Most retrospectives I've attended follow the same script. Someone puts up a Miro board with three columns: What went well, What didn't go well, What to improve. Everyone adds sticky notes. Someone reads them out. The team nods. Someone writes down three action items. The meeting ends. The action items are never mentioned again.
Two weeks later, same problems. Same retrospective.
The issue isn't the format. The issue is that retrospectives are treated as a ritual rather than a problem-solving session. You go through the motions, you feel like you've done the thing, and nothing changes.
Why action items die
Action items from retrospectives die because they're too vague, unowned, or both. "Improve communication between design and engineering" is not an action item. It's a wish. Nobody knows what it means, nobody knows who's responsible for it, and there's no way to tell if it happened.
I started requiring that every action item has three things: a specific action, an owner, and a date. "Safarmurod will add a design review checkpoint to the sprint planning checklist by next Friday" is an action item. "Improve communication" is not.
Improve communication between design and engineering
Safarmurod adds a design review checkpoint to the sprint planning checklist by next Friday
This sounds obvious. It's not obvious in the moment, when the meeting is running long and everyone wants to wrap up. The vague action item feels like progress. It's not. It's a way of acknowledging a problem without committing to solving it.
The other reason action items die is that nobody checks on them. If you write down three action items at the end of a retro and never mention them again until the next retro, you've trained your team that action items don't matter. They'll stop taking them seriously, which means they'll stop raising real problems, which means the retro becomes pure theater.
The format problem
The three-column format is fine for generating observations. It's bad for generating solutions. You end up with a list of problems and a separate list of improvements that may or may not address those problems. The connection between "what went wrong" and "what we're going to do about it" is implicit and often lost.
I switched to a different format. We spend the first half of the retro identifying the one or two biggest problems from the sprint - not everything that could be better, just the things that actually hurt. The second half is a focused conversation about what specifically we're going to do about those things.
This means we don't address every problem every retro. That's fine. The problems that matter most get real attention and real solutions. The minor annoyances get noted and revisited if they keep coming up. If something keeps appearing in retros without getting addressed, that's a signal it's more important than it seems - or that there's a structural reason it's not getting fixed that we need to surface.
The format change also changes the energy in the room. When people know the retro will produce two specific, owned action items rather than a list of wishes, they engage differently. They're more willing to name the real problem instead of the safe version of it.
The psychological safety part
Retrospectives only work if people say what they actually think. In teams where there's low trust or where criticism is taken personally, retros become performance. Everyone says things are fine, or they raise only safe complaints, and the real problems stay hidden.
I can't fix a team's psychological safety in a retro format. But I can create conditions that make honesty easier.
Anonymous input collection before the meeting helps. People say things in writing that they won't say out loud, especially about process problems that implicate specific people. I use a simple form - three questions, anonymous responses - and read through them before the meeting so I can identify themes and prepare to address the uncomfortable ones.
Modeling honesty myself matters more than anything else. If I'm willing to say "I made a mistake here - I wrote a spec that was ambiguous about the timing requirement and we built the wrong thing," that sets a tone. If I'm defensive about criticism, the team will stop giving it. The PM is usually the most powerful person in the room during a retro. How you respond to feedback about your own work determines whether people feel safe giving it.
Starting with what went well, genuinely, also helps. Not as a ritual warm-up, but because it's true that things went well and it's worth naming them. Teams that only ever talk about what went wrong develop a distorted view of their own performance.
The follow-through
The retro doesn't end when the meeting ends. At the start of the next sprint planning, I spend five minutes reviewing the action items from the last retro. Did we do them? If not, why not? If yes, did they help?
This is the part most teams skip. It's also the part that makes retros worth doing. When the team sees that action items actually get followed up on, they start taking them seriously. When they see that nothing changes, they stop trying.
The follow-through also gives you data about your retro process itself. If you consistently generate action items that don't get done, that's a signal - either the items are too vague, the owners don't have the capacity, or the problems are structural and can't be solved at the team level. That's useful information. It tells you what kind of problem you're actually dealing with.
The retrospective is only as good as what happens after it. Everything else is just a meeting.