Is There Still a Scrum?
I should tell you before anything else that this is the chapter with the least ground under it. The data on how AI is changing the way development teams write code is now real and large; the data on how it is changing the way they meet, plan, and coordinate is almost nonexistent, because the change is a year old and the practice that is supposed to document it is the same practice being disrupted. So I am going to be honest about what is established, what is a vendor selling a feature, and what is my own argument that I cannot yet prove. The frontier is worth writing about precisely because it is unsettled, but you should know which sentences are load-bearing fact and which are me reasoning ahead of the evidence. I will mark them.
Here is what is not in dispute. The ceremonies of agile development, the sprint, the daily standup, backlog grooming, planning poker, the retrospective, were designed to coordinate humans writing code at human speed. Every one of them assumes a particular cadence: that building a feature takes days, that a person can hold a sprint’s worth of work in their head, that an estimate means something because effort is roughly proportional to complexity. The agent broke that cadence. When a feature ships in an afternoon instead of a sprint, the rituals built around the sprint do not automatically stop making sense, but they stop meaning what they meant.
I want to tell you where this chapter lands before I walk you to it, because the destination is strange enough that you should be able to watch it coming. The argument is that the collapse of the cadence is quietly converging agile and waterfall, the two methodologies a generation of software people were taught to treat as opposites, into the same shape, because the only thing that ever truly separated them was batch size, and the agent has driven batch size toward zero. That is the structural claim, and every point about ceremonies and estimates and standups in between is a step toward it. But the structural claim is not the part I care about most. Underneath it is a human one, and it is the heart of the chapter: the ceremonies were never really about coordination, and the part of them worth saving is the part no agent can run and no digest can capture. The destination is the convergence; the reason it matters is the people.
The estimate that stopped meaning anything
Start where the breakage is clearest and least arguable, because the institution that owns the framework said it out loud. In early 2026 Scrum.org, the body that certifies Scrum practitioners, published guidance calling velocity a “vanity metric” in the AI era. Their reasoning is exact: a story point was always a unit of human effort, and when an agent can generate the code for a three-point story in seconds while the verification of that code stays as hard as it ever was, the point no longer measures anything real. They proposed replacing it with new metrics built around agent efficiency and human-agent handoff time. Set aside whether those particular replacements are right. The signal that matters is that the framework’s own stewards are reframing it rather than defending it. When the people who sell the certification tell you the central number is now a vanity metric, the number is broken.
And it is not only the framework’s stewards saying it. Amazon Web Services published a proposed AI-native development methodology, the AI-Driven Development Lifecycle, that asks the same questions from the other side of the industry, and asks them more bluntly. Its founding rationale puts two of them in writing: would effort estimation still be as critical, it asks, if AI diminishes the boundaries between simple, medium, and hard tasks, and would a metric like velocity be relevant at all, or should it be replaced by business value. It observes that the old rituals, the daily standup, the retrospective, were built for iteration cycles measured in weeks, and that when proper use of AI compresses those cycles to hours or days, many of the rituals are rendered, in its word, less relevant. When the certifying body and a hyperscaler’s published methodology independently reach the same conclusion about the same ceremonies, the conclusion has stopped being a contrarian take and become the consensus that has not finished arriving.
Estimation breaks first because it is the ceremony most directly tied to the thing that changed. Planning poker, story points, velocity, the whole apparatus exists to answer “how long will this take,” and the answer used to be a function of human effort. Effort is no longer the constraint. The constraint moved downstream to verification, which the estimate was never measuring, so the estimate now describes a bottleneck that no longer exists and ignores the one that does. You can keep playing planning poker. The cards just stopped pointing at anything.
The sprint was never a coding container
Pull the thread further and you reach a more interesting claim, and this one comes from the data. When teams adopt coding agents, the striking thing in the telemetry is what does not move: sprint-level throughput, the company’s actual delivery rate, stays roughly flat even as individual code output explodes. The Faros study across twenty-two thousand developers found the familiar pattern, pull requests up, median review time up more than four hundred percent, incidents up, and delivery barely changed. One way to read a flat delivery number against a soaring output number is that the sprint was never a coding container in the first place. It was a coordination container. The coding was the part that fit inside it, but the sprint’s real job was synchronizing people: aligning what everyone was building, surfacing what was blocked, deciding what came next. The agent automated the coding, the thing that was incidental to the sprint’s purpose, and left the coordination, the thing the sprint was actually for, untouched and now mismatched in cadence to the work.
That reframing, that the sprint was a container for human coordination and not for code, is the most useful idea in this chapter, because it tells you which ceremonies are in real trouble and which are merely mislabeled. The ones in trouble are the ones that only ever measured the coding: estimation, velocity, the burndown. The ones that were really about coordination are not obsolete; they are mis-cadenced, running on a two-week clock for work that now moves on a two-hour one. And the ones whose real value was never on the board at all, the human ones, are the ones at risk of being automated into hollowness without anyone noticing what was lost. Which is the next thread, and the heart of the chapter.
What the standup was actually for
The daily standup is the easiest ceremony to automate and the most dangerous one to get wrong, because what it produced was never the thing it appeared to produce.
On paper the standup is a status meeting: what did you do yesterday, what will you do today, what is blocking you. If that were all it was, automating it would be pure gain, and the tools to automate it are mature and widely used. Standup bots have been around for years; the AI versions pull your commits and pull requests and ticket movements and write the status digest for you, post it to the channel, flag the blockers, and give everyone back their fifteen minutes. Hundreds of thousands of teams use them. As a way to collect and distribute status, they are strictly better than a human reading their yesterday out loud.
But status was never the point. Status was the pretext. What the standup actually produced was the involuntary collision: the moment one engineer mentioned, in passing, the thing that was not on any board, and another engineer said “wait, if you are touching the retry logic, that is going to break the thing I am shipping Thursday.” Nobody planned that exchange. It happened because the ceremony forced a set of people into the same five minutes and made them say out loud what they were doing, and in the friction between two spoken updates a problem surfaced that neither person had written down because neither person knew it was a problem until they heard the other one talk. The standup was a manufactured opportunity for the unplanned, and the unplanned was the value. Put less reverently: it was a daily mechanism for getting a room of heads-down engineers, who would happily go a week without an unprompted word to a colleague, to collide in person against their own preference, and the collision was the point. The agile literature dressed this up as alignment and transparency. What it really was, most days, was social engineering nobody admitted to, forcing the conversation that the people in the room would never have started on their own and badly needed to have.
This is not sentiment. It is the most robust finding in the science of how teams work, and it predates AI by decades. The research out of MIT’s Human Dynamics Lab found that the strongest predictor of a team’s productivity was not the quality of its formal meetings but the volume of its informal communication, the unscheduled, low-stakes, sideways contact between people. The meeting on the calendar mattered less than the energy around it. The standup’s contribution to a team was rarely the agenda. It was that it put people in proximity and gave them a reason to talk, and the talk that mattered was the talk that was not on the agenda.
Now automate it. The AI digest captures the status perfectly and loses the collision entirely. Every engineer’s update is now accurate, complete, machine-generated from their actual commits, and read by no one in the presence of anyone else. The thing the meeting was for, the friction that surfaced the unwritten problem, does not survive the conversion to a digest, because the digest is a broadcast and the collision required a room. This is the pattern that should worry you more than any of the velocity numbers: automating a ceremony preserves its form and removes its purpose. The form was the meeting. The purpose was the accident the meeting made possible. The agent is very good at the form.
Every team ceremony has a stated function and a real one, and they are not the same. When you automate the ceremony, the agent reliably reproduces the stated function and reliably destroys the real one, because the real one was a side effect of humans being in a room with a reason to speak. Which gives you the only test that matters for whether a ceremony is safe to hand to a machine. Not “can the agent do it,” because the agent can do the stated function of nearly all of them. The test is “was its value ever on the agenda.” If it was, automate freely. If it was not, automating it is subtraction wearing the costume of efficiency.
You can run that test on every ceremony and it sorts cleanly into two piles. The retrospective’s stated function is a list of process improvements; its real function is the one sanctioned hour where a team can name what is broken without it counting as going over someone’s head, and an AI that groups the sticky notes and generates the action items produces a better list and removes the only safe space the team had to be honest. Backlog grooming’s stated function is a tidy backlog; its real function was the argument, the place where a junior learned, by listening to two seniors disagree about scope, what actually mattered and why. There is a clean line between what the agent can take and what it cannot, and it is not a line about capability. It is a line about whether the value was the output or the human friction that produced the output.
| What the agent reliably takes | What it cannot replicate |
|---|---|
| Status collection and the digest | The unplanned collision that surfaces the unwritten dependency |
| Burndown, velocity, sprint metrics | Reading the room: sensing burnout, hesitation, a quiet “no” |
| Ticket hygiene and backlog tidiness | The argument in grooming where a junior learns what matters |
| Grouping retro feedback, drafting action items | The sanctioned hour to say what is wrong without escalating |
| Risk-pattern detection across the project | Conflict resolution and the building of psychological safety |
There is harder evidence that the human side is not soft. A 2025 study in a Nature journal, following several hundred employees over time, found that AI adoption was associated with a statistically significant decline in psychological safety, the felt permission to speak up, admit an error, take an interpersonal risk, and that the decline tracked through to measurable harm. The sample was not specifically software teams, so I will not overstate it, but the direction is consistent with everything else: as the machine takes over more of the interaction, people feel less safe being human in front of it, and the ceremonies that were quietly doing the work of psychological safety were doing work the org never costed and is about to stop paying for.
When the agent runs the ceremony, the ceremony joins Channel 2
There is a further step past automating the ceremony’s content, and it is already shipping. The agent can now run the ceremony itself. At its 2026 conference Atlassian shipped, to general availability, agents inside Jira that prepare sprint planning by checking every backlog item against the definition of ready, that draft the sprint goal from the issues, that groom the backlog by finding the work missing estimates and routing it for sizing. This is not a bot collecting status. It is an agent performing the facilitation, the work that used to belong to a scrum master or a lead.
And the moment the agent runs the process, the process becomes the thing this whole book is about: a system that acts on the team’s behalf and therefore has to be supervised. The agent that grooms your backlog is making prioritization decisions, and prioritization is where an agent quietly launders the organization’s existing bias into the appearance of neutral optimization. The documented tendency of these systems is to weight what the historical data weighted, the enterprise customer over the small one, the revenue-linked feature over the accessibility fix, the loud stakeholder over the quiet need, and to present the result as an objective ranking rather than a value judgment. Someone has to be watching for that. But here is the gap, and it is the same gap as everywhere else in this book: there is no role that owns it. The scrum master and the project manager are peers in the framework; neither supervises the other; there is no defined seat for the person who supervises the agent that now runs the team’s coordination. The org that staffed the team to build the product and never staffed anyone to supervise the product’s runtime is about to make the identical mistake one level up, with the process. The agent that runs the ceremony is a Channel 2 system, and Channel 2 still has no owner.
This is also where the role question lands, and the labor data is real even if the proportions are murky. Capital One eliminated roughly eleven hundred agile delivery and scrum master roles in a single cut; other large firms have made similar reductions. I will not claim, because the evidence does not support it, that agile roles were disproportionately targeted across the whole industry. What I will claim is narrower and better supported: the parts of the coordination job that were automatable, the status, the metrics, the ticket hygiene, are being automated, and the parts that are not, conflict resolution, reading the room, building the safety that lets a team tell the truth, are exactly the parts no tool ships and no metric counts. The coordination role is not vanishing. It is being stripped down to the human-remainder, and the organizations cutting it to zero are betting that the human-remainder was never doing anything, which is the same bet as believing the standup was about status.
The convergence nobody is naming
Now the part that is mine, and that I cannot prove, and that I think is the most important thing in the chapter. I have not found anyone else making this argument, which is partly why I am making it: I think we are watching agile and waterfall converge, and almost no one is saying so.
Follow the shape of how an agentic team works now. You write a spec for a bounded task, a clear statement of intent and a definition of done. You hand it to the agent, which plans, then builds. Then you verify what came back. Spec, plan, build, verify. Look at that sequence plainly and it is not the agile loop. It is the waterfall sequence, requirements, design, implementation, verification, the exact sequence that agile spent twenty years teaching the industry to abandon. The spec-driven micro-sprint is, structurally, a micro-waterfall.
The reflex is to say that cannot be right, because waterfall was a disaster and agile was the cure. But it is worth remembering precisely what was wrong with waterfall, because it was not the sequence. Spec-then-design-then-build-then-verify is just the logical order of doing the work; you cannot verify before you build or build before you decide what to build. What was catastrophic about waterfall was the batch size. You ran that sequence once, over a year, across the entire product, and you did not find out whether you had built the right thing until the end, by which point the cost of being wrong was the whole year. Agile’s real innovation was never a new sequence. It was shrinking the batch, running the same fundamental sequence over and over on small increments so the feedback came back fast and a wrong bet cost a sprint instead of a year. Agile won the argument about batch size so completely that we forgot the argument was ever about batch size and started believing it was about the ceremonies.
The agent did something agile never could. It did not improve waterfall’s planning. It collapsed the batch toward zero. A full spec-build-verify cycle that used to be the unit of a year is now the unit of an afternoon, and at that scale the feedback is just as fast as agile’s was, faster, while the sequence inside each cycle is openly, unmistakably the waterfall sequence. We escaped waterfall by shrinking its batch until the danger went away. The agent kept shrinking the batch until the thing we were left with is a stream of tiny, sequential, spec-driven waterfalls, and we are calling them sprints out of habit. The convergence is real, and it is a convergence, not a defeat: this is not big-batch waterfall returning to vindicate itself. It is that, at infinitesimal batch size, the two methodologies are the same shape, and the religious war between them was always a war about how much you were willing to bet before you learned you were wrong.
People are not naming the convergence, but they are building it. The clearest example is the AWS methodology I just mentioned, because if you read its structure without its vocabulary, it is the argument of this section rendered as a product. Its cycle runs from an intent, to units of work, to a domain design, to a logical design, to code, to deployment, to operations. Strip the new words and that is requirements, then design, then build, then deploy, then operate: the waterfall sequence, in phases its own authors call phases, run as fast cycles they have renamed from sprints. And it goes further than habit would require, because it deliberately pulls the up-front design disciplines, domain-driven design, the architecture decision record, the modeling that agile had pushed to the edges as optional, back into the core of the method, on the explicit argument that leaving them out is what produced a generation of low-quality software. That is not a team drifting back toward waterfall by accident. That is a hyperscaler reintroducing waterfall’s design rigor on purpose, at small batch size, and presenting it as the future. They built the convergence and gave it a new name instead of the old one, which is exactly what you would expect from an industry that spent twenty years being told the old name was the enemy. The thing nobody will call waterfall is being rebuilt by the people least able to admit that is what it is.
There is a personal echo here. The hundred-and-ninety-eight-page strategy document from the foundations of this book, the one whose ten months of planning was the doctrine of its era working as intended, was a perfect specimen of spec-everything-before-you-build, and we spent two decades dismantling it, shrinking the plan, moving it inside the sprint, then inside the ticket. And now the most advanced way to build, hand a precise spec to an agent and verify what it returns, is that same spec-first discipline, with the hundred and ninety-eight pages compressed into a paragraph and the ten months into an hour. The planning did not die and the sequence did not change. Only the batch size changed, by four orders of magnitude, and that single change is what let the oldest sequence in software quietly become the newest.
So is there still a scrum
There is still a scrum, in the sense that teams still gather, still align, still decide what comes next, and will need to more than ever, because alignment is the part the agent cannot do for them. There is not still a scrum, in the sense that the specific apparatus, the two-week sprint, the story point, the velocity chart, the status standup, was built for a cadence that no longer exists, and pieces of it are now ritual without function, form without purpose.
The honest answer is that the ceremonies were always two things wearing one name. They were a coordination mechanism for human work, and they were a manufactured habitat for the informal contact that is the actual substrate of a working team. The agent is dissolving the first, because the cadence it coordinated is gone, and the convergence on micro-waterfall is what is taking its place. The danger is to the second, because automating a ceremony keeps its shape and quietly kills the accidents inside it, and the team that replaces its standup with a perfect digest will get better status and slowly stop noticing the dependency nobody wrote down. The work for whoever owns the team is to be clear-eyed about which ceremony is which: to let the coordination apparatus mutate freely toward whatever fits agent-speed work, and to defend, deliberately and against the efficiency argument, the few manufactured occasions where people still collide. Keep the collisions. Automate the status. And do not mistake the disappearance of the form for the disappearance of the need, because the need to align, to argue, to feel safe enough to say what is wrong, did not go anywhere. It just lost the meeting that used to carry it, and nobody has built the thing that carries it next.