How to Run a Retrospective That Actually Changes Something

I joined a healthcare enterprise coaching engagement where one squad had been running retros every two weeks for over a year. They had a Miro board with hundreds of sticky notes organized by color. They rotated formats: Mad/Sad/Glad one sprint, Start/Stop/Continue the next, sailboat metaphor the sprint after that.

Nothing changed. The same three themes appeared every retro: unclear requirements, too many meetings, no time for tech debt. The team dutifully wrote them down, voted on them, discussed them for 30 minutes, and went back to work. Two weeks later, the same stickies reappeared in different colors.

The retro had become a venting ritual. It felt productive in the moment but produced nothing.

The format is not the problem

When a retro stops producing change, most teams blame the format. They search for a new template, bring in an icebreaker, try a different voting method. This is like rearranging furniture in a house with a leaking roof.

The format is the least important variable in a retro. I have seen teams produce meaningful change using the simplest possible structure: what went well, what did not, what are we going to do about it. I have also seen teams run beautifully designed retros with custom Miro templates and timed breakout rooms that produce nothing.

The difference is not the template. The difference is three things: accountability for past commitments, psychological safety to name what is actually broken, and the discipline to focus on root causes instead of symptoms.

Check last retro's actions first

This single practice changes retros more than any template ever will.

Before generating a single new sticky note, review the action items from the last retro. Did they happen? If yes, acknowledge it. If no, discuss why. Not to blame anyone, but to understand what got in the way.

Most teams skip this step. They generate new action items every two weeks without checking whether the old ones landed. The result is a growing list of abandoned commitments that teaches the team a clear lesson: retro actions do not matter.

When you start every retro by reviewing what you committed to last time, the team learns a different lesson: these commitments are real. People start volunteering for actions they can actually complete. The quality of the actions improves because everyone knows they will be reviewed.

At the defense software portfolio I coached, one team had never tracked retro actions before. The first time we reviewed them, two of three items were incomplete. We discussed what blocked them, adjusted scope, and re-committed. Within four sprints, the team was completing 80% of their retro actions. The retro went from a complaint session to the most productive 30 minutes of their sprint.

Silent writing before anyone speaks

Open discussion favors extroverts, people with strong opinions, and whoever speaks first. Silent writing levels the field.

Give the team 3 to 5 minutes to write observations individually before anyone shares. This is a core facilitation technique: extract information from the full group before discussion narrows the options. The quiet engineer who noticed a deployment bottleneck gets the same airtime as the PM who always has something to say.

After silent writing, dot vote to surface themes. Each person gets 3 dots. Discuss only the top 2 to 3 themes. The team's collective intelligence identifies what matters most.

Root causes, not symptoms

"Our deploys are slow" is a symptom. "We have no automated test suite, so every deploy requires manual regression testing" is a root cause. The symptom generates a vague action item like "improve deploy process." The root cause generates a specific one: "Pair on writing integration tests for the checkout flow this sprint."

When a theme surfaces, ask "why" until you reach something the team can act on. Not five whys for the sake of it, but enough digging to move from "things are frustrating" to "here is the specific thing we can change."

The discipline here is resisting the pull toward easy answers. Teams prefer to name symptoms because they feel shared and safe. Root causes often point to specific decisions, specific gaps, specific people who need to have a conversation. That discomfort is where the value lives.

Two to three action items, each with an owner

A retro that produces five action items will complete zero of them. A retro that produces two will complete both.

Every action item needs a clear description of what "done" looks like, a single owner (not "the team"), and a due date. These actions should flow directly into the team's iteration plan for the next sprint. If the action is important enough to commit to in retro, it is important enough to allocate capacity for.

When the same theme keeps appearing

If the same issue surfaces three retros in a row, that is not a retro failure. That is a delivery diagnostic signal. The retro is doing its job by surfacing the problem. The system around the retro is failing to resolve it.

Recurring themes usually point to something outside the team's direct control: an organizational constraint, a dependency, a leadership decision that has not been made. When you spot this pattern, escalate. Bring the data to the person who can actually change the constraint. Three retros of evidence is a compelling case.

At the healthcare enterprise, one squad flagged "unclear requirements" for four consecutive retros. The root cause was not the PM's writing. It was that the PM was receiving shifting priorities from a stakeholder group that could not align on what mattered. The fix was not a better story template. It was a conversation between the PM and the stakeholder group, facilitated by their coaching lead, that produced a prioritized list everyone committed to.

The retro is a mirror

A retro where people only share safe observations, where the real issues live in hallway conversations and Slack DMs but never make it to the board, is a team that does not trust each other enough to be honest in the room.

The team is the product. And the retro is where you find out whether the team is healthy enough to improve. If people feel safe naming what is actually broken, the retro will surface real problems and produce real change. If they do not, no format or template will fix it.

The good news: safety is buildable. It starts with the facilitator modeling vulnerability, responding to hard feedback with curiosity instead of defensiveness, and following through on what the team commits to. Over time, the team learns that honesty in retro leads to actual improvement. That learning is the retro working.

---

For the complete ceremony-by-ceremony facilitation guide, including retro-specific techniques, see the facilitation playbook. If your team's retros have gone stale and you want help making them stick, let's talk.