The funeral nobody is sad about
Let's be honest about something we've all been pretending not to notice.
Scrum is dead.
And almost nobody is sad about it.
We've spent twenty years standing in a circle every morning, moving tickets across a board, arguing about whether something is a 3 or a 5, and calling it "agility." We built an entire industry on top of it — certifications, coaches, tooling, dashboards. We turned a lightweight idea into a bureaucracy with a mascot.
And deep down, most of us hated it.
Here's the twist: the thing finally killing Scrum isn't a better methodology. It isn't a smarter framework with cleaner ceremonies. It's a capability shift. Coding agents have made the original promise of the Agile Manifesto — the actual promise, not the ritual we replaced it with — physically possible for the first time.
Scrum won because it was followable, not because it was right. And now something has come along that makes the right thing followable too.
So this is a eulogy. But bring confetti.
The Manifesto was correct — and that's exactly why it failed
Here's the part people get wrong.
The Agile Manifesto wasn't wrong. It was right. Read it again today and it still reads like common sense written by people who had suffered.
So why did it fail?
It failed because it was right in the wrong format. It gave us principles. And principles are the single hardest thing in the world to get an organisation to actually follow.
Think about the difference between a principle and a piece of practical advice.
Practical advice can be followed by anyone. "Stand up for fifteen minutes every morning." "Estimate your work in story points." "Work in two-week sprints." No judgment required. No experience required. Just compliance. You can teach it in an afternoon and audit it with a spreadsheet.
Principles are different. "Deliver value continuously." "Trust motivated individuals to get the job done." "Reflect regularly and adjust." You cannot checklist your way to those. They require intuition, gut feeling, and accumulated experience. You have to earn the judgment to apply them, and that judgment doesn't arrive on a training course.
And here is the uncomfortable truth about human beings:
We are biased toward the practical over the principled.
Give a large organisation a choice between a principle it has to internalise and a practice it can copy-paste, and it will pick the practice every single time. Not because people are stupid — because practices are legible, teachable, auditable, and certifiable. Principles are none of those things. You can't put "developed good judgment" on a Jira board.
So the market did what the market always does. It converted the principles into practices — and lost the soul in translation.
Scrum was that conversion.
It took a set of values that required wisdom and repackaged them as ceremonies that required only attendance. That's the whole reason Scrum won and "being agile" lost: Scrum was followable. It asked nothing of your judgment. It just asked you to show up to the standup.
This is exactly how Agile transformations fail. The gap between principles and practices is where every one of them goes to die. Leadership never commits to the principle; they adopt the artefact, misread it — the burndown chart becomes an obsession with output instead of a tool for reflection — and they end up with the precise opposite of what the Manifesto intended. A principle demands a missionary. A practice only needs a mercenary. And most organisations are staffed to hire mercenaries.
So the real question was never "were the Agile values correct?" They were.
The real question was: how do you get an organisation to honour principles it doesn't have the collective experience to internalise?
For twenty years, the honest answer was: you can't. So here's Scrum instead.
The Manifesto didn't fail because it was too idealistic. It failed because it trusted us to have judgment — and judgment doesn't scale by memo. Scrum scaled by memo. That's the whole tragedy.
Until now.
The principle that just became literally true
Look at one line from the Manifesto:
"Business people and developers must work together daily throughout the project."
This is the principle everyone paid lip service to and absolutely nobody achieved.
"Daily"? Come on. We got a fifteen-minute standup where a business stakeholder occasionally lurked, and a Slack channel where they dropped requirements like ransom notes. We put "collaboration" on the wall and then reintroduced every silo the Manifesto told us to tear down.
Working together daily was a principle. So of course we replaced it with a practice — a recurring meeting — and pretended that counted.
Now watch what agents do to that sentence.
For the first time in the history of this industry, business people and end users are the ones building. Not describing. Not requesting. Building. A domain expert who has never written a line of production code can now sit down with a coding agent and vibe-code the thing they actually want.
So "work together daily" stops being a meeting you have to schedule and start resenting. It collapses into a single artefact: a working prototype, produced by the person who understands the problem best.
You don't need business and engineering in the same room every day if the business already handed you running software.
The principle didn't get easier to follow. It stopped needing to be followed at all — because the technology now executes it by default.
Prototypes are the new requirements — and they're better than any ticket
Think about the old chain of custody for an idea.
Idea → Jira epic → refinement session → user story → acceptance criteria → estimate → sprint commitment → build → demo → "...that's not what I meant."
Every arrow in that chain is a place where value leaks out. Every handoff is a game of telephone played by people with different incentives and different vocabularies. By the time an idea reaches an engineer, it has been flattened into a ticket — a lossy proxy for a conversation that a business person had with themselves weeks ago.
The new chain is almost insultingly short.
The end user vibe-codes the thing they actually want → they hand engineering a working form of requirements.
That's it.
And a working prototype is a better requirement than any document we've ever produced. A spec describes. A prototype demonstrates. A spec says "the user should be able to filter the list." A prototype shows you exactly which filters, in what order, with what defaults, behaving in the specific way the person imagined but could never have written down.
I've always believed we should listen to our customers' problems, not their solutions. That's still true — but a prototype reveals the real problem far better than a feature request ever could, because you get to see what they reached for when nobody was translating for them.
This is executable discovery. It is the highest-fidelity requirement artefact we have ever had.
Now — an important caveat, because I don't want to sell you snake oil. The prototype is not the product. It's validated intent. It's a running, clickable, arguable statement of "this is what I mean." Engineering's job doesn't disappear. It changes — from "figure out what they meant" to "make this real, safe, scalable, and correct."
Which is a much better job than the one we had.
Jira is dead too 🪦
So let me ask the obvious question.
If the requirement is a running prototype, what exactly is the backlog for?
The ticket was always a lossy proxy for a conversation and an intent. Agents let us skip the proxy entirely. And once you remove the proxy, an enormous amount of ceremony has nothing left to justify it.
Here lies:
- Sprint planning.
- Story points.
- Estimates.
- Burndown charts.
- Three-hour refinement marathons.
- Velocity dashboards nobody trusted anyway.
Story points and Jira tickets were the ultimate practice-over-principle crutch. They were legible, auditable, and certifiable — which is exactly why they metastasised across every engineering org on earth. They gave managers something to point at. They never gave customers anything.
I've argued for years for no estimates, no time boxes, pull-based flow, and cost tracking over velocity tracking. Agents don't just make estimation undesirable — they make it absurd. Agent velocity is wildly unpredictable; a task that looks trivial takes six iterations, and a task that looks huge falls out in one prompt. Estimating that is superstition with a Fibonacci sequence attached.
And let's say the quiet part out loud: a large chunk of the agile-industrial complex exists to manage a scarcity — human coding throughput — that is actively evaporating. When the bottleneck moves, the machinery built around the old bottleneck becomes theatre.
So what actually replaces Scrum?
Not another framework with new ceremonies. Please, not that.
What replaces it is a capability-driven loop:
- Business people and end users turn intent into a prototype. Discovery becomes executable.
- Engineering steers, hardens, verifies, and integrates. The role shifts from typing to judgment.
- Everything is continuous, pull-based, and measured by outcomes rather than by sprints completed.
Notice what happened to the silo wall. It didn't get a door. It dissolved. Developers get pulled into discovery — because when implementation is cheap, understanding what to build matters more than how. And business people get pulled into building — because the tools finally let them.
And look at what got deleted in the process. Not automated — deleted. The whole tower of intermediaries that used to sit between the person with the problem and the person solving it. The business analyst who translated the need into a document. The scrum master who defended the ceremony. The project manager who maintained the Gantt chart. The proxy product owner who spoke for a user they'd never met. Layer after layer, each one added to compensate for the fact that the end user and the developer couldn't talk to each other directly.
Now they can. So the layers have no reason to exist.
This is where it gets interesting, because of Conway's law. Any system you build ends up mirroring the communication structure of the organisation that builds it. Stack up six layers of handoffs between the user and the code, and your software inherits all six — the seams, the misunderstandings, the compromises baked in at every translation. Conway's law never stops operating; you just get to choose how ugly the org chart it's copying is.
When you collapse the distance to a single hop — end user to developer, mediated by an agent instead of a committee — Conway's law is still true, but its blast radius shrinks to almost nothing. There are barely any communication seams left for the software to inherit. The negative version of Conway's law fades not because we repealed it, but because we finally stopped feeding it layers.
That's the Manifesto's cross-functional dream, except this time it isn't an aspiration you have to be disciplined enough to honour. It's just how the work flows.
The honest part: what could still go wrong
I'm celebrating, but I'm not naïve. I have one rule about AI that I'll never let go of: it's an amplifier, not a corrector. It accelerates whatever trajectory you're already on.
So here's the sober bit.
Verification is the new bottleneck. Anyone can now generate software that works-ish. Proving that it's correct, secure, performant, and maintainable is the scarce skill — and it's a skill agents cannot be fully trusted to perform on themselves. Prototypes-as-requirements only works if engineering owns the hardening layer with total seriousness.
Beware "good bad code" — code that is technically impressive but delivers no value, and its evil twin, code that looks fine and quietly ships a vulnerability. The vibe coders who ship without any verification will fail, and they'll fail fast. The winners are the ones who start with value and invest enough in verification to sustain it.
Killing Scrum removes a fake safety net. Sprints and story points never made your software correct; they just made your Gantt chart feel manageable. The real safety net — automated testing, security review, human judgment at the gate — now has to be built for real. The new failure mode isn't shipping slowly. It's shipping the wrong, unsafe thing faster.
Which brings us to the developer identity shift I keep banging on about. Our profession has lived by "talk is cheap, show me the code." Code is our identity. Letting go of it is painful. But the job was never the typing. The job was the judgment. Agents don't take the judgment away — they make it the only thing that matters.
Who wins and who's in denial
The winners are the teams that let end users prototype, treat those prototypes as requirements, and reinvest all the capacity they just freed up into the two things that actually matter now: discovery and verification.
The ones in denial are the organisations bolting agents onto Scrum. Asking an agent to produce story-point estimates. Running AI-assisted standups. Generating Jira tickets that no human will ever read, to feed a process whose only job was to ration a scarcity that no longer exists.
They will amplify their dysfunction — faster.
You cannot AI-transform your way out of a methodology whose entire purpose was to ration something that isn't scarce anymore.
The Manifesto wasn't wrong, just early
The Agile Manifesto's promise was never a lie. It was early. The values were correct; we just never had the technology to honour principles that demanded more judgment than an organisation could reliably muster. So we swapped the principles for practices, called the practices "agile," and spent two decades cosplaying the thing instead of living it.
Coding agents change that — not by giving us a new set of rules to follow, but by letting a principle finally be executed as a working artefact instead of admired as a poster on the wall.
Scrum served its purpose. It taught a whole generation to work in small increments and to at least look at their users. We can thank it for that. And then we can let it go.
Because Scrum didn't lose an argument.
It lost a job — now that business people and developers can, finally and literally, build together every day. 🎉
