In my last book I defended Scrum. I wrote a whole chapter arguing that, read carefully, the Scrum Guide already contains the answer to what coding agents are doing to software teams: timeboxes are caps, refinement is prompt writing, the Definition of Done is the constraint that keeps plausible code out of production. I believe every sentence of that chapter. It is also the polite version.
This is the other one.
Picture a team. Most teams working with agents this year will recognise it. Five developers, a Product Owner, a Scrum Master, two-week Sprints. On the Monday, Sprint Planning commits to eight backlog items. By the Tuesday afternoon, agents have drafted all eight. Not perfectly: two need rework, one misunderstood the acceptance criteria, one invented a framework method that does not exist. But the code exists, and so do the tests, and the pull requests are open.
Then the team waits. It waits for review, because five people cannot carefully review what eight agents produced in a day and a half. It waits for the Daily Scrum, where everybody reports that they are “working on” things that were written on Tuesday. It waits for the Sprint Review, nine days later, to show stakeholders work that was finished before the stakeholders had finished their coffee. The calendar says the team is in the middle of a Sprint. The work says the team is in a waiting room.
Nobody in that room is doing Scrum badly. That is the uncomfortable part. They are doing exactly what the Guide describes, and it no longer fits the work.
What Scrum Was Built For
Scrum deserves a fair hearing before it gets a harsh one, because what it got right, it got very right.
It was born in the 1990s as a reaction to a specific disease: large projects planned in full before anyone wrote a line of code, built for a year, delivered late, and wrong. The cure was empiricism. Do a small amount of work, look at it, decide what to do next. The 2020 Guide still says it plainly: Scrum is founded on empiricism and lean thinking, and its three pillars are transparency, inspection and adaptation.
Everything else in Scrum is machinery to make those three pillars happen in a world with one defining constraint. Building software was slow, expensive and uncertain. A usable piece of it took days or weeks of skilled human labour, and that labour was the scarcest resource the organisation had.
Read the Guide again with that constraint in mind and every structure falls into place. The Sprint is a fixed container, a month or less, because building a usable increment took about that long and you needed a regular moment to inspect it. The Product Owner orders the backlog because developer capacity was scarce and somebody had to decide what it was spent on. The team is small and cross-functional because the people building were the bottleneck, so you removed every handoff between them. The Daily Scrum exists because those people needed to coordinate their scarce hours. Estimation exists because you needed to know how much of the scarce thing a piece of work would consume.
It was a brilliant design. For that constraint.
The Premise That Broke
The constraint is gone.
Not entirely, and not for every kind of work. But for a large and growing share of what software teams do, producing a working change is no longer the slow part. An agent drafts the migration, the controller, the tests and the documentation in minutes. It does it competently most of the time and plausibly all of the time.
What did not get cheaper is everything around the code. Deciding which change is worth making. Knowing whether the change that was made is actually right, which, when the author is a model that produces confident, idiomatic, entirely invented API calls, is a real job and a slow one. Integrating forty individually correct changes into a system that still makes sense. Being accountable at three in the morning for what was merged.
The scarce resource moved. It used to be building. It is now judgement: deciding and verifying.
And here is the problem with Scrum, stated as precisely as I can. Every structure in the Guide is shaped around the old scarcity, and there is almost nothing in it shaped around the new one. That is not a problem of practice. It is a problem of design.
The Sprint Is a Batch
Start with the heart of it. The Guide calls Sprints “the heartbeat of Scrum“, fixed-length events of one month or less, and it is right that they were. They were also a batch: a quantity of work started together, inspected together and delivered together, sized to how long building took.
Lean thinking, which the Guide names as one of its two foundations, has a firm opinion about batches. Large batches hide defects, delay feedback and create inventory. You shrink the batch until the cost of handling each one is the limiting factor. When building took two weeks, two weeks was a reasonable batch. When building takes an afternoon, a two-week batch means your feedback loop is ten times slower than your production. You are not iterating. You are queueing.
Scrum’s defenders have an answer, and it is a good one, so let me give it its full weight. The Guide says that multiple Increments may be created within a Sprint, that work can be released at any time, and that the Sprint Review should never be considered a gate to releasing value. Nothing in Scrum stops you from shipping on the Tuesday.
True. But look at what still runs on the Sprint’s clock. The Sprint Goal, a commitment made at the start about what the whole Sprint will achieve, made before the team discovers that the work it was planning for would be done in a day. Sprint Planning, which forecasts a batch. The Sprint Review, the main moment of inspection with stakeholders. The Retrospective, the main moment of adaptation. The pillars of empiricism, inspection and adaptation, are scheduled on the batch. You can release continuously and still only learn every two weeks, and learning was the whole point.
A framework built on empiricism that fixes the frequency of its own inspection, regardless of how fast the work underneath it now moves, has stopped being empirical about itself.
Estimation Measures a Dead Variable
The Guide is careful here. It does not mandate story points, velocity or any particular estimation technique; it says only that Developers size the work in refinement and that the Sprint forecast should fit their capacity. Story points are a community habit, not scripture.
But the habit grew out of the design, because the design needed it. If the Sprint is a container and developer capacity is the thing it contains, you need a unit to measure how much of that capacity each item will consume. Whatever the unit, it was always a measure of effort to build.
Effort to build is now close to zero for a great deal of work, and close to unpredictable for the rest, because whether an agent nails a change in four minutes or produces four hours of confident nonsense depends on things no refinement session can see. The estimate measures a variable that no longer constrains anything.
Velocity is worse, because it has stopped being merely useless and started being dangerous. Agents inflate it. A team that sized work by writing effort sees everything shrink, takes more into the Sprint, finishes more items, and watches the chart go up. Value does not go up with it. Review queues get longer, escaped defects get more plausible, and the team’s dashboard reports the best quarter it has ever had. Teams that optimise for velocity in 2026 are not measuring productivity. They are measuring inventory and calling it progress.
The Accountabilities Ration the Wrong Thing
The 2020 Guide replaced “roles” with “accountabilities“, and the word is exactly right, so let us take it seriously and ask what each one is accountable for.
The Product Owner is accountable for maximising the value of the product resulting from the work of the Scrum Team, chiefly by ordering the Product Backlog. Ordering is rationing. It answers the question: given that we cannot build everything, which things do we build first? When building was scarce, that was the most important decision in the room. When building is abundant, the ordering question does not disappear, but it changes shape. The hard question is no longer “what do we build first?” It is “what is worth building at all, now that we could build all of it, and what will it cost us to own?” That is closer to product strategy than to backlog management, and the Guide gives the Product Owner no tools for it beyond the backlog.
The Developers are defined as the people committed to creating any aspect of a usable Increment each Sprint. Creating. In a team working with agents, what the Developers mostly do is not create. It is specify, verify and integrate: write the item precisely enough that an agent can act on it, check that what came back is right, and make sure forty right changes still form a coherent system. The Guide mentions instilling quality by adhering to a Definition of Done, which is close. But it describes the Developer as a builder who also checks. The job has become a checker who also builds.
The Scrum Master is accountable for the Scrum Team’s effectiveness, by establishing Scrum as the Guide defines it. And that is precisely the trap. A Scrum Master who does the job well establishes a process whose bottleneck has moved, defends events whose timing no longer matches the work, and coaches estimation of a variable that no longer constrains anything. The better they are at Scrum as written, the more faithfully they keep the team in the waiting room.
Now ask the question that matters. Who, in the Guide, is accountable for verification? For the scarce thing? The honest answer is: everyone and no one. It is folded into the Developers' commitment to the Definition of Done, alongside creating, alongside everything else. In a world where verification is the bottleneck, the framework has no one whose job it is.
The Events Ask Yesterday’s Questions
The Daily Scrum is a fifteen-minute event for the Developers to inspect progress toward the Sprint Goal. In practice, and the Guide’s own framing invites it, it is a conversation among producers about what they are producing. When production is done by agents in minutes, the producers have very little to report. The question that matters, what is waiting to be verified, and for how long?, is not the question the event was built to ask.
The Sprint Review inspects the Increment with stakeholders. With agents, the Increment is large, and the temptation is to demonstrate it: forty pull requests, six features, a slide with the velocity on it. Stakeholders are impressed by volume because volume is what they can see. Whether any of it works, whether it is right, whether it will survive real users, is invisible in a demo, and the event has no structure that makes it visible.
The Sprint Retrospective is the only event that survives the shift intact. Its purpose is to plan ways to increase quality and effectiveness, and the Guide explicitly includes tools and the Definition of Done in what it inspects. A good Retrospective, asked the right question (what plausible-but-wrong thing escaped this Sprint, and what would have caught it?), is the single most useful hour a team working with agents can spend.
It is also the event teams skip first.
Liturgy Without Theology
Here is the harshest thing I will say, and I say it as someone who holds the certificate.
Scrum’s real value was never its events, its artifacts or its accountabilities. It was the theology underneath them: empiricism, the conviction that you find out what works by doing a little and looking honestly at the result. The events were the liturgy, the practices that made the theology happen on a calendar.
In most organisations I have seen, the liturgy has outlived the theology. Teams hold every event, fill in every artifact and staff every accountability, and inspect almost nothing and adapt even less. That was already true before agents arrived. What agents have done is make the gap impossible to ignore, because the liturgy is now visibly out of step with the work. The team is ceremonially planning two weeks of something that took two days. Everyone in the room can feel it.
There is also an industry around the liturgy, and it is worth naming because it explains why the liturgy survives. Certifications, trainers, scaled frameworks layered on top of the framework, consultants who sell the events. None of that is malicious. All of it has an interest in Scrum staying recognisably the same. A framework whose survival is partly commercial is a framework that will be slow to admit its premise has changed.
What Must Replace It, or What Scrum Must Become
I am not proposing a new framework. The industry does not need another trademark. I am proposing what the next version of the Guide would have to say if it were written today, from the same empiricism, for the new constraint.
Continuous verification instead of a fixed Sprint. Keep a cadence for the things that genuinely need one: talking to stakeholders, stepping back, deciding direction. But stop batching the work itself on that cadence. Each change should be inspected when it is ready, not when the calendar says. The unit of rhythm becomes the verified change, not the Sprint.
The Definition of Done as the primary artifact. Not a checklist on a wiki: a contract enforced by machines where it can be and by named reviewers where it cannot. Evidence, not claims: the change on disk, the build that ran, the tests that passed with their output, the behaviour observed. The author of a change, human or agent, is never its only judge. When producing is cheap, the definition of finished is the product.
Limits on unverified work instead of velocity. Stop measuring how much was produced. Measure how much is waiting to be verified, how long it has been waiting, and how much of what was declared done later turned out not to be. Cap the queue of unreviewed changes the way lean caps work in progress. When the cap is hit, nobody starts new work; they verify.
An accountability for verification. Name it. Somebody on the team owns the question “is what we shipped actually right?” in the same way the Product Owner owns “is what we are building worth it?” It can rotate. It cannot be everyone, because everyone is no one.
Planning by review capacity. The real limit on a team’s throughput is how much it can verify carefully. Plan against that number. Size work by what it will cost to check (how reversible it is, how far its damage could spread, how much of it the tests can actually see) rather than by what it will cost to write.
A Product Owner for judgement, not rationing. When the team can build almost anything, the Product Owner’s job is to decide what is worth owning: every feature built is a feature maintained, verified, secured and explained. The backlog stops being a queue and becomes a set of bets.
None of this abandons Scrum’s foundations. It applies them to the world as it is. That is the test of whether a framework is empirical: when the evidence changes, does the framework?
Three Words
Scrum’s successor, whatever it is called, will keep three words: transparency, inspection, adaptation. It will throw away almost everything that was built on top of them for a world where building was slow.
If Scrum is willing to be that successor, it survives, and deserves to. The people who wrote the Guide have revised it before, and the 2020 revision was braver than most give it credit for. It made the Guide shorter and less prescriptive, and replaced roles with accountabilities. Another revision of that courage would do.
If it is not willing, it becomes the thing it was invented to replace: a process followed because it is the process, by teams who can feel that the calendar and the work have stopped agreeing, and who are told that the problem is their discipline.
The problem was never their discipline. The bottleneck moved. Scrum did not.