Retrospectives That Actually Change Things
The retrospective is the most important Agile ceremony and the most frequently wasted. I have facilitated hundreds of retros. The ones that fail all share the same pattern: the team identifies problems, generates action items, and then nothing changes.
The issue is not that teams lack insight. They know what is wrong. The issue is that retro action items enter a black hole. They get written on a sticky note or a Confluence page and are never referenced again until the next retro, when the same problems come up.
Make Action Items Owned and Sized
Every action item needs an owner and a due date. Not "the team" as owner. A person. And the action needs to be small enough to complete in one sprint. "Improve our testing process" is not an action item. "Write a pre-merge checklist for the payments module by next Friday" is.
I track retro action items in the same backlog as feature work. They get assigned during sprint planning. They show up on the board. This makes them visible and accountable.
Rotate the Format
If you run the same "what went well, what did not, what can we improve" format every sprint, people disengage. I rotate between formats: Start/Stop/Continue, the sailboat exercise, timeline retros, and focused retros on a single topic. The novelty keeps people engaged and surfaces different insights.
Follow Up First
I start every retrospective by reviewing action items from the last one. Did we do them? If yes, did they help? If no, why not? This creates accountability and shows the team that their input matters.
The retrospective is where continuous improvement lives or dies. If your retros feel stale, the problem is not the ceremony. It is the follow-through. Fix that and the retros will fix themselves.
←Back to all posts