On Agile theatre

the argument worth having

Everyone who has done Agile for any length of time has already stopped believing in the rituals. The standup as a recital of the board, the sprint as a fortnight of theatre, the retro with the columns, the certification on the LinkedIn profile. The “Agile theatre” critique is consensus now. It is not contrarian to say the ceremonies have gone hollow. It is the room’s collective shrug.

The interesting argument is not that the rituals are hollow. It is that agentic engineering finally ends Agile in the way we have come to know it in the last decade. It does that by changing the shape of the work underneath the rituals so completely that the rituals have nothing left to coordinate.

This post is about what working software looks like when an agent does the engineering, and why the certified version of Agile cannot survive that shift. The Manifesto can. The industry that grew around it cannot.

what the Manifesto actually said

Seventeen people sat in a ski lodge at Snowbird, Utah in February 2001 and wrote a one-page document. You can read the Agile Manifesto in under a minute. Four trade-offs and twelve principles. Individuals and interactions over processes and tools. Working software over comprehensive documentation. Customer collaboration over contract negotiation. Responding to change over following a plan. Underneath there is a qualifier almost nobody quotes: “while there is value in the items on the right, we value the items on the left more.”

That is the whole thing. There is no standup in it. There is no story point. There is no two-week sprint. There is no Jira board, no retrospective, no scrum master, no certified anything. There is a principle that face-to-face conversation is the most efficient way to convey information. There is one about simplicity being the art of maximising the amount of work not done. There is one about motivated individuals being given the trust to get the job done.

The Manifesto already named the right things. AI has not invalidated it. AI has made the things on the left side of those four trade-offs cheap, and made the things on the right side, the processes and tools and documentation and plans, look like the expensive scaffolding they always were.

Twenty-five years on, the people who wrote it have spent the second half of their careers trying to take it back. Martin Fowler, signatory, popularised the phrase “Agile Industrial Complex” in a 2018 talk in Melbourne. “What I’m hearing so much is the Agile Industrial Complex imposing methods upon people, and that to me is an absolute travesty,” he said. Dave Thomas, signatory, gave a talk called “Agile is Dead” in 2015 and used a line I keep coming back to: “‘Agile’ is now used with software products the way ‘Natural’ is used with food.” Andy Hunt, signatory, wrote in 2015 that “the word ‘agile’ has become sloganized; meaningless at best, jingoist at worst.” Ron Jeffries, signatory, wrote that “it breaks my heart to see the ideas we wrote about in the Agile Manifesto used to make developers’ lives worse, instead of better”, and a year later, of an invention he is widely credited with: “I may have invented story points, and if I did, I’m sorry now.” Ken Schwaber, co-creator of Scrum, attacked the most-adopted scaling framework for Agile in a 2013 post titled “unSAFe at any speed”.

When the founders of a movement spend a quarter-century trying to disown the thing they founded, you should at least look up from your sprint planning and wonder why.

how the rituals decoupled from the work

The daily standup is not from rugby. The name Scrum is from rugby, by way of a 1986 Harvard Business Review paper by Takeuchi and Nonaka that Jeff Sutherland read in the eighties. The meeting itself, the fifteen minutes, the standing up so that nobody gets comfortable, the three questions, comes from Extreme Programming. Kent Beck formalised it at Chrysler in 1996. Scrum borrowed the form and inherited the rugby brand, and most teams running a “daily scrum” today are doing an XP ritual under a Scrum logo without noticing.

That mismatch is the whole story in miniature. The rituals decoupled from the practice almost immediately. The certifications came next. Scrum.org currently reports something north of 1.18 million Professional Scrum certifications. Scrum Alliance reports roughly 1.8 million members. Scaled Agile Inc. claims around two million SAFe-certified professionals trained across twenty thousand organisations. Roughly five million people who have paid for the badge over the years.

The certifications needed a syllabus. A syllabus needs an artefact you can teach and assess. You cannot certify someone in “responding to change over following a plan”, so the certifying bodies reified the artefacts instead. The standup. The sprint. The story point. The burndown chart. The retrospective with the columns. The board with the swim lanes. None of which were in the Manifesto. All of which became, in most organisations, what the word agile means.

Atlassian built a company around the fact that the ceremony reads out the tool. The Industrial Complex Fowler named is a certification industry, a tool industry, a consultancy industry, a scaled-framework industry, all of them with a commercial stake in the rituals being the answer. That is supporting context. The thing I actually want to write about is what happens to the rituals now that the work underneath them runs at a different speed.

what happens to Agile when an agent does the engineering

The two-week sprint was a compromise. Long enough to fit a meaningful slice of work, short enough that the wrongness of yesterday’s plan could be corrected before it became expensive. In 2001 a fortnight was a reasonable estimate of how long it took to ship a feature that worked. The sprint was a cadence chosen to match a cycle time.

That cycle time has been falling for twenty years. Deployment pipelines got faster. Feature flags removed the release as a bottleneck. Trunk-based development removed the merge as a bottleneck. The slowest part of shipping software, by 2020, was not the engineering. It was the coordination.

Agents collapsed the residue. A senior engineer pairing with a working set of capable agents can take a clear slice of work from idea to merged pull request in a morning. The slice the sprint was sized for, two weeks of estimable effort, now ships before the standup that was meant to coordinate it has finished. That is not a forecast. That is a description of what teams I work with are doing this quarter.

The rituals were doing specific jobs. Each one is now doing a different job, or no job, depending on whether the team has noticed. Take them in turn.

The standup surfaced blockers. Agents do not have blockers in the same shape. They do not get stuck waiting on someone else’s pull request, they do not get pulled into a meeting, they do not have a bad morning. What they have, instead, is a specification problem. The blocker has moved upstream, out of the engineering, and into the deciding. The standup’s primary function, shared awareness of who is stuck on what, is now mostly a question of who is unsure what to build. That is a different conversation, and it does not happen at nine-fifteen every morning.

The story point estimated effort. Effort has decoupled from time. The same slice of work takes a senior engineer with the right agents thirty minutes or six hours depending almost entirely on how clearly the work is specified. The variable being estimated has stopped being the work, and has become the quality of the specification. Story points were the wrong unit for that even when humans were doing all the typing.

The pull request review used to be a peer reading a peer’s code. The PR now is, increasingly, generated by an agent under an engineer’s supervision, and the human review is the second pair of eyes on a body of code that no human typed. Sometimes it is the only pair of eyes. The review has not got less important. It has got more important, and it has changed shape. You are no longer checking whether your colleague understood the problem. You are checking whether the model did, and whether the engineer caught it when it did not.

The retrospective learned from the sprint. The sprint was a fixed window. The agent learns from each prompt, each correction, each rejected suggestion. The cycle of learning that the retro was riding has moved inside the day, inside the hour, inside the loop the engineer is running with the model. The human retro, on a two-week clock, is reviewing a learning process that has already iterated a hundred times underneath it. That is not nothing. It is on a slower clock than the work, and the work has not waited.

The deciding has become the slow part. What to build. Whether it is worth building. Whether the build matches the thing the person asking for it actually wanted. The rituals were designed for a world where engineering was slow and decisions were stable. We have the opposite now. Engineering is fast and decisions move every conversation. The fortnightly cadence is a coordination overhead that no longer matches anything underneath it.

What you actually want, at this cycle time, is a view of the work in flight, a limit on how much of it you let into flight at once, and a discipline of finishing what you start before you start more. That is a kanban board with a work-in-progress limit. It is not a sprint.

kanban over scrum, and the lost twin

Scrum got the marketing. Kanban got the work. The kanban approach in software was named by David Anderson in the late 2000s, but its roots are older, in the Toyota Production System and in the Lean Software Development book that Tom and Mary Poppendieck wrote in 2003. The Poppendiecks took the same ideas the Manifesto authors took from the same lineage, and they wrote a version with no certification industry attached. They got drowned out. Scrum had a sales engine. Lean had a textbook.

The kanban view fits agentic work in a way Scrum never will. The unit of work is the slice, not the sprint. The slice is whatever a human-plus-agents pairing can ship from idea to merged in a day or two. The board is a window onto flow. The work-in-progress limit is the constraint that matters, and the thing the limit is binding on has changed. It used to be engineering capacity. It is now human attention, specifically the capacity of the engineer in the loop to review, correct, and stand behind what the agents are producing. Engineering capacity is no longer the scarce resource. Reviewing capacity is.

That reframes the board. Each in-flight card represents an engineer’s commitment to keep their eyes on a slice of agent-assisted work until it is shipped and standing up. It does not represent two days of someone’s engineering time. Three to five cards is plenty. More than that and the human cannot honestly say they reviewed any of it. The limit is binding on the human, not on the throughput.

Several of the teams I most respect have ended up at variants of this without using the word kanban. Linear’s method says it directly: “Create momentum – don’t sprint”. Basecamp’s Shape Up, Ryan Singer’s free book, replaces the sprint with a six-week cycle and a two-week cool-down, with no daily standup at all. GitLab’s handbook is async-first, with the handbook itself as the single source of truth. Stripe writes long-form internal documents and prizes writing over meetings. None of these teams perform Scrum. They are agile in the original sense, and they happen to be well-placed for the shape work has taken this year.

Being agile is what the Manifesto described. Doing Agile is what the certification industry sold. AI is making the first one cheap, and most teams are still buying the second one.

the strongest case against me

If the prescription does not survive the counter-argument it is not worth writing down. There are four good ones.

The first is empirical. Viktoria Stray and her collaborators have spent a decade studying the daily standup, and the honest summary of their findings is that the standup correlates with positive outcomes when psychological safety on the team is already high. The ritual is not the active ingredient. The room is. A founder who bins the standup without replacing the function it was performing, which is shared situational awareness, is removing scaffolding that, for some teams, was the only forcing function holding the team in the same reality. The right read of Stray is not that you should keep the standup. It is that you should be specific about what the standup was doing, and replace the function with something that does the same job better. A short written update at end of day. A narrow Slack channel with a norm. A Friday demo. Most teams that bin the standup and replace it with nothing get worse before they get better.

The second is structural. Mike Cottmeyer at LeadingAgile has engaged Fowler’s Industrial Complex critique directly and answered it with a sharp version of: some imposition is necessary, because most enterprises do not have the technical excellence or the trust to self-organise their way out. Cottmeyer is not wrong about enterprises. The rituals are scaffolding for teams who have not built the muscles yet. The honest version of my argument is that scaffolding works, scaffolding has a purpose, scaffolding is fine. The problem starts when the scaffolding becomes the building.

The third is the privilege reading. Linear, Shape Up, GitLab, Stripe, and the post you are reading all share a strong precondition. They assume a small team of senior, literate, motivated people who can write well, self-direct, and hold context without being herded. Most teams in most companies are not that team. Camille Fournier’s “Make Boring Plans” is the most charitable version of this objection. The ceremonies are training wheels. You should not write a post telling people on training wheels to ride no-handed.

The fourth is the one that has emerged this year, and I think is the most important to address. The argument is that agents need more ritual, not less. New failure modes need new verification. Hallucinated code that compiles but is wrong. Silent regressions in behaviour the team did not write tests for. Drift in what the model considers idiomatic between Tuesday’s session and Thursday’s. Prompts that quietly do different things in different repos because the context is different. The case for ceremony is that you need a prompt governance review, an eval gate on every model-touched PR, a hand-off ritual when one engineer’s agent session is picked up by another engineer, a model-of-record document for what version of what tool wrote which lines. The argument has the weight of every previous “new technology, new ritual” argument, and most of those rituals were correct in their time.

I take it seriously and I reject it. The new failure modes are real. The ritual answer to them is wrong. The verification belongs in the tooling, not in the team’s daily meeting. The eval gate belongs in CI. The hallucinated code belongs in the test suite the agent is required to run before it opens the PR. The drift in idiom belongs in a shared house-style document the agents read on every run. The model-of-record belongs in the commit trailer. The prompt governance belongs in the prompt library the team maintains together, version-controlled, the same way the codebase is. Every one of those problems is solved by treating the agent as a peer who needs a working environment, not by adding a meeting where humans rehearse the problem to each other. The temptation to answer new failure modes with new ceremony is exactly the temptation that turned the Manifesto into a certification industry the first time. The cost of giving in to it twice would be embarrassing.

I take the first three seriously too. The first means the prescription has to be specific, not a clearance sale on rituals. The second means I am writing for small teams, not enterprises, and I should say so. The third means the prescription is a privilege some teams have to build their way into rather than a default.

being agile, not doing Agile

Here is how I think a small software team should work in 2026.

The team is small. Two to six people. A designer plus two to four engineers, not a startup department. Above a handful, the coordination problem grows faster than the working problem, and the rituals I am attacking start to earn their keep again. This is not a flat structure for five hundred people. It is a working pattern at the scale of a team that fits round one table.

The board is kanban. Three states. Backlog. In Progress. Done. The work-in-progress limit is on human attention, not on engineering velocity. Roughly the size of the team, sometimes smaller. If a card is stuck, the team fixes the stuck before pulling the next card. The board lives in whatever tool is least obtrusive, and the rule is that the tool serves the team, not the other way round.

There is no sprint. There is no story point. There is no estimate other than an honest sentence about whether the work is small, medium, or large. There is no sprint planning, no sprint review, no grooming.

There is no daily standup. There is a short written update at the end of each day, in a single channel, from each person who shipped or got stuck on something. Three lines. What the agent shipped under the engineer’s supervision today. What the engineer had to teach it. What the engineer is not yet willing to trust it with. The written form replaces the meeting form because writing is asynchronous, leaves an artefact, and forces the writer to think for two minutes before broadcasting. If two people need to talk, they talk. They do not need a meeting to give them permission.

There is a weekly written review on a Friday afternoon, ten minutes to read, that says what shipped, what is stuck, what the team learned this week, and what the team had to teach the agents. The retro question has changed. It is not what did we get wrong as a team. It is what did the agents get wrong this week that we have to teach them, what new capability did we add to their toolkit, what new thing are they now trusted to do unsupervised.

The pull request review takes on more weight, not less. The engineer is reviewing more code than they wrote. They are the named human standing behind code they did not type. That is a real responsibility and it should be paid attention to. PR reviews are not a place to compress. They are the place the team’s standards live now.

The customer is in the loop continuously, not on a sprint cadence. This is what “customer collaboration over contract negotiation” was always supposed to mean. The cost of finding out you are building the wrong thing has collapsed by another order of magnitude this year, because the thing is in front of the customer in a day instead of a fortnight. The ritual designed to amortise that cost is no longer pulling its weight.

The test for whether a ritual is doing real work is simple. Stop performing it for a month. If the team gets worse, put it back. If nobody notices, leave it off.

what I am building from here

The next things I build are not going to look like the last twenty years. The hierarchy is going. The titles are going, as I wrote about in the previous post. The sprint is going next. The rituals that survive are the ones doing real work for the team in front of me, and the test for whether a ritual is doing real work is the one above.

The post before this one was about the CEO badge doing identity work I had not asked it to do. The Scrum Master badge has been doing the same thing for fifteen years. The senior engineer badge is doing it right now, this quarter, in real time, for everyone whose job description has just been refactored under them by a tool they did not ask for. AI is forcing the identity question for every role at once. Some of the badges will survive the question. Some of them are going to come off the chest the way mine did, quietly, and the person wearing them is going to feel the join where the welding used to be.

The way I am choosing to work in this next chapter is closer to the Manifesto than anything that got sold under its name for the last twenty years. Small teams. Kanban flow, not sprints. Agents in the loop. Written async over meetings. The customer in the loop continuously. Working software over comprehensive documentation, customer collaboration over contract negotiation, responding to change over following a plan. That is what those seventeen people at Snowbird were trying to describe. The certifications are not heirs to that document. The way I work now is.

I would rather be agile than do Agile. The Manifesto was written by seventeen people in a room who already were the first thing, and the industry that followed them spent twenty-five years selling the second one. AI has collapsed the friction the industry was pretending to solve. The trade-off the Manifesto authors named in 2001 is finally available on the terms they wrote it down on.

Be agile. Stop doing Agile. The badge on the office door does not predict any of it. Neither does the one on the standup grid.