Are retrospectives worth it? Our verdict
Yes — but not for the reason most teams defend them. A retro earns its hour through learning and cohesion, not a tidy list of action items. If yours only produces words, the ritual isn't the problem. We steelman the skeptics and rule.
Yes — but not for the reason most teams defend them. A retro earns its hour through learning and team cohesion, not through a tidy list of action items. If yours only produces words, the ritual isn’t the problem. The follow-through is, and so is the team’s power to act.
“Retros are a waste of time” isn’t a lazy complaint. It’s the most serious critique anyone makes of agile ceremonies, and the honest defense has to go through it, not around it.
The case that retros are pointless
The skeptics’ evidence is specific and it’s everywhere. Concerns get aired and nothing happens; the same sticky note comes back sprint after sprint with the quiet resignation that it won’t be addressed this time either. By one commonly-cited survey, only about a third of teams consistently finish their retro action items — and even that framing misses the deeper failure. (For what it’s worth, the folklore is too gloomy: our own data on whether teams actually do what they decide in retrospectives puts action completion closer to three in four.)
The deepest version of the critique is powerlessness. The meaningful problems — budget, headcount, cross-team dependencies, infrastructure, decisions made two levels up — are genuinely outside the team’s authority. So the retro becomes the place those problems get named and nothing more: the team is handed a voice but no lever to pull. Worse, it gives leadership an excuse. There’s a channel for gripes now, so if nothing improves, that’s the team’s outlet not functioning, not the org’s problem to fix.
Then there’s the career risk, which almost no vendor page will name. When honest feedback gets stored up and quoted back in a performance review — flagged as complaining too much — people learn the lesson fast: candor is a liability. And there’s a real cost even to the venting itself. Sitting through an hour of other people’s frustrations, sprint after sprint, is its own quiet drain.
That is a formidable case. A retro that behaves like this is worse than no retro, because it teaches learned helplessness on a two-week cycle.
Why they are still worth it
The defenders’ strongest line isn’t “action items get done.” It’s cohesion. Even an imperfect retro, held as a regular, un-skippable ceremony, does more for a team’s ability to work together than its absence — teams that never stop to talk suffer internal strife far more often than teams that do. The most telling redemption story in the discourse is the engineer who went from dreading retros to looking forward to them, and realized the difference was that they had simply never seen one run properly.
The current canon backs this. The second edition of Agile Retrospectives (2024, with David Horowitz added as a third author) makes the shift explicit: the success criterion is learning, not a checklist of actions. A retro where the team genuinely understood something isn’t a failure because it produced no ticket. That single reframe answers the number-one complaint — because “nothing changed” stops being the only measure of a retro’s worth.
Where we would change our mind
We would tell a team to stop running retros in one specific situation: when the real problems are overwhelmingly outside its control, leadership won’t act on escalations, and the meeting has no power and no follow-through. At that point the retro is theatre, and we would rather you fix the escalation path — or shrink the cadence to something honest — than keep performing reflection every fortnight. A powerless retro isn’t a neutral waste of an hour; it actively erodes trust.
We would also cut the cadence, not the ceremony, when a team has genuinely run out of new things to say. A weekly retro on a team where nothing has changed decays into a tick-box ritual. That’s a frequency problem, not proof retros are worthless.
The practical take
- Redefine success as learning, not action items. Aim for one real change or one shared insight per retro, and review last time’s at the top of this one. A long list is how retros become box-ticking theatre.
- Triage issues by who owns them, and escalate the ones outside the team’s control by name and date. Do not tell people to “stay in their circle of influence” if that means burying the real blocker — radiate it outward instead.
- Protect safety, because feedback banking is real. Exclude the authority figure whose presence quiets the room, keep what is said in the room, and offer anonymity as an option per idea. Psychological safety isn’t a soft nicety: Google’s Project Aristotle found it the single biggest factor in team effectiveness, building on Amy Edmondson’s research.
- Right-size the cadence. If there is nothing new to reflect on weekly, run it fortnightly. Forced reflection is its own anti-pattern.
The Scrum Guide says the retrospective is the team inspecting itself to improve. So the moment it’s being run at the team rather than by it, you’ve lost the thing that made it worth an hour. That’s the Void failure mode — reflection with nothing downstream of it — and it’s the most fixable one on this list.
Frequently asked questions
Are retrospectives a waste of time?
They are when they only produce words — when the same concerns get aired every sprint and nothing changes. But the fault is usually the follow-through and the team’s power to act, not the ceremony itself. A retro that leads to learning and small, owned change earns its hour; one that functions as a pressure valve does not.
Does a retrospective need an action item to be worthwhile?
No. The second edition of Agile Retrospectives reframes success as learning, not a to-do list — a retro where the team genuinely understood something is not a failure just because it produced no ticket. Chasing action items for their own sake is how retros become box-ticking. Aim for one real change or one shared insight, not a long list that half-vanishes into the backlog.
When is a retrospective genuinely not worth running?
In one specific situation: when the real problems are overwhelmingly outside the team’s control, leadership won’t act on what gets escalated, and the meeting has no power and no follow-through. A powerless retro isn’t a neutral waste of an hour — it actively erodes trust by teaching the team that speaking up changes nothing. Fix the escalation path or shrink the cadence to something honest rather than performing reflection every fortnight. And if the team has simply run out of new things to say, cut the frequency, not the ceremony.
Related reading
- Why retrospectives fail (and how to make yours matter) — the deep dive on powerlessness, weaponised feedback and the follow-through void.
- Why retrospectives are a useful agile tool — the case for the ceremony, made plainly.
- How to build a psychologically safe space — the antidote to feedback banking.
- Agile Theatre: the Void failure mode — reflection with nothing downstream, and how to escalate what the team cannot fix alone.
- Retrospectives in TeamRetro — run one that leads to learning, not just words.