Raise your hand if this sounds familiar:
- Your team rolls into the retro half-distracted
- You rehash the same pain points you talked about last sprint
- Someone adds action items that no one will follow up on
- Two weeks later, nothing has changed
Yeah, me too.
A friend of mine put it best:
"We stopped doing retros. They just turned into venting sessions that created tasks no one followed up on."
Honestly? That tracks.
So what do you do instead?
I’ve sat through every retro format imaginable — sticky note boards, sailboat metaphors, start/stop/continue, fancy tools.
None of it really helped until we made one change:
We stopped trying to fix everything.
Instead of asking:
"What went wrong?"
We started asking:
"What’s one thing in our control we can improve next sprint?"
It’s a subtle shift, but it changed the tone.
Suddenly retros weren’t just post-mortems.
They were decisions. Small, actionable, team-owned decisions.
If this resonates...
I wrote a short PDF guide called Retros That Don’t Suck.
It’s free, blunt, and based on 20 years of real-world agile and post-agile pain.
It includes:
- A repeatable format you can run in 30 minutes or less
- A way to surface real problems — not just process noise
- Tips for getting actual improvements to stick
- Bonus: when to kill the retro and do something better
👉 Grab the free guide here
(Just an email. No spam.)
Would love to know if this lands with you — or how your team’s handled broken retros.
Top comments (1)
"We stopped doing retros" is often the right answer.
When your process improvement process needs improvement, maybe the process is the problem.
Some teams just need to ship working software, not optimize their feelings about shipping.