{"slug": "scrum-is-finally-dead-and-we-have-to-thank-coding-agents-for-that", "title": "Scrum is finally dead 🎉 and we have to thank Coding Agents for that", "summary": "A developer argues that Scrum is effectively dead, not because a better methodology replaced it, but because coding agents have made the Agile Manifesto's original principles practically followable for the first time. The piece contends that Scrum won because its ceremonies were legible and auditable, while the Manifesto's principles required judgment that organizations could not scale, and that AI coding agents now close that gap.", "body_md": "Let's be honest about something we've all been pretending not to notice.\n\n**Scrum is dead.**\n\nAnd almost nobody is sad about it.\n\nWe'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.\n\nAnd deep down, most of us hated it.\n\nHere'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.\n\nScrum won because it was *followable*, not because it was right. And now something has come along that makes the right thing followable too.\n\nSo this is a eulogy. But bring confetti.\n\nHere's the part people get wrong.\n\nThe 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.\n\nSo why did it fail?\n\nIt 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.\n\nThink about the difference between a principle and a piece of practical advice.\n\nPractical 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.\n\nPrinciples 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.\n\nAnd here is the uncomfortable truth about human beings:\n\n**We are biased toward the practical over the principled.**\n\nGive 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.\n\nSo the market did what the market always does. It converted the principles into practices — and lost the soul in translation.\n\nScrum *was* that conversion.\n\nIt 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.\n\nThis 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.\n\nSo the real question was never \"were the Agile values correct?\" They were.\n\nThe real question was: *how do you get an organisation to honour principles it doesn't have the collective experience to internalise?*\n\nFor twenty years, the honest answer was: **you can't. So here's Scrum instead.**\n\nThe 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.\n\nUntil now.\n\nLook at one line from the Manifesto:\n\n\"Business people and developers must work together daily throughout the project.\"\n\nThis is the principle everyone paid lip service to and absolutely nobody achieved.\n\n\"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.\n\nWorking together *daily* was a principle. So of course we replaced it with a practice — a recurring meeting — and pretended that counted.\n\nNow watch what agents do to that sentence.\n\nFor 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.\n\nSo \"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.\n\nYou don't need business and engineering in the same room every day if the business already handed you running software.\n\nThe principle didn't get easier to follow. It stopped needing to be *followed* at all — because the technology now executes it by default.\n\nThink about the old chain of custody for an idea.\n\nIdea → Jira epic → refinement session → user story → acceptance criteria → estimate → sprint commitment → build → demo → *\"...that's not what I meant.\"*\n\nEvery 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.\n\nThe new chain is almost insultingly short.\n\nThe end user vibe-codes the thing they actually want → they hand engineering a **working form of requirements**.\n\nThat's it.\n\nAnd 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.\n\nI'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.\n\nThis is executable discovery. It is the highest-fidelity requirement artefact we have ever had.\n\nNow — 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.\"\n\nWhich is a much better job than the one we had.\n\nSo let me ask the obvious question.\n\nIf the requirement is a running prototype, what exactly is the backlog *for*?\n\nThe 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.\n\nHere lies:\n\nStory 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.\n\nI'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.\n\nAnd 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.\n\nNot another framework with new ceremonies. Please, not that.\n\nWhat replaces it is a **capability-driven loop**:\n\nNotice 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.\n\nAnd 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.\n\nNow they can. So the layers have no reason to exist.\n\nThis 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.\n\nWhen 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.\n\nThat'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.\n\nI'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.\n\nSo here's the sober bit.\n\n**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.\n\nBeware \"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.\n\nKilling 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*.\n\nWhich 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.\n\nThe 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.**\n\nThe 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.\n\nThey will amplify their dysfunction — faster.\n\nYou cannot AI-transform your way out of a methodology whose entire purpose was to ration something that isn't scarce anymore.\n\nThe 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.\n\nCoding 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.\n\nScrum 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.\n\nBecause Scrum didn't lose an argument.\n\nIt lost a job — now that business people and developers can, finally and literally, build together every day. 🎉", "url": "https://wpnews.pro/news/scrum-is-finally-dead-and-we-have-to-thank-coding-agents-for-that", "canonical_source": "https://dev.to/remojansen/scrum-is-finally-dead-and-we-have-to-thank-coding-agents-for-that-18bi", "published_at": "2026-09-16 10:55:21+00:00", "updated_at": "2026-09-16 11:13:07.236888+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "developer-tools", "ai-products"], "entities": ["Scrum", "Agile Manifesto", "Jira"], "alternates": {"html": "https://wpnews.pro/news/scrum-is-finally-dead-and-we-have-to-thank-coding-agents-for-that", "markdown": "https://wpnews.pro/news/scrum-is-finally-dead-and-we-have-to-thank-coding-agents-for-that.md", "text": "https://wpnews.pro/news/scrum-is-finally-dead-and-we-have-to-thank-coding-agents-for-that.txt", "jsonld": "https://wpnews.pro/news/scrum-is-finally-dead-and-we-have-to-thank-coding-agents-for-that.jsonld"}}