I've facilitated probably 500 sprint retrospectives over the years. And I'll be honest: most of them were mediocre at best. The team shows up, complains about the same three things they complained about last time, writes some action items that never happen, and leaves. Repeat every two weeks forever.
This isn't what retros are supposed to be. But it's what most retros are. Here's why, and what actually works.
The Symptoms of a Dying Retro
You know your retros are in trouble when:
The same issues appear on the board month after month
Action items from previous retros aren't followed up on
People contribute one sticky note to hit the minimum, then check out
"It was fine" becomes the team's default assessment
Attendance gets mysteriously "complicated" around retro time
The loudest person dominates while others stay silent
If any of these sound familiar, you're not alone. This is the default state of retros in most organizations.
Why Retros Fail
No actual accountability for change
The classic retro format generates action items, then... nothing. No one owns them. No one tracks them. No one is empowered to actually implement them. The action items go into a doc that no one reads, and two weeks later, you generate the same action items.
Discussing symptoms, not root causes
"Deployments are too slow" is not actionable. Why are they slow? Is it the CI pipeline? Is it manual testing? Is it deployment queue bottlenecks? Until you dig to the root, you can't fix anything. Most retros stop at the symptom level because going deeper is uncomfortable.
Psychological safety issues
Real retros require honesty. "I think our architecture decision was a mistake." "I don't feel supported by the team lead." "We're building the wrong thing." These are the conversations that drive real improvement. But if people don't feel safe being honest, you'll only get surface-level feedback.
The format is stale
If you've been doing "What went well / What didn't / What could improve" for two years, people are bored. The format itself signals "this is routine, not important."
What Actually Works
Make action items someone's actual job
Every action item from a retro needs an owner and a deadline. Not "the team will do X" but "Alex will do X by next Tuesday." At the start of the next retro, spend the first 10 minutes reviewing: did the action items happen? If not, why not?
Use "5 whys" relentlessly
When someone raises an issue, keep asking "why" until you hit something actionable:
"Deployments are slow."
→ Why? "Because the pipeline takes 45 minutes."
→ Why? "Because we run all tests sequentially."
→ Why? "Because no one's prioritized parallelizing them."
→ Why? "Because it wasn't in the sprint."
✓ Action: Add test parallelization to next sprint
Try different formats
Some options beyond the standard "good/bad/improve":
Start/Stop/Continue
What should we start doing, stop doing, and continue doing?
4Ls
Liked, Learned, Lacked, Longed for
Mad/Sad/Glad
Emotional check-in that surfaces deeper issues
Sailboat
Wind (propels), anchors (holds back), rocks (risks)
A Sample Retro Structure
Here's a format that's worked well for teams I've coached:
Action item review
What did we commit to last time? Did it happen? If not, is it still a priority?
Async prep
Everyone silently writes topics on virtual sticky notes. Prevents anchoring.
Clustering and voting
Group similar items. Everyone gets 3 votes to indicate priority.
Discuss top items
7-8 minutes each for the top 3-4 items. Use 5 whys. Get to root causes.
Action items
What specifically will change? Who owns it? When is it due?
Retro the retro
One minute: was this session useful? What should we change next time?
The Meta-Point
Retros are a microcosm of your team's health. If your retros feel pointless, it usually means one of two things:
- The team doesn't actually have the power to change things (learned helplessness)
- The team doesn't have the psychological safety to be honest (trust issues)
Both of these are bigger problems than retro format. But the retro is often where they become visible.
Fix the retro, and you create a space where improvement is possible. Ignore the retro, and you're accepting that things will stay as they are.
Your choice.
Mei has been coaching engineering teams for 8 years. She's seen every flavor of "agile" and most of them are wrong.