Retros That Actually Produce Change

I've facilitated hundreds of retrospectives. For the first few years, most of them followed the same pattern: the team vents, we generate action items, nobody follows up, and next retro we vent about the same things. Sound familiar?

The problem isn't that teams don't have good ideas. The problem is that retro output rarely survives contact with the next sprint.

What I changed

Maximum three action items. Not five, not eight, not "we'll track these in a backlog." Three. If we can't prioritize to three, we haven't prioritized at all.

Every action item gets an owner and a deadline. "Improve code review process" is a wish. "Sarah will draft a code review checklist by Thursday and present it at Friday's standup" is an action item.

Action item review starts the next retro. The first 10 minutes of every retro is reviewing last retro's action items. Did we do them? If not, why? This accountability loop is what makes retros produce change instead of catharsis.

Rotate facilitators. When I facilitate every retro, the team tells me what they think I want to hear. When a different engineer facilitates each time, the conversations are more honest and the perspectives are more varied.

Formats that work

I rotate between four formats to prevent retro fatigue:

• Start/Stop/Continue for general health checks
• Timeline after major releases or incidents
• Four Ls (Liked, Learned, Lacked, Longed for) for milestone reflections
• Sailboat (wind, anchor, rocks, island) for quarterly planning

The format matters less than the follow-through. A boring retro that produces one implemented change is worth more than an energizing retro that produces zero.

The metric

I track the percentage of retro action items completed before the next retro. When we started measuring this, our completion rate was around 30%. It's now above 75%. That number represents real process improvement, not just good conversations.