Void: when the ceremony changes nothing

The fourth failure mode of agile theatre: the follow-through void. When the retro produces words and only words, becomes a pressure valve for problems out of the team's control, and how to triage, escalate and learn instead.

The deadliest failure mode isn’t a bad ceremony. It’s a good one that changes nothing.

A stand-up can be captured, a planning session can be overloaded, and the team will still feel the friction and push back. The follow-through void is worse because it feels fine. The retro runs, people are candid, sticky notes get written, everyone nods — and then the sprint turns over and not one thing is different. Do that a few times and you don’t get anger; you get something quieter and more corrosive. As one engineer put it on Hacker News, “retrospectives allow airing concerns, but nothing really ever happens of those concerns in my experience.” Another, more bluntly: “I have never seen anything happen besides words.” This is the single most-repeated complaint about retrospectives anywhere, and it is not the complaint our industry’s advice thinks it is.

Words, and only words

The standard framing is that teams “forget to write action items,” so the standard fix is to write better ones — make them SMART, assign an owner, add them to the board. It misses the actual pathology. The problem is rarely that no action was written; it’s that the action was written, added to the backlog, and then sat there forever while the next retro generated three more. “I’ve repeated the same retrospective items sprint over sprint without them being addressed,” runs one resigned account. “This sticky will not be addressed. It’s kind of sad.” By one commonly-cited survey, only about a third of teams consistently complete their retro action items — and the other two-thirds are learning, sprint by sprint, that the ceremony produces words and only words. Treat the folklore with care, though: our own first-party data on what percentage of retrospective action items actually get done puts completion nearer three in four — and shows ownership and cadence, not effort, decide the gap.

The fix that actually holds isn’t more actions — it’s fewer. Cap it at one. A single improvement the team genuinely commits to, reviewed at the very top of the next retro before anything else happens, beats a list of ten that all quietly lapse. Make too many action points and half won’t get done — and the half that don’t teach the team that none of it counts. One item, owned, with a review date, closes the loop that a long list leaves open. Our retro guide’s why retrospectives fail chapter covers running that loop from inside the ceremony, and the box-ticking retro in the Performance chapter is what the void looks like before the team gives up entirely.

The pressure valve

But there’s a deeper version of the void, and it’s the one our industry’s advice gets backwards. Sometimes the actions don’t happen because the team was never going to be able to make them happen — because the real problems are genuinely above the team’s pay grade. Budget, headcount, cross-team dependencies, an architecture decision made two levels up, a deadline set by sales. The team can name these all day. It cannot fix any of them. And so the retro becomes a pressure valve: a place to let off steam so leadership can feel the team has been heard, with no mechanism to change the thing being vented about.

vs feedback in Owner Pressure valve input in, nothing out Radiator pushed out to an owner
A valve releases just enough steam to change nothing; a radiator pushes the same issue outward to a named owner. The next section turns one into the other.

The sharpest statement of this comes from a developer writing on dev.to, and it’s worth quoting in full: “the retrospective became a pressure valve. Appearance of voice without substance of power.” The same essay lands the point that should make every coach uncomfortable: “blaming facilitation is like blaming the suggestion box for management not reading the suggestions.” You cannot facilitate your way out of a power problem. And on Hacker News, plainly: a retro is “a ceremony without actual purpose because usually the deeper things that people bring up are not within that team’s power to control” — and worse, “it gives leadership an excuse for not fixing things.”

Here is where most vendor advice does real harm. The standard anti-pattern list tells teams to “stay within your circle of influence” — stop raising things you can’t change. Framed as the team’s discipline problem, that advice is exactly wrong. It tells the team to bury the real blocker and reflect only on the small, safe, team-controllable stuff, which is precisely how a retro turns into comfortable theatre. Staying in your circle of influence is bad advice when the most important thing in the room is outside it.

Radiate outward, don’t vent inward

The good news is that the canonical text already wrote the fix — and it’s the current edition that did it. The second edition of Agile Retrospectives (2024), with David Horowitz joining Esther Derby and Diana Larsen, added a whole chapter on issues beyond the team’s control — the pain got acute enough that the canon caught up. Three of its tools are the antidote to the pressure valve:

  • Circles & Soup — sort every issue by who owns it: what the team controls, what it can influence, and what’s in the “soup” it can only respond to. This is triage by ownership, and it replaces “stay in your circle” with “route each issue to whoever can actually act on it.”
  • 15% Solutions — for the big, stuck problems, find the slice the team can start on now without anyone’s permission. Not the whole fix; the 15% of it that’s within reach. Momentum on a fraction beats paralysis on the whole.
  • Retrospective Radiators — make the escalated issues visible outward, on a board leadership can see, tracked over time. A radiator is the opposite of a valve: a valve releases pressure and hides it; a radiator broadcasts the unresolved item until someone with the power to fix it does. Escalate the red ones by name.

That’s the hard line the research points to, and it’s canon-backed: triage by ownership, escalate red items by name and date, radiate rather than vent. A retro that does this is honest about power. A retro that skips it is a pressure valve with a facilitator.

Learning is the point, not the to-do list

The last reframe closes the loop on the whole mode. The second edition also shifts the success criterion itself — from action items to learning. The second edition’s position — and it’s a relief to hear it from the canon — is that a retro without an action item isn’t a failure if the team learned something. The unit of change becomes an experiment — a hypothesis you test with a review date — rather than a to-do that rots in the backlog. “We think pairing on the deploy will cut our rollback rate; we’ll try it for two sprints and check” is an experiment. “Improve deploys” is a sticky note that dies.

Action item “Improve deploys” backlog words, and only words Experiment EXPERIMENT We think X… Try — 2 sprints Review ▸ a date learned a change you’re running Judge a retro by what it learns, not the to-dos it lists.
An action item like “improve deploys” rots unowned in the backlog; the same intent framed as an experiment — a hypothesis with a review date — is a change the team is actually running.

It also dignifies a cost that never makes it onto anti-pattern lists: the emotional tax of the pure venting session. As one participant put it, a retro can be “an hour plus of sitting there mostly listening to other people complain about stuff, which bums me out.” A venting-only retro doesn’t just fail to fix things — it taxes the people who absorb the complaints. The fix isn’t to ban feelings; it’s to give them an exit: convert the red items into owned, dated, radiated experiments, and the hour stops being a place where frustration just circulates.

That’s the way out of the void, and out of the guide. Run the loop small enough to close it, triage honestly enough to escalate what the team can’t fix, and measure learning rather than counting actions — because candor that changes nothing eventually stops being candor. The four modes — Performance, Power, Overload and the Void — are, in the end, the same question asked four ways: is this ceremony doing its job, or just performing it?

Frequently asked questions

What do you do when the same issues come up every single retro?

Diagnose why they recur, because two different failures look identical from the inside. If the action was written but never owned, it rots in the backlog while the next retro adds three more — cap it at one owned item with a review date, and open the next retro by checking it. If the issue keeps coming back because it is genuinely outside the team’s control, re-listing it will never work: triage it by who owns it and escalate it upward by name and date instead of venting again.

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

Don’t coach the team into raising smaller problems — that’s how a retro becomes theatre. Triage every issue by who actually owns it, then escalate the red ones upward with a name and a date attached, and make them visible on a retrospective radiator so they can’t be quietly dropped. Staying inside your circle of influence is bad advice when it means burying the real blocker.

How do we get retrospective action items to actually get done?

Cap it at one. A single improvement the team genuinely commits to, reviewed at the very top of the next retro before anything else, beats a list of ten that all quietly lapse. Give it an owner and a review date, and treat it as an experiment with a hypothesis rather than a chore on a list.

Does a retrospective need an action item?

No — and insisting it does is part of the problem. The second edition of Agile Retrospectives reframes the success criterion as learning, not action items: a retro where the team genuinely understood something new isn’t a failure just because it didn’t generate a to-do. Run experiments you can learn from, not tasks you’ll feel guilty about.