Why retrospectives fail (and how to make yours matter)

Your team runs a retro every sprint. People show up, post their stickies, nod at two or three action items, and leave. Then nothing about how the work actually happens changes. Do that forty times a year and you haven’t built a habit of improvement — you’ve built a habit of talking about improvement. That is the failure mode almost nobody names: not a bad format, but a ritual that reliably produces words and only words.

The standard advice treats a failing retro as a facilitation problem — rotate the format, write SMARTer actions, add an icebreaker. Sometimes that’s the issue. Usually it isn’t. We’ve cataloged the ten common retrospective anti-patterns elsewhere, and they’re worth fixing. This chapter goes after the two failures that list politely steps around, because they are the ones that make experienced engineers call retros a waste of time: a power problem and a follow-through problem. No icebreaker touches either.

The retro that changes nothing because the team can’t

Here is the deepest critique of retrospectives, and the one our own anti-patterns post gets backwards. When a developer says “nothing ever happens,” they usually don’t mean the team forgot to write action items. They mean the problems worth raising — headcount, cross-team dependencies, a deployment pipeline that takes forty minutes, a deadline set three levels up — are genuinely outside the team’s authority to fix. As one engineer put it plainly on Hacker News, a retro can become “a ceremony without actual purpose because usually the deeper things that people bring up are not within that team’s power to control.” Another, in the same thread: “It gives leadership an excuse for not fixing things or listening because retro is supposed to be the outlet for gripes.”

That’s the trap. The retro turns into a pressure valve — the team gets to speak, precisely so that nothing has to change. People vent, leadership feels the box is ticked, and the underlying cause survives untouched. Blaming the facilitator for this is, as one developer’s essay put it, “like blaming the suggestion box for management not reading the suggestions.” No amount of sailboat-versus-starfish will give a team the authority to solve a problem it was never given authority to solve.

Our old advice — “stop focusing on things outside your circle of influence” — quietly sides with the system here. It tells the team to bury the real blocker to keep the conversation comfortable. Take the harder line instead. Sort every issue by who actually owns it: what the team controls, what it can influence, and what it can only suffer. That’s the Circles and Soup activity from Esther Derby and Diana Larsen’s Agile Retrospectives (2nd ed.) — and the point of the outer ring is not “ignore these.” It’s the input to an escalation.

Not everything escalates, and not everything is hopeless. 15% Solutions — the Liberating Structures technique of finding the smallest change the team can make without anyone’s permission — keeps momentum on the influence ring while the big blockers work their way up. But the honest retro refuses to pretend the outer ring is the team’s fault.

The feedback that gets banked and used against you

Now the part no vendor writes about. People stay quiet in retros for a reason more concrete than shyness: being honest can be career-negative. The fear is specific and it shows up in real stories. One developer described retro feedback resurfacing “in my yearly evaluation where it was pointed out that I ‘complain too much’.” Another, more cynically: “they bank all these complaints for withdrawal at your annual bonus review.”

That’s feedback banking — honest input stored up and withdrawn against you later — and it is the fastest way to kill a retro dead. The Scrum Guide describes the Sprint Retrospective as the Scrum Team inspecting itself. Read that literally: the team, inspecting itself. So why is the person who signs your performance review sitting in the room taking notes? Their silence is enough — nobody who controls your promotion has to say a word to make you soften what you’d have said otherwise. Google’s Project Aristotle found psychological safety the single biggest predictor of team effectiveness; a manager’s mere presence is often enough to remove it. (We cover the mechanics in the chapter on building a psychologically safe space.)

So name the fear and design against it:

• Keep promotion authority out of the room. Share the agreed actions upward, not seats. A team blocked by a manager’s presence cannot hold a transparent retrospective, and no facilitation trick recovers it.
• Agree what’s said stays in the room. Only the actions the team chooses to publish leave it. This is what lets people speak in the first place.
• Make anonymity an option per idea, not a permanent mode. Anonymity levels power dynamics and surfaces the sensitive stuff; used as a permanent crutch it erodes the trust you’re trying to build. Let people choose it for the item that needs it.
• Be careful bringing metrics in. Objective data (velocity, cycle time) belongs in a retro — but the moment velocity becomes a target the team is measured against, you’ve built a velocity ratchet, and people optimize the number instead of telling the truth. This is the power failure mode that turns candor into performance.

The follow-through void — and the reframe that fixes it

Assume the power and safety problems are handled. Retros still fail on the most-repeated complaint in the entire discourse: “Retrospectives allow airing concerns, but nothing really ever happens of those concerns.” Or, more bluntly: “I have never seen anything happen besides words.” The resigned sound of it — “this sticky will not be addressed” — is what groundhog-day retros feel like from the inside. It’s not imagination: by one commonly cited Scrum Alliance figure, only about a third of teams consistently complete their retro action items. The rest get written on a whiteboard and erased. The folklore does oversell the doom, though — we measured how many retrospective action items actually get done across hundreds of thousands of real actions, and completion is closer to three in four, with cadence and ownership deciding which side of the gap a team lands on.

Two fixes, and the second is the important one.

First, stop trying to fix everything. A retro that generates ten action items completes none of them. Cap it at one improvement the team genuinely commits to, and open every retro by reviewing last time’s one thing before generating anything new. If it wasn’t done, that’s the most useful conversation in the room. Reaching for a new format is the first thing teams try and the least likely to help — swapping Mad/Sad/Glad for a sailboat is lipstick if follow-through is broken.

Second — and this is the reframe from the Agile Retrospectives 2nd edition that the whole category is moving toward — stop treating the action item as the point. Derby, Larsen and David Horowitz’s key shift is that learning, not a completed to-do, is the success criterion. Replace the action item with an experiment: a hypothesis you test (“if we pair on the risky story, we’ll cut rework”), a date to review it, and an honest look at what actually happened. A retro that produced no checkbox action but genuinely taught the team something is not a failed retro. That single move dissolves the “nothing changes” complaint, because the goal stops being a completed chore and becomes a change you’re actually running.

Silence isn’t apathy — it’s a signal

A quieter failure: the retro where two of eight people talk for five minutes and the rest is dead air, and every format and pre-filled board you try changes nothing. It’s easy to read that as a disengaged team. It usually isn’t. Silence in a retro is a signal, not the problem itself — it points at missing trust, unclear purpose, or a leadership issue people won’t name out loud. Remote makes it worse: cameras off, mics muted, energy flat.

Don’t fill the silence with more prompts. Change who talks first. Run a silent, solo brainstorm before any discussion so people write before they speak — which protects the introverts and the people who don’t want to be the one who says it aloud. Collect input async ahead of time. Let people contribute a sticky without having to defend it in front of the room. The goal isn’t a lively meeting; it’s honest data, and honest data often arrives quietly.

The meeting tax is a real cost, not an excuse

Finally, the critique the “never skip the retro” crowd waves away too fast: retros cost something. “It’s another meeting on my calendar potentially interrupting whatever deep focus I was in,” one developer wrote — stacked on standup, planning, review, and refinement. On short cadences the maths gets brutal: teams on one-week sprints describe planning and retro every week as “a burden,” and they’re right. Fifty retros a year on a mature team is not a virtue.

The answer isn’t to skip retros; it’s to right-size them. A newly formed team under stress benefits from a retro every sprint. A stable team that keeps having the same thin conversation is telling you the cadence is wrong, not that reflection is worthless. Move to bi-weekly, or trigger retros by events — after a release, after an outage, after a rough sprint — when there’s genuinely something to inspect. Cadence is a dial, not a commandment. (The same overload logic runs through every ceremony — see standup anti-patterns and the follow-through void in our Agile Theatre field guide.)

Fix the power problem, protect the honesty, follow through on one real thing, and right-size the cadence, and the retro stops being a pressure valve. It becomes the one hour a sprint where the team actually changes how it works — which was always the point.

Frequently asked questions

Why does nothing ever change after our retrospectives?

Usually because the issues that matter most are outside the team’s authority, and the retro has no route to send them anywhere. The board fills with problems the team cannot fix alone — headcount, dependencies, a broken deployment pipeline — and everyone leaves having described the weather rather than changed it. The fix is to triage every item by who actually owns it, keep a single team-controlled improvement to work on, and escalate the out-of-scope items upward by name with an owner and a date instead of quietly dropping them.

What do you do when the real problem is outside the team’s control?

You escalate it, on the record. Sort issues into what the team controls, what it can influence, and what it can only suffer (the Circles and Soup activity from Agile Retrospectives). The generic advice says to ignore the outer ring and stay in your circle of influence. That is how a retro becomes theatre. Instead, turn the outer-ring items into a visible request — a Retrospective Radiator — that names the blocker, the impact, and who needs to act, and put it in front of the people who can move it. A retro that only surfaces problems the team can already fix is comfortable and dishonest.

Is it safe to be honest in a retrospective?

Only if honesty carries no career cost. Developers routinely report retro feedback resurfacing in a performance review as evidence they “complain too much.” If the person who signs off on promotions is in the room, or if what’s said gets banked for later, people go quiet and say everything is fine. Protect candor deliberately. Keep line managers who own promotions out of the session, agree that what’s discussed stays in the room and only agreed actions leave it, and make anonymity available per idea rather than as an all-or-nothing mode.

Are retrospectives a waste of time?

They are when the only success test is a completed action item, because most sprints don’t hand you a tidy one. Reframe the goal — a retrospective succeeds when the team learns something it will carry into the next sprint, even without a checkbox action, and when it runs one honest experiment rather than ten abandoned to-dos. Retros also do quieter work — surfacing tension early and keeping a team cohesive — that never shows up as an action item but is real. Judged as a learning ritual instead of a task factory, they earn their place.