What is agile theatre?
Engineering culture and software practice
Agile theatre is the practice of performing the visible rituals of Agile, such as stand-ups, sprints, boards, story points and retrospectives, without the substance that makes them work: genuine user feedback, the freedom to change the plan, and working software delivered often. Also called cargo-cult Agile, dark Scrum, water-scrum-fall or fake Agile, it produces ceremonies and a tooling bill while how work actually gets done never changes.
What this means
Agile began in 2001 as a reaction against heavyweight, document-driven ways of building software. Seventeen practitioners met and wrote a short manifesto that valued working software, close collaboration with customers and responding to change over rigid plans. The point was to shorten the loop between having an idea and learning whether it worked.
Agile theatre is what happens when an organisation adopts the visible parts of that idea and quietly drops the hard parts. The team holds a daily stand-up, moves cards across a board, estimates work in story points and runs a retrospective every fortnight. From the outside it looks modern and disciplined. Underneath, nobody talks to a real user, the plan is fixed a year in advance, and software still ships in one big lump at the end.
The term matters because the rituals are easy to copy and the substance is hard to fake. A leader who sees the ceremonies can be reassured that all is well when the thing that actually reduces risk, frequent delivery of working software that people can react to, is entirely absent.
Why it matters
Agile theatre is expensive. Transformations often produce a large bill for tools, certification and coaching, plus the standing cost of meetings that every team member attends, while delivery does not speed up and quality does not improve. The organisation pays for the form and gets none of the benefit.
It also hides risk. The whole purpose of short feedback loops is to find out early that something is wrong: a feature nobody wants, a technical approach that will not scale, a requirement that was misunderstood. When the loop is fake, those discoveries arrive at the end, when they are most expensive to fix. The board is green until the launch, and then it is not.
There is a human cost too. Boards and stand-ups can be turned into surveillance, and velocity, which was meant to help a team predict its own capacity, gets used as a productivity target imposed from above. When a measure becomes a target it stops measuring anything useful, because people optimise the number rather than the work. Teams inflate estimates, morale falls, and the best people leave.
The same disease now shows up in AI adoption programmes. An organisation runs pilots, commissions demos and announces a strategy, but the way people actually do their work does not change and no decision is ever made differently because of the tool. That is agile theatre wearing a new costume, and the tell is identical: lots of activity, no change to how the work gets done.
How it works
Where the term came from
There is no single coiner. The phrase grew out of a decade of practitioner frustration in the 2010s, built on the Agile Manifesto of 2001 and the Scrum Guide. The clearest early named critique is Martin Fowler's "Flaccid Scrum" from 2009, which described teams that adopt Scrum's management practices but neglect the technical practices, so productivity declines as the code becomes a mess. In his keynote "The State of Agile Software in 2018", the transcript of which he published on 27 August 2018, Fowler said that much of what is done is faux-agile, "agile that's just the name, but none of the practices and values", and attacked what he named the Agile Industrial Complex for "imposing methods upon people", calling that "an absolute travesty".
Ron Jeffries, one of the founders of Extreme Programming and a Manifesto signatory, coined "Dark Scrum" in an article published on 8 September 2016, a term he says he believes he coined for Scrum gone badly wrong, usually to the detriment of the team and the product, where every ceremony becomes an opportunity to pressure developers and the workplace becomes unsafe for programmers. Forrester analyst Dave West is credited with "water-scrum-fall" in 2011, describing how organisations wrap traditional waterfall planning and release around a scrum-shaped middle. In 2018 the US Defense Innovation Board, whose members included Eric Schmidt, published a short guide bluntly titled "Detecting Agile BS" to help non-technical officials tell real Agile from waterfall in agile clothing. Treat all of these as names for the same underlying disease.
The split between ritual and substance
The ritual is the set of visible events and artefacts: the stand-up, the sprint, the board, the points, the retrospective. The substance is three things the manifesto actually asked for. First, working software delivered frequently, from a couple of weeks to a couple of months, so there is always something real to inspect. Second, genuine feedback from the people who will use the thing. Third, the freedom to change the plan when that feedback shows the plan was wrong.
Agile theatre keeps the ritual and discards the substance. Sprints happen but nothing shippable comes out of them. Retrospectives happen but nothing changes as a result. Backlogs are groomed but the roadmap is fixed and politically untouchable. The tell is always the same: activity is high, but the loop that turns evidence into a changed decision is broken.
How experienced teams detect it
The Defense Innovation Board's guide is the most useful institutional detector because it is written for non-engineers. Its questions are pointed: can you see working software, and how often is it delivered to real users? Who on the team spoke to an actual user in the last week? What did the team change after the last retrospective? Are automated tests and continuous integration in place, or is testing a separate phase at the end? Is the whole ecosystem, including contracting and governance, actually agile, or just the development team?
A leader does not need to understand the code to use these. If the honest answer to "show me the working software" is a slide deck, or if nothing has changed after six retrospectives, the ceremonies are theatre. Experienced teams treat these questions as routine health checks rather than accusations.
Why it happens
Three forces drive it. Management often wants the predictability of the old world (fixed scope, fixed date, fixed price) plus the modern label, which is a contradiction the rituals paper over. A large certification and consulting industry sells the visible apparatus, because a two-day course and a set of ceremonies are far easier to sell and deliver than the slow, uncomfortable work of technical excellence and cultural change. And genuine Agile requires leaders to give up some control and tolerate visible uncertainty, which many find frightening, so they keep the comforting rituals and quietly restore command and control underneath.
Examples
A professional services firm of sixty people hires a coach and rolls out Scrum across its internal software team. Six months on there are daily stand-ups, a wall of sticky notes and a fortnightly retrospective. The client-facing portal, however, has not shipped anything since the programme began, because everything is being built for a single big release in the autumn. A partner asks the detection question, "who talked to a user this week", and the honest answer is nobody. The ceremonies are real; the feedback loop is not.
A borough council digital team adopts sprints to modernise a licensing service. The board looks healthy, but the release process still requires a change-approval board that meets monthly and a separate testing phase that takes three weeks, so working software reaches residents twice a year at best. This is textbook water-scrum-fall: an agile-shaped middle bolted between a waterfall front and a waterfall back. The fix is not more stand-ups; it is shortening the release path.
A mid-sized retailer launches an AI adoption programme. There are pilots, a steering group, vendor demos and a strategy deck. A year later, staff still process customer emails exactly as before, and no operational decision is made differently because of the tool. The programme has produced the ceremonies of transformation and none of the substance, which is the same failure pattern as agile theatre applied to AI rather than to software delivery.
Common misunderstandings
People assume that having stand-ups, sprints and a board means a team is Agile. It does not. Those are the visible mechanics; being Agile means delivering working software often, learning from real users and changing the plan on the evidence. The rituals without the substance are precisely what agile theatre is.
People think agile theatre is the same as cargo-cult programming. It is not. Cargo-cult programming is copying code or configuration you do not understand in the hope it works, a code-level habit. Agile theatre is the process-level cousin: copying the rituals of a way of working without understanding what made them effective. They rhyme, but one is about code and the other is about how work is organised.
People believe more discipline about the ceremonies will cure it. Usually the opposite is true. Enforcing stricter stand-ups and more precise story points doubles down on the form while ignoring the missing substance, and often tips into surveillance. The cure is to restore feedback and frequent delivery, not to polish the rituals.
People assume that because a respected framework such as Scrum is being followed, the result must be sound. Frameworks are deliberately light on engineering practice, which is what Fowler's "Flaccid Scrum" warned about: adopt the management shell without the technical core and progress slowly grinds to a halt regardless of how faithfully the ceremonies are run.
Risks and boundaries
The term can be weaponised. "That's not real agile" is a well-worn move that lets any critic dismiss any implementation, a version of the No True Scotsman fallacy that Jeffries himself acknowledged when writing about Dark Scrum. Calling something agile theatre should be a diagnosis backed by evidence, such as the absence of working software or unchanged plans, not a rhetorical weapon.
There is also a real debate about whether some ceremony-heavy, plan-driven ways of working are simply appropriate for the context. Not every organisation needs to ship fortnightly; regulated, safety-critical or hardware-bound work has legitimate reasons for longer cycles and heavier documentation. The problem is not ceremony as such; it is ceremony that claims to deliver the benefits of fast feedback while structurally preventing it. Naming the pattern is useful only when it points at that specific gap between claim and reality.
Finally, the folklore can outrun the evidence. Studies of agile adoption failure exist, but much of the writing on fake Agile is practitioner opinion rather than controlled research. It is persuasive and widely shared, but a leader should treat the vivid anecdotes as illustrations of a pattern, not as measured proof of its prevalence.
What to do next
Ask to see working software, not a status report. Set a standing expectation that every team can demonstrate something a real user could touch, and ask how often that reaches actual users. If the answer is always "at the end", you have found the problem.
Use the Defense Innovation Board's questions as a routine, low-drama health check. Who spoke to a user this week? What changed after the last retrospective? Is testing continuous or a phase at the end? These are answerable by anyone and expose theatre quickly.
Stop using velocity and story points as performance targets. Let teams use them for their own planning and judge the work by delivered software and user response instead. The moment a metric becomes a target imposed from above, it stops telling you the truth.
Fix the ends of the pipeline, not just the middle. If a monthly approval board and a three-week test phase bracket your sprints, shortening the release path will do more than any change to the ceremonies. Invest in the unglamorous technical practices, automated testing and continuous integration, that make frequent delivery possible.
Apply the same test to AI programmes. Judge them by whether the daily work has changed and whether any decision is now made differently, not by the number of pilots, demos or strategy documents produced.
FAQs
Is agile theatre the same as fake Agile or dark Scrum?
Yes. Fake Agile, cargo-cult Agile, dark Scrum and water-scrum-fall are all names for the same disease: the visible rituals of Agile performed without the substance of frequent working software, real feedback and the freedom to change the plan.
How can a non-engineer spot it?
Ask to see working software and how often it reaches real users, ask who spoke to a user this week, and ask what changed after the last retrospective. Vague or "at the end" answers are the giveaway.
Does agile theatre mean Agile does not work?
No. It means the substance of Agile is missing. The manifesto's core ideas, short feedback loops and frequent delivery, are what reduce risk; theatre is what you get when an organisation keeps the ceremonies and abandons those ideas.
Where did the ceremonies come from in the first place?
Mostly from Scrum and Extreme Programming, which grew alongside the 2001 Agile Manifesto. The events and artefacts were meant to support fast feedback and frequent delivery, not to be an end in themselves.
Why do organisations fall into it?
Because managers often want old-world predictability with a modern label, a large certification industry sells the visible apparatus, and genuine Agile requires leaders to tolerate uncertainty and share control, which is uncomfortable.
Can AI adoption suffer from the same thing?
Yes. Pilots, demos and strategy decks with no change to how work is actually done are agile theatre in another form. The test is whether daily work and decisions have genuinely changed.
What is the single fastest way to recover?
Insist on frequent delivery of something real that users can react to, and make sure retrospectives lead to at least one concrete change. That restores the feedback loop the theatre was hiding.