Your retrospective is a batch process for feedback. That's exactly why it doesn't work.

Someone on your team notices a bad deployment pattern on Tuesday. Instead of raising it and fixing it, they mentally file it for Friday's retro. By Friday it's stale, half-forgotten, or it's already caused three more incidents. The retro didn't fail to catch the problem — it actively delayed the fix by giving everyone an excuse to wait.

That's the retro's original sin. It takes something that should be continuous and turns it into a ceremony. Improvement becomes a calendar entry. The default state of the team becomes not fixing things.

The Vogons of Software

Every organisation has them. The people who respond to a broken deployment pipeline not with "let's fix this" but with "let's make sure we capture this for the retro." They don't pull the emergency brake — they file a ticket about the brake.

Douglas Adams invented the Vogons as a species that would demolish your entire planet, but not before ensuring the paperwork was in order and had been available for public comment at the appropriate planning office. He meant it as satire. Somehow, the software industry read it as a methodology.

These people are not evil. They are, like their literary counterparts, simply incapable of distinguishing between process and progress. They measure success in ceremonies completed, not problems solved. They have read the Agile Manifesto and somehow concluded that the point was more meetings.

Toyota Solved This Before Software Existed

Sakichi Toyoda understood the instinct to defer problems in the 1890s. He built a power loom that automatically stopped when a thread broke — preventing defective fabric from being produced while nobody was watching. He called the principle jidoka: automation with a human touch.

When Taiichi Ohno scaled this thinking to car manufacturing in the 1950s, he gave every worker on the assembly line an andon cord — a physical rope they could pull to halt the entire production line the moment they spotted a defect. Not at the end of the shift. Not in a Friday meeting. Immediately.

The result was counterintuitive. Managers who implemented stop-the-line saw productivity collapse — teams spent their time fixing problems instead of producing cars. The managers who ignored Ohno kept their numbers up and felt vindicated.

But within months, the stop-the-line teams were producing faster, cheaper, and more reliably than the teams who'd let defects pass downstream. The initial investment in fixing things immediately paid compound interest. The teams that batched their problems paid compound debt.

A Vogon would have looked at Ohno's andon cord and immediately asked who was authorised to pull it, whether there was a form to fill in first, and whether the cord-pulling had been approved in the last sprint planning session. Ohno's answer was simple: everyone pulls the cord, nobody fills in a form, and if you see a defect and don't stop the line, that's the failure.

The Retro Is the Anti-Andon

A retrospective is the structural opposite of an andon cord. Where jidoka says stop now and fix it, the retro says log it for later. Where Toyota empowered every worker to halt production, the retro teaches people to defer action until a ceremony gives them permission.

And the batching compounds the damage. Six issues in an hour means everything gets shallow treatment. Context is gone. Energy is gone. You get a list of vague action items disconnected from the moment that produced them. Same problems surface two weeks later. Same sticky notes. Same theatre.

The Vogons love this, of course. A retro produces artefacts — boards, action items, Confluence pages. It generates the paperwork that justifies the process that mandates the meeting. Nothing changes, but the ceremony was observed.

A Better Meeting Already Exists

If you still need a structured meeting — and most teams do — the Entrepreneurial Operating System's IDS method is a far better model. IDS stands for Identify, Discuss, Solve, and it treats issues the way Toyota treats defects: as things to be eliminated permanently, not recycled.

Issues go onto a running list the moment they're spotted. In the weekly meeting, the team picks the top three by priority and works each one: identify the root cause, not the symptom. Discuss it until everyone understands. Solve it with a concrete action, an owner, and a deadline.

No "what went well." No check-in round. No facilitation theatre. A Vogon would hate it — there's no room for process about the process. Just: what's broken, why, and what are we doing about it right now?

The critical difference is philosophical. A retro asks you to reflect. IDS demands you resolve. You don't leave the room until the issue is solved or someone owns the next step. Issues that aren't closed carry forward with priority — they don't evaporate into a wiki page nobody reads. It's Ohno's andon cord in meeting form: stop, identify the root cause, fix it permanently, move on.

Kill the Ceremony, Build the Culture

If your team needs a fortnightly retro to surface problems, you haven't built a culture of improvement — you've built a pressure valve on a two-week timer. The Vogons are running your engineering process, and they're doing it by the book.

Replace the retro with a running issues list and a meeting that exists to solve, not to reflect. Better yet, build a team where most issues never reach the meeting because they're raised and fixed in real time — and the meeting exists only for the structural problems that genuinely need the room.

Toyota figured out stop-the-line before your grandparents were born. EOS figured out IDS two decades ago. The retro has had its chance.