The Agile Theatre Diagnostic

Agile theatre is the condition in which an organisation has adopted every visible artefact of an agile way of working and none of the properties those artefacts were designed to produce. The boards exist. The ceremonies run on schedule and are well attended. The vocabulary is fluent — people say backlog, sprint, increment, blocker, and they say them correctly. There are certified practitioners, a community of practice, and a maturity dashboard that is mostly green.

And nothing about how software reaches customers is different from five years ago.

This is extremely common, and it is not usually the result of cynicism. It is what happens when the observable parts of a way of working are adopted and the causal parts are not — the same mechanism described in the-spotify-model-was-never-a-model, operating at the level of practice rather than structure. Ceremonies are cheap to install and can be mandated. The things ceremonies are meant to enable — short feedback loops, decisions made by the people with the information, work that reaches users quickly enough to learn from — require changing funding, governance, architecture and authority, none of which can be mandated by a delivery function.

The difficulty is that theatre is genuinely hard to see from inside, because every individual element looks correct. Maturity assessments make this worse: they ask whether the practices are being followed, and in theatre the practices are followed meticulously. What you need instead is a small number of questions that bypass the practice layer entirely and interrogate outcomes. Those questions are below, and they are deliberately awkward.

How to recognise it from the outside

Before the questions, the ambient signals. None is conclusive; three or more together usually are.

Improvement effort is aimed exclusively at teams. Training, coaching, maturity scoring and tooling for the delivery teams, and no work at all on funding, procurement, release governance or architecture. This tells you where the change programme's authority ends.

The measures are all about activity. Velocity, story points, sprint burndown, percentage of teams trained, ceremony attendance. Nothing about how long a change takes to reach a customer or what happened when it did.

Nobody can name something the organisation stopped doing. Genuine change removes things: a gate, a document, a committee, a role. If every existing process is still in place and new ceremonies have been added on top, the net effect is more process, not less.

The language is confident and the examples are thin. Ask for a specific instance of the team changing direction because of something they learned from users, and you get a description of the process by which such a thing would happen.

Retrospectives produce actions that concern the team's own behaviour only. More on this below, but it is the single most reliable tell in the set.

The diagnostic

Ask these of a delivery team, not of a transformation lead. Ask for specific recent instances rather than general descriptions — the phrase to use is "tell me about the last time". A team that has to reach for a hypothetical is telling you the answer.

Question	A healthy answer sounds like	A theatre answer sounds like
How long from merge to production, for a one-line change?	Hours, and someone can point at a real one from this week	It depends, or a number that turns out to be the next release train
Who can stop a release, and who can start one?	The team can start one; anyone can stop one on evidence	A board starts one; stopping it needs an executive
What happened to the last three retrospective actions?	Named, dated, two done and one abandoned deliberately	Improved communication, be better at estimating, nothing tracked
What can this team decide without asking anyone?	A specific list including technical approach and sequencing	Small things, then a pause, then how to implement what was decided
How is this work funded?	A team and a period, against an outcome	A project with a scope and a date, approved last year
When did you last remove something from the backlog because it stopped being worth building?	A concrete item, with the evidence that killed it	We reprioritise every sprint, but nothing is named
Who has spoken to a user in the last month?	A named person on the team, with what they learned	Product, via the business, at some point
What does done mean here?	Running in production with monitoring, per a written definition	Dev complete and moved to the test column
What is your change failure rate and how do you know?	A number from your own deployment records	We do not really have incidents from releases, or silence
What happened the last time a release caused an outage?	A blameless review with a specific systemic fix	A root cause analysis naming an individual, and a new checklist
When did a stakeholder demo last change the plan?	A specific instance in the last quarter	Stakeholders are very supportive of the demos
What is the biggest thing slowing this team down?	Named immediately, specific, usually outside the team	A pause, then something about estimation or focus

Two of these carry disproportionate weight.

The first is merge to production for a trivial change. It is a single number, it is measurable rather than reported, and it compresses an enormous amount of information about pipeline maturity, test strategy, environment management, governance and trust. An organisation cannot talk its way past it. If the number is measured in weeks, then whatever else is true, the feedback loop that all agile practice depends on is not running.

The second is the retrospective action question, and it deserves its own note.

Why it happens

Theatre is not laziness. Four forces produce it reliably in organisations full of competent people.

Ceremonies are the only part that can be adopted without permission. A delivery manager can introduce a standup on Monday. They cannot change the funding model, the change advisory board or the architecture review, because those belong to other functions and other executives. So the change goes as far as the authority extends and stops precisely at that boundary. The resulting shape is water-scrum-fall, and theatre is its cultural expression.

Adoption is easy to measure and outcomes are not. A programme has to report progress quarterly. Teams trained, teams with a certified practitioner, maturity score, ceremony compliance — these produce a chart within weeks. Cycle time improvement takes quarters and may get worse before it gets better. The reporting requirement selects for the measurable proxy, and once the proxy is the target it becomes the thing people optimise.

Certification and tooling supply an off-the-shelf implementation. There is a well-developed market in the visible layer: courses, roles, tools, assessments, frameworks. There is no comparable market in "renegotiate your funding model with the CFO", because that cannot be productised. Organisations buy what is for sale.

Nobody involved wants to say it is not working. The sponsor has staked credibility. The coaches are paid to deliver it. The teams have learned that scepticism is read as resistance. The result is a shared and entirely sincere performance in which everyone reports that things are going reasonably well, and the first candid conversation happens eighteen months in, usually at an exit interview.

What it costs

The opportunity cost is the largest item and it is invisible. Two or three years of change appetite, a substantial budget and the attention of good people are spent on the layer that was not the constraint. Meanwhile the deployment pipeline, the funding model and the dependency structure are untouched, and they are what determines the delivery outcome.

Cynicism accumulates and is durable. Engineers who have sat through three years of ceremonies that change nothing will not engage with the fourth initiative. They are not being difficult; they are updating on evidence. Rebuilding that credibility takes far longer than losing it, and it must be done by demonstrating a real change before asking for any behaviour at all.

The vocabulary becomes unusable. Once "agile" in your organisation denotes a set of meetings that produce nothing, the word cannot be used to describe anything useful. People proposing genuinely valuable changes have to invent new terminology to avoid the association, which is a tax on every future conversation.

Process is added and never removed. Theatre is additive by nature. The new ceremonies arrive, the old governance stays, and the total overhead rises. Teams end up with both a sprint planning session and a stage gate, both a definition of done and a handover document. The organisation is now measurably slower than before the transformation, which is the outcome most likely to produce the conclusion that agile does not work here.

The good people leave first. The engineers with options are the ones most frustrated by working in a system where their improvement suggestions go nowhere. Attrition in theatre is selective in the worst possible direction.

The treatment order

The findings from the diagnostic will be numerous. Treat them in this order, because the sequence matters more than the content and the wrong order stalls.

First, make one flow measure visible and honest. Pick merge-to-production time or end-to-end cycle time for a single value stream. Compute it from your own systems rather than asking people. Publish it, including the parts that are embarrassing. This is first because everything afterwards needs a shared factual basis, and because in theatre the primary deficiency is that nobody has an agreed number. Do this without announcing a programme.

Second, fix the release path. It is a technical problem, it has a technical owner, it needs no cultural change, and it produces a visible improvement within a quarter. Every hour removed from merge-to-production makes smaller batches rational, which makes faster feedback possible, which is the mechanism everything else depends on. This is also the step that rebuilds credibility with engineers, because it is the first time the transformation has made their actual day better.

Third, move one decision right down and write it down. Choose something concrete — the team decides its own technical approach, or the team can deploy without external approval once the pipeline checks pass. Write it down, tell the people whose approval is being removed why, and give them the replacement assurance mechanism rather than nothing. One real transfer of authority does more for behaviour than a year of empowerment language.

Fourth, change how one thing is funded. Take a single initiative from scope-and-date to team-and-outcome. This is the hardest step, it requires a sponsor with genuine authority, and it is where the transformation stops being cosmetic. Attempting it first, before there is a credible flow measure and a working pipeline, usually fails because there is no evidence to argue with.

Fifth, and only now, look at the ceremonies. By this point some of them will have become useful on their own, because the conditions that make them useful now exist, and others will be visibly redundant and can be removed without a fight. Reforming ceremonies first — which is where almost every programme starts — changes the appearance of the system and none of its behaviour.

What to do on Monday

Pick one team and one hour. Ask the twelve questions in the table, in a room, without a scoring sheet, and press for a specific recent instance every time you get a general description. Take notes on what is said and on where the pauses are, because the pauses are usually the most informative part.

Then measure one thing yourself rather than asking anyone: take the last ten changes that reached production and calculate the elapsed time from merge to release for each. Use the distribution, not the average. You will have the number by lunchtime, and it will be more useful than any maturity assessment your organisation has ever commissioned.

If that number is measured in weeks, you have your first piece of work and you do not need anyone's permission to start looking at why. If it is measured in hours, the theatre is elsewhere, and the next place to look is the funding question and the decision-rights question — because a fast pipeline attached to an annual scope commitment is a very efficient way of building the wrong thing.