Scrum Is Dead. Here's What Killed It.

Picture this: it's 9:15 AM on a Monday. Fourteen people are standing in a semicircle, each waiting their turn to recite a liturgy they've memorized: what I did yesterday, what I'm doing today, any blockers. The Scrum Master nods sagely. The Product Owner checks Slack under the table. A developer who was in flow state forty-five minutes ago has now completely lost their thread.

I've been in that semicircle. I've been the developer who lost the thread. I've also been the one nodding sagely, and I'll tell you what I was actually thinking: this isn't working, and everyone in this room knows it.

This is the daily standup. This is Scrum. And it's dying.

The Promise vs. The Reality

Scrum promised us agility. Iterative delivery. Close collaboration. Freedom from the waterfall death march. And for a while, in certain contexts, it delivered.

Then the ceremonies multiplied.

Sprint planning. Sprint review. Sprint retrospective. Backlog refinement. According to Parabol's research on Agile teams, developers now spend more than 17 hours per week in Agile ceremonies. Sprint planning runs synchronous 64% of the time. Standups, 61.6%. Backlog refinement, 51.8%. The calendar filled up with meetings about work instead of time for work.

The Stripe developer coefficient study put the damage in starker terms: developers spend only 32% of their time writing new code or improving existing code. The rest vanishes into coordination, ceremonies, reviews, deployment, and support. Two thirds of an engineer's week, gone before they write a line.

But the real killer wasn't the time. It was the metrics.

Teams began to measure velocity instead of value. Story points became a currency for negotiation rather than a tool for estimation. This is Goodhart's Law in action, named after British economist Charles Goodhart: when a measure becomes a target, it ceases to be a good measure. Velocity was supposed to be an internal calibration tool. It became a management scoreboard. Teams learned to inflate points. Managers learned to demand more of them. Nobody learned to ship faster.

The Digital.ai State of Agile Report tells the punchline: 58% of organizations practice Scrum, making it the dominant framework. The top cited barrier to adoption? "Organizational culture at odds with agile values."

The most popular agile framework's biggest obstacle is its own organizational mismatch. The framework ate itself.

The Certification Industrial Complex

Let's talk about the elephant in the room.

The Scrum Alliance has issued over 1.5 million certifications globally. A two-day course runs $995 to $1,495. No coding required. No product management experience needed. Just the ability to memorize the Scrum Guide and facilitate meetings. The broader Agile training and certification market, including SAFe, Scrum.org, and ICAgile, is estimated at over $2 billion annually.

That's not an industry that supports a methodology. That's a methodology that supports an industry.

I call this the Credential Trap: a system where the people most qualified to critique the methodology are the ones whose livelihood depends on its continued dominance. Economists have a name for the same dynamic in regulation: regulatory capture, where the regulated industry ends up controlling its regulators. The Scrum certification ecosystem is regulatory capture applied to software methodology.

It's not new, either. The medieval guild system operated on the same logic. Guilds controlled who could practice a trade, set prices, and maintained their monopoly through apprenticeship requirements that served the guild's interests more than the public's. Access to the credential gated access to the role. Access to the role gated access to the budget. The guild thrived. The work didn't necessarily get better.

Dave Thomas, one of the original signatories of the Agile Manifesto, saw this coming. He wrote in 2014:

The word "agile" has been subverted to the point where it is effectively meaningless, and what passes for an agile community seems to be largely an arena for consultants and vendors to hawk services and products.

The man who helped write the manifesto watched the movement get eaten by the consulting class it was supposed to make irrelevant.

What Actually Works

Here's where most Scrum critiques go wrong. They tear down the ceremonies, then offer the same vague advice: trust your team, minimize meetings, measure outcomes. Fine. True. Useless.

I want to be more specific. And I want to borrow from a discipline that solved this problem decades ago.

In the 1980s, the U.S. Army adopted a doctrine influenced by the German concept of Auftragstaktik, or mission-type tactics. The principle: a commander states the intent, not the method. Subordinates execute based on local conditions, using their own judgment, adapting in real time. The commander doesn't tell the squad leader which route to take. The commander says: take that hill.

Scrum is the opposite. Scrum is requiring every squad leader to file a report at headquarters before engaging. It's mandating a synchronous briefing every morning regardless of whether there's anything to brief. It's measuring how many hills were attempted per two-week period instead of whether the right hills were taken.

The research backs up Auftragstaktik for software teams, too. Paul Graham's "Maker's Schedule, Manager's Schedule" essay articulated why synchronous ceremonies are uniquely destructive to creative work. Gloria Mark at UC Irvine found it takes an average of 23 minutes to return to a task after an interruption. Gerald Weinberg's research on context switching showed that working on two projects simultaneously reduces productive time to 40% per project, with 20% lost to switching. Three projects? 20% per project, 40% lost entirely.

Every standup, every sprint planning, every backlog refinement is an interruption that costs 23 minutes of recovery time on top of the meeting itself. For a developer in 17 hours of weekly ceremonies, the true cost is closer to 25.

Here's the Auftragstaktik model applied to software:

Commander's Intent over Sprint Planning. Define the outcome, not the process. The team decides how to get there.
Decentralized Execution over Daily Standups. Trust the people doing the work to coordinate themselves. They're closer to the problem than any ceremony can be.
Outcome Metrics over Velocity. Did the feature ship? Did users adopt it? Velocity tells you how fast the treadmill is moving, not whether you're going anywhere.
Asynchronous by Default. Synchronous ceremonies are expensive interruptions. Default to async. Meet when the situation demands it, not when the calendar says so.

What Comes Next?

I can hear the objection already. Isn't "just trust the team" what every Agile critic says right before everything descends into chaos?

Fair. I've seen that movie too. The answer isn't no process. It's a different metaphor entirely.

If Scrum is the rugby metaphor, fifteen players packed together, pushing in the same direction through sheer collective force, progress measured in meters gained, then we need a different sport. One with four players instead of fifteen. Where every person has a distinct role. Where precision matters more than brute force. Where the path to the goal isn't a straight line but a carefully planned curve.

We need Curling.

In curling, the most important person on the ice isn't the one throwing the stone. Think about what that means for your team.

Next post: Curling: The Framework That Replaces Scrum