Is Agile Dead For Software Development?

Born in manufacturing and product development, adopted and formalized by software, agile transformed how the industry builds through shared understanding between the person with the idea and the people who build it. That problem, the one agile solved so well, just stopped being expensive.

Every methodology is a price list in disguise. Waterfall, agile, DevOps: each one is the set of behaviors that made sense given what software cost to produce, to change, and to get wrong at the time it was invented. Read them that way and the history of software process stops being a story about culture wars and becomes a story about economics. It also becomes predictable. When the underlying prices move, the methodology dies, whatever its practitioners believe about it.

The prices just moved. Agile, in the form we knew it, is dead, and it did not die because anyone found a better ritual. It died because the problems it was born to solve, speed to market, quality, and above all human understanding, no longer need its machinery. The first two everyone names. The third is the real engine. A product manager is “almost” clear about what they want, but needs to see something real to finish thinking. The people who build sit on the far side of a translation gap that no requirements document ever fully crossed. Agile was the machine that provided the shared understanding at human speed, and that machine just lost its monopoly.

I became an agile believer early, around 2002, and adopted it as both a methodology and a philosophy. I've spent a good portion of my career helping teams make that shift, first at Microsoft and then at hundreds of companies since, and the results were consistent: better-quality products, faster speed to market, more enjoyable collaboration, and lower cost. Years ago, to prove the point, I created a Microsoft product called eScrum, which launched and eventually became part of Visual Studio.

So agile isn't really dead. The form we knew is, and what survives has to evolve for the AI era and the software development lifecycle it has reshaped.

Waterfall Was Rational Once

Start where agile started: with the thing it rebelled against. The sequential model, requirements to design to build to test to ship, is usually told as a cautionary tale about hubris. It was actually a sensible answer to the economics of 1970s software. Machine time was rationed. Deployment meant physical media and acceptance gates. And the cost of change rose brutally with time: Barry Boehm's research made famous what every large program already felt, that a defect caught in production costs orders of magnitude more to fix than one caught on the whiteboard. Big design up front was not stupidity. It was insurance, priced for its era.

The irony is that Winston Royce's 1970 paper, the one that gave the world its canonical waterfall diagram, presented the single-pass model as risky and prone to failure. The industry adopted the diagram and skipped the warning, because the diagram matched the cost structure and the warning did not.

By the 1990s the cost structure had shifted and waterfall had become a machine for building the wrong thing slowly. Software had moved from spacecraft programs to business applications, where requirements were not physics but opinion, and opinion changes. Annual release trains meant a company bet a year of payroll on a requirements document written before anyone had seen a screen. The Standish Group's CHAOS research found that only a small minority of large projects delivered what was promised, on time and on budget. The cost of software was never mostly the typing. It was the cost of being wrong, multiplied by how long it took to find out.

The cost of software was never mostly the typing.

It was the cost of being wrong, multiplied by how long it took to find out.

Snowbird Was a Repricing Event

On Feb 11-13, 2001, seventeen practitioners met at a ski lodge in Snowbird, Utah, and wrote the Agile Manifesto. The ideas were older than software, born in manufacturing and product development: the Toyota Production System and lean thinking, the plan-do-check-act cycle Japan built on Deming's postwar lectures, and Takeuchi and Nonaka's 1986 Harvard Business Review article "The New New Product Development Game", which watched Honda and Canon build products with overlapping, self-organizing teams and borrowed scrum from rugby. Software adopted and formalized them when its economics demanded it: Jeff Sutherland and Ken Schwaber turned scrum into a software method in the mid-1990s, Kent Beck built Extreme Programming on a Chrysler payroll project in the late 1990s, and Snowbird named the economic insight all of it shared.

The insight was this: if you cannot stop requirements from changing, stop pretending they will hold, and instead drive down the cost of changing your mind. Shrink the batch. Replace the single year-long bet with twenty-six two-week bets, each one checkable against reality before the next is placed. Agile has never really been about standups or sticky notes. It is about batch size, feedback latency, and the price of being wrong.

And underneath the economics sits a truth about people. Requirements change because nobody, not the customer and not the product manager, fully knows what they want until they see it. A product manager is usually almost right, and the remaining distance cannot be closed by thinking harder. It closes only when something real sits in front of them and talks back. Then comes the second gap: carrying that still-forming intent across to the engineers, who hear the words but not the picture behind them. Every sprint is a round trip across both gaps. The demo is not a status ritual; it is the moment the product manager finally sees their own idea from the outside and can finish thinking it. Agile's true product has never been software. It is shared understanding, manufactured two weeks at a time.

Agile's true product has never been software.

It is shared understanding, manufactured two weeks at a time.

Twenty Years of a Good Trade

And it worked. For twenty-some years agile was the best trade available. It gave product people a seat inside the loop instead of at the front of a conveyor belt. It made prototyping and usability work legitimate, because the only way to learn what users want is to build a thin slice and put it in front of them. It gave executives something waterfall never could: a true progress signal every two weeks instead of a status report colored by hope.

Be precise here, because the argument that follows is not that agile was wrong. Agile was right, for as long as its load-bearing assumption held: producing working software is the expensive part. Every ceremony is a tax paid to that constraint and to the human limits underneath it. Standups exist because people cannot directly observe each other's progress; fifteen minutes each morning is a cache-coherence protocol for brains. Estimation sessions exist because predicting human effort is guesswork that needs ritual to feel respectable. The backlog exists because construction capacity is scarce and something has to ration it. None of these are values. They are workarounds, each one exactly as valuable as its constraint is binding. Agile is a magnificent set of workarounds for one fact: software is built at the speed of human hands, so understanding can only be manufactured at that speed too.

Agile is a magnificent set of workarounds for one fact: software is built at the speed of human hands.

One Loop Becomes Three

That assumption no longer holds. For a growing class of well-specified work, the marginal cost of producing working code has collapsed: an AI agent returns an inspectable increment, the very artifact the sprint existed to produce, in minutes instead of two weeks. That is a change in the cost structure, not a gain in efficiency, and cost structure is what methodologies are made of.

Watch what happens to the loop itself. Agile runs everything, discovery, translation, construction, on one two-week wheel, because the only way to make an idea visible is to have the whole team build it. When seeing becomes cheap, the wheel splits into three loops, each owned by the people it serves, each turning at the speed of its own constraint. Together they are the new architecture of iteration.

Loop One: The Clarity Loop

The first loop runs between the product manager and AI, before development starts. The person who needs to see something to finish thinking now gets prototypes, designs, and working mockups the same afternoon, revises them by conversation, and throws the failures away at no cost. The discovery that agile rations into sprint-sized portions, build a slice, look at it, learn, happens in hours, before a single ticket exists. By the time an engineer hears about the idea, it has already been seen, rejected, reshaped, and seen again. The old discover-by-sprint loop is not shortened. It is absorbed into pre-build work, which is where the thinking always wanted to live.

Loop Two: The Alignment Loop

The second loop is the conversation with development, and it survives, because someone still has to think holistically about the system: data, security, scale, cost, the load-bearing parts a prototype hides. But it changes shape and speed. The product manager no longer arrives carrying a document that describes a picture; they arrive carrying the picture. The system architects answer with visualizations and counter-prototypes of their own. The translation gap that agile manages with a ceremony calendar closes because there is less to translate: everyone is looking at the same running thing, poking it, pricing it. Alignment that used to accrete over a quarter of sprint reviews now happens in days, before the build begins.

Loop Three: The Build Loop

The third loop is the final iteration, with AI itself, and it is safe to run fast precisely because the first two loops already did their work: everyone arrives clear and aligned. An engineer writes a precise specification for a bounded piece of work and hands it to an agent. The agent returns a working implementation, with tests, in minutes. The engineer reads it, rejects half of it, tightens the spec, and runs the loop again before lunch. None of this is unsupervised, and none of it survives a sloppy specification. The constraint here is judgment: when code arrives faster than anyone can read it, review depth and verification infrastructure set the speed limit of the whole system. A team's quality ceiling used to be the output of its best engineers. It is now its ability to specify precisely and verify ruthlessly.

Walk the old ceremonies through the three loops and watch them lose their jobs. Sprint planning rations developer hours; the hours are no longer the constraint. Estimation prices human effort; estimating agent work in story points is pricing water in the rain. The sprint review exists so the product manager can finally see; the clarity loop did that before the build began. The standup synchronizes humans around a construction bottleneck that has moved into a loop measured in minutes, and a morning sync is a strange instrument for something that already happened eleven times this morning.

Estimating agent work in story points is pricing water in the rain.

The values of agile outlive the ceremonies because the values are about feedback and the ceremonies are about cost. Only the costs changed.

The Obituary Is for the Form

Parts of the manifesto survive, which is the final irony. Customer collaboration survives at higher frequency than any sprint review allowed. Responding to change survives as the whole game. Working software as the measure of progress survives, measured in hours. What dies is the machinery, and it dies precisely because the values won. The seventeen at Snowbird were optimizing feedback per unit of time under human limits. The way to honor them is to keep optimizing after the limits moved.

So write the obituary precisely. The old form of agile, the two-week heartbeat and the ceremony calendar that manufactured understanding at the speed of human conversation, is dead. Iteration is not. The short loop survives, and it tightens: one loop for clarity, one for alignment, one for construction, each running as fast as its own constraint allows rather than at the pace of a shared calendar. What stands where agile stood is yet another form of agile, a little different in shape, a lot faster, and it solves every problem the old one was invented to solve: speed to market, quality, and the oldest problem of all, the distance between what a person means and what gets built. In technical due diligence at RingStone, the first question is no longer how a company runs its sprints; it is how well its three loops turn.