Picture the scene. It's Friday afternoon. The sprint is over. Someone has opened a Miro board with three columns: What went well, What didn't go well, What could we improve. People are staring at it like it owes them money. After a long pause, someone types "communication" under the third column. Someone else adds "deployment process." A third person types "communication" again, not having noticed the first one.
Forty-five minutes later, you close the meeting with a vague commitment to "talk more" and "look at the pipeline." No owner. No date. No follow-up. The action items go into a Confluence page that no one will open until the next time someone asks what the last retro produced, at which point someone will say "I think we looked at the pipeline."
This is most retrospectives. Not all of them. But most.
The retrospective is, in theory, one of the most valuable rituals in software delivery. A structured moment of collective honesty. A chance to ask what's actually happening here, and to improve as a team rather than just continue. In practice, it is often a compliance exercise dressed up as a ceremony. You do it because the process says to. And because you do it badly, it produces nothing. And because it produces nothing, people stop engaging. And because people stop engaging, it produces nothing. Round and round.
The failure isn't usually dramatic. There's no single villain. The meeting fails slowly, through accumulated habits that look reasonable in isolation.
The most common is what I'd call honesty suppression. A retro only works if people say true things. But teams are made of humans with memories and working relationships and line managers in the room. Psychological safety isn't a switch you flip, it's an environment you either build over months or don't. Ask a team that doesn't trust each other what went wrong this sprint, and they will tell you what they think is safe to say. Which is usually "communication."
Close behind that is the retrospective that confuses symptoms for causes. "The deployment took too long" is a symptom. What caused it? What broke? Was it knowledge concentrated in one person? A manual step that's never been automated because no one owns it? Symptoms are easy to identify and almost useless to act on. Causes require interrogation.
Then there's the retrospective that generates actions and buries them. Twelve items on the board, three owners, no deadlines, never reviewed. The next sprint starts and everyone is heads-down immediately, and the actions exist in a document in a folder in a space that no one has the Confluence breadcrumb for anymore. This is arguably worse than not writing anything down. At least then you have no expectation of change.
And finally, the retro that happens to the team rather than with it. A facilitator running through a template, people dutifully adding sticky notes, no real conversation, no challenge, no tension. If the meeting could be replaced by a Google Form and nobody would notice, that's a sign.
Good retrospectives don't feel like good retrospectives. They feel uncomfortable, occasionally.
Not gratuitously uncomfortable. Nobody needs conflict for its own sake. But the useful retrospective will surface something that needs to be named. A process that is quietly eating everyone's time. A decision that was made three months ago that's become a millstone. A pattern in how the team communicates under pressure. If you come out of a retro feeling exactly as you went in, nothing happened.
The facilitator matters more than the format. Whether it's Start / Stop / Continue, Four Ls, the Sailboat, or something you made up yourself - the format is scaffolding, not substance. What actually produces insight is a facilitator who asks the second question. The first question, what didn't go well?, is easy. The second one, why? what's the root of that? where does that actually come from?, is where the retro earns its keep. This is why a rotating facilitator, pulled from the team, works better than a tired Scrum Master running through a template for the fortieth consecutive sprint. Familiarity breeds shortcuts.
The other thing good retros do is respect the difference between things the team can change and things they can't. Teams waste enormous energy relitigating decisions made above their authority. That's not a retro, it's group therapy. Acknowledge it, park it, escalate it if you need to, but don't spend your one improvement meeting venting about the roadmap you had no hand in setting. Focus on the things you can actually move.
Outcomes deserve more attention than format. A retro that surfaces three real insights and produces one actionable change is worth more than a retro that generates twelve items that dissolve by the start of the next week.
An action from a retrospective should have three things: an owner, a definition of done, and a date. Not "the team will look at the CI pipeline." Someone owns it. Something specific will change. By a named sprint or date. If you can't say those three things about an item, it's not an action, it's a wish. And wishes are washy.
The actions should be reviewed at the start of the next retro, before anything else. Not as bureaucratic ritual, but because the quality of your follow-through is the only signal the team has that the retro is real. The moment people believe that actions disappear into the void, engagement drops. And once it drops, getting it back is hard.
One practice I've seen work well: cap the number of actions. Three. Possibly five if they're trivial. Not twelve. The instinct to write everything down is understandable. It feels productive, but a team can only absorb so much change per sprint. Three things, actually done, compounds beautifully. Twelve things, mostly ignored, erodes trust in the whole process.
The retrospective is a bet that your team will be better next sprint than it was last sprint. Not because the sprint was magical, but because you stopped, looked honestly at what happened, identified something specific to change, and then changed it.
That bet only pays out if you take it seriously. Not solemnly. Retros can be human and I do try to make them funny. But they must be taken seriously, in the sense that the conversation is real, the actions are real, and the follow-through is real.
Most teams don't do that. They run the meeting, fill the board, close the tab, and wonder why nothing gets better.
You know what to do instead. The hard part isn't the format. It's actually meaning it.
Top comments (0)