Every so often, someone declares Scrum dead. Usually, it coincides with the arrival of something shiny, a new methodology, a new tool, a new reason to believe that this time, complexity has finally been solved. This time, the obituary writers have AI on their side, and I’ll grant them this much: they have a point, just not the one they think they’re making.
I run Scrum.org, so take my bias as read. But what I’m about to argue isn’t a defense of an institution; it’s a warning about what happens to development teams that abandon structure precisely when they need it most.
Here’s what’s actually happening. AI is making individual developers dramatically faster. Code gets generated in seconds. The boilerplate that took an afternoon is done before the coffee is poured. If you measure a single developer’s output on a structured, well-defined task, AI can deliver a real improvement. That part of the story is true, and anyone who tells you otherwise is selling something.
But here’s what the productivity enthusiasts aren’t telling you. Faster individuals do not automatically produce better teams. In fact, the evidence suggests they often produce worse ones. McKinsey’s 2025 State of AI report surveyed nearly 2,000 organizations across 105 countries and found that while 88% now use AI regularly in at least one function, 94% report not seeing significant value from those investments. Think about that for a moment. Near-universal adoption, negligible enterprise-level impact. Individual perception of productivity, flat organizational reality.
The speed paradox
The independent research on development teams specifically is even more striking. METR, a non-profit research institute, ran a randomized controlled trial in 2025 with experienced open-source developers working on their own codebases. Developers using AI tools took 19% longer to complete tasks than those who didn’t. The kicker: those same developers estimated afterward that AI had made them 20% faster. The gap between what they believed and what the data showed is not just a curiosity; it is a warning signal about how thoroughly AI can distort our ability to assess our own performance.
Meanwhile, a longitudinal analysis of 211 million lines of code by GitClear found that as AI coding adoption rose, refactoring activity collapsed from 25% of code changes in 2021 to under 10% in 2024, while code duplication increased eightfold in a single year. More code, faster, with less quality, less reuse, and a mounting maintenance burden that hasn’t shown up in anyone’s velocity metrics yet.
I call this the speed paradox. AI accelerates the individual and, in doing so, can quietly destroy the team. Faster individuals diverging on different tasks, with different assumptions, generating more output with less shared understanding, create not a productivity engine but a coordination crisis. The bottleneck doesn’t disappear. It moves upstream, from execution into alignment, judgment, and governance. Which is precisely where Scrum lives.
Scrum was designed for exactly this kind of problem. Not for predictable work where requirements are known and the path is clear, any decent project plan handles that. Scrum was designed for complexity, for situations where the answer cannot be known in advance and where the only sensible response is to make small bets, learn fast, and change course. Sprint Goals force a team to agree on a single valuable outcome rather than a collection of tasks. The Sprint Review brings real evidence of value to stakeholders rather than a volume of shipped code. The Definition of Done prevents AI-generated output from silently accumulating debt. None of that matters less when AI is in the room. It matters more.
Capability debt
There is a subtler problem beneath the speed paradox that I want to name, as it rarely comes up in AI adoption conversations. This is called capability debt. When AI takes over the execution tasks, writing the function, drafting the test, and generating the documentation, those are the same tasks that used to build junior developers’ judgment. Anthropic’s own researchers, Judy Shen and Alex Tamkin, ran a randomized controlled trial in 2026 to study how developers learned a new programming library with and without AI assistance. Participants who used AI scored 17% lower on comprehension assessments than those who coded by hand, without finishing meaningfully faster. The largest gap appeared specifically in debugging ability, which is precisely the skill you need most when your job is to oversee and evaluate AI-generated output. We are, in other words, using AI to skip the learning that makes humans capable of supervising AI. That is a compounding problem, not a one-time cost.
This connects to the fact that most organizations misunderstand AI fluency. The mistake is treating it as an individual-capability problem: give everyone access to tools, run a few training sessions, and watch productivity climb. But individual fluency is not team capability. There are meaningful levels at which practitioners engage with AI. At the foundational level, the primary concern is safe, intentional use without passing on hallucinations. At the practitioner level, where most developers sit today, fluency improves individual output but introduces a subtle trap: the more effort you invest in crafting a prompt, the more likely you are to trust the result without adequately scrutinizing it. Better prompting can paradoxically lower your evaluation guard. The antidote to that trap isn’t better tools. It’s the kind of shared review, collective accountability, and structured inspection that a well-run Scrum Team builds as a matter of practice. The third and most valuable level of fluency is about designing the team’s AI workflow, not just your own, and it is inherently a team-discipline problem.
The teams getting the most genuine value from AI are not the ones that abandoned structure. They are the most disciplined ones, where Sprint Goals give AI a direction to work toward, where a shared Definition of Done prevents technical debt from quietly accumulating, and where the Retrospective institutionalizes AI learning at the team level rather than leaving it to individual experimentation.
So no, Scrum isn’t dead. We are at the precise moment where empiricism, shared goals, collective accountability, and structured inspection become the difference between AI making your team genuinely better and AI making your team faster at producing the wrong things. Those are not the same outcome, and the gap between them will define which development organizations look back on this moment as the year they got it right, and which ones are still untangling the consequences.
