If your retrospectives feel like awkward therapy sessions where someone mentions a problem that doesn’t get solved, and everyone agrees communication could be better, and then nothing changes—you’re not alone. The retrospective is the most important Agile ceremony and the most routinely broken.
A good retro is the difference between a team that gets better every sprint and a team that runs the same broken process forever, slightly annoyed. A bad retro is what most teams have.
Why Retros Drift Into Discomfort
The problem usually starts with the room itself. If your manager is in the retro, people aren’t going to be honest. They’re going to optimize for sounding good. “Communication could be better” (translation: you don’t listen). “We had some challenges with scope” (translation: you overcommitted us). “The database performance was interesting” (translation: the database query you wrote was terrible and nobody wanted to say it).
Nobody wants their honest feedback to become a note in a performance review.
But even in well-designed rooms—no managers, peers only—retros still drift. Here’s the pattern I see: someone raises a real problem. Everyone agrees it’s a problem. Someone suggests a solution. A different solution gets suggested. You’re now at minute twenty-five of a forty-five minute meeting and you’ve spent all your time debating solutions without anyone agreeing on what the problem actually is. Or worse, someone says, “We should probably do X,” everyone nods, the facilitator writes it down, and then at the next retro nobody has done X and you don’t talk about why.
The other big drift: the retro becomes a gripe session. People are frustrated, they have a safe space, so they vent. The team feels better for an hour. Then nothing changes, and by the next retro, people are frustrated again. This time their venting is more bitter because last time didn’t help.
And then there’s the retro where everyone is so uncomfortable that you just do the safe version: “What went well? Great teamwork. Great communication. What could we improve? Maybe we could communicate better?” Everyone leaves having said nothing real. The retro happened. The box is checked.
What Makes a Retro Actually Work
First: no managers. Not the person who controls whether you get promoted. Not the person who decides your bonus. Just the team. This is non-negotiable.
Second: a facilitator who actually facilitates. Most teams rotate who runs the retro, which is good in principle—it distributes the work, it means nobody gets stuck as “the Scrum Master”—but it means your facilitator is probably not very good at the job. A good facilitator does three things: makes sure people feel safe being honest, asks clarifying questions when someone raises a problem, and most importantly, makes sure the team commits to actual actions and follows up on them.
When someone says “we need better communication,” a good facilitator doesn’t nod and move on. They ask: “What does that actually mean? Where did communication break down this sprint? What specifically would better communication look like?” And then, crucially: “Who’s going to own making that happen? By when?”
If nobody owns it, it doesn’t happen. If you don’t follow up next retro on whether it happened, it becomes clear that retros are theater, not a way to get better.
Third: the team has to have enough psychological safety to name real problems. This means if someone raises something, the response can’t be defensive. If someone says, “I was confused about the feature requirements,” the PM can’t say, “Well, I documented it clearly.” They have to say, “Okay, where did I miss clarity? What would have helped?” This takes practice. Most teams are terrible at it at first.
Formats That Actually Lead to Change
Start/Stop/Continue is the most straightforward. What should we start doing? What should we stop doing? What should we keep doing? It forces action—Start and Stop are inherently about change. It also constrains the conversation. You’re not endless venting; you’re identifying discrete changes.
A good start/stop/continue retro might surface: Start—better definition of done before sprint planning. Stop—the afternoon stand-up that nobody thinks is useful. Continue—the pairing sessions on Fridays that have been really useful for knowledge sharing.
Then someone owns each change. “Sarah’s going to draft a definition of done template, and we’ll refine it next planning.” “We’re canceling the afternoon stand-up starting next sprint.” “We’re keeping Friday pairing.”
4Ls is Liked, Learned, Lacked, Longed For. It’s a bit more introspective. Liked: what went well. Learned: what did you learn. Lacked: what was missing. Longed For: what do you wish had happened. This one works well for teams that are thoughtful and introspective, but can get overly touchy-feely if you’re not careful.
Mad/Sad/Glad is just what it sounds like. What made you mad? What made you sad? What made you glad? It’s a bit more emotional, which can be good if your team needs permission to acknowledge that they were frustrated, but it can also get pretty raw.
The format matters less than the discipline. Whatever format you use, you need to:
- Identify specific, concrete problems, not abstract ones
- Talk through what actually happened, not just that it was bad
- Identify specific, concrete changes to make
- Assign ownership to each change
- Follow up next retro on whether those changes happened and whether they worked
If you skip step five, you’re wasting everyone’s time.
The Follow-Through Piece
Here’s where most retros die: you identify a change, nobody owns it clearly enough, and two weeks later it’s not done. So you go to the next retro and someone says, “Did we ever do the thing about clearer requirements?” and the answer is “not really” and everyone feels bad and frustrated.
This is the facilitator’s job. They write down the actions. They own the follow-up. At the next retro, the first thing you do is review what you committed to. Did it happen? If yes, is it working? If no, why not? Do we still think it’s worth doing? If we do, we need to figure out what’s in the way.
Most teams skip this. They just jump into new problems every retro. And so you get the same problems every sprint, each one a little more frustrating because now you’re not just dealing with the problem, you’re dealing with the fact that you’ve talked about it five times and done nothing about it.
A good team’s retros are boring. They’re not dramatic. They’re not full of shocking revelations. They’re fifteen minutes of reviewing the changes you committed to last sprint, thirty minutes of identifying one or two specific things to try differently, and everyone leaves knowing who owns what.
An hour, all told. Disciplined. Focused. And the team actually gets better.
Most retros aren’t like that. Most retros are longer and produce less. But the good news is that this is entirely in your control. It’s not about having the right team or the right manager or the right tool. It’s about being disciplined enough to actually follow through on the changes you identify.
Try it for three sprints. Identify two small changes per retro. Assign one person to own each. Follow up at the next retro. See what happens. My bet is by sprint three, your team is noticeably better at coordinating. By sprint six, they’re noticeably better at shipping.
The retro is the only place built into Agile where you stop and ask if the way you’re working is actually working. If you use it right, it compounds. If you don’t, you’re just running the same process forever.