Every now and then, someone says that Scrum is dead. Often, it’s accompanied by the arrival of something shiny, a new way of doing things, a new tool, a new reason to believe that this time, complexity has finally been solved. This time, the obituaries have AI on their side, and I’ll give them this much: they have a point, just not the one they think they’re making.
I use Scrum.org, so take my bias as read. But what I will argue is not to defend the institution; it’s a warning about what happens to advanced teams that abandon the structure when it’s needed the most.
Here’s what really happens. AI makes individual developers much faster. The code is generated in seconds. The boilerplate that took the afternoon was done before the coffee was poured. When you measure the output of a single engineer on a structured, well-defined task, AI can deliver real improvements. That part of the story is true, and anyone who tells you otherwise is selling something.
But here’s what production enthusiasts don’t tell you. Fast people do not automatically produce better teams. In fact, evidence shows that they often produce the worst. McKinsey’s 2025 State of AI report surveyed nearly 2,000 organizations in 105 countries and found that while 88% now use AI regularly in at least one function, 94% report that they see no significant value in that investment. Think about that for a moment. A near universal discovery, the impact of the small business level. An individual’s view of productivity, the flat reality of an organization.
The paradox of speed
Independent research on development teams is even more impressive. METR, a non-profit research institute, conducted a randomized controlled trial in 2025 with experienced open source developers working on their codebase. Engineers using AI tools took 19% longer to complete tasks than those who did not. The kicker: those same developers later estimated that the AI made them 20% faster. The gap between what they believed and what the data showed is not just a curiosity; it’s a warning signal about how AI can distort our ability to evaluate our own performance.
Meanwhile, a longitudinal analysis of 211 million lines of code by GitClear found that as the adoption of AI code increased, refactoring decreased from 25% of code changes in 2021 to less than 10% in 2024, while code duplication increased eightfold in one year. More code, faster, with less quality, less reuse, and an increased maintenance burden that doesn’t show up in anyone’s speed metrics yet.
I call this Speed is a puzzle. The AI speeds up the individual and, in doing so, can silently destroy the team. Fast people who deviate from different tasks, with different assumptions, who produce more product with less shared understanding, create not a productivity engine but a communication problem. The bottle never ends. It goes upward, from killing to planning, judging, and ruling. Which is exactly where Scrum resides.
Scrum is designed for exactly this type of problem. Not for predictable work where the requirements are known and the path is clear, any good project plan handles that. Scrum is designed for weirdness, situations where the answer cannot be known in advance and where the only logical response is to bet small, learn quickly, and change course. Sprint Goals force the team to agree on one key outcome rather than a set of tasks. A Sprint Review delivers real evidence of value to stakeholders rather than the volume of code delivered. The definition of Done prevents the AI generated from silently accumulating credits. None of this matters when the AI is in the room. It is very important.
Skill credit
There is a subtle problem beneath the speed paradox that I want to name, as it rarely comes up in discussions of AI adoption. This is called skill credit. When the AI takes on the tasks of making, writing a task, writing a test, and generating documentation, those are the same tasks that were used to form the judgment of junior engineers. Anthropic’s own researchers, Judy Shen and Alex Tamkin, are conducting a randomized controlled trial in 2026 to learn how developers learn the new library with and without the help of AI. Participants who used AI scored 17% lower on comprehension tests than those who coded by hand, without finishing much faster. The biggest gap appeared specifically in the ability to remove errors, which is exactly the skill you need most if your job is to oversee and evaluate AI-generated products. In other words, we use AI to bypass learning that enables humans to supervise AI. That’s a compounding problem, not a one-time cost.
This includes the fact that many organizations do not understand it AI smoothness. It’s a mistake to treat it as an individual skill issue: give everyone access to the tools, run a few training sessions, and watch productivity rise. But individual fluency is not group fluency. There are reasonable levels at which experts engage with AI. At a basic level, the main concern is safe, deliberate use without conveying false ideas. At the practitioner level, where most engineers sit today, fluency improves each output but presents a hidden trap: the more you invest in making the information, the more likely you are to trust the result without checking it enough. Better information can dramatically reduce your test alertness. The solution to that trap is not better tools. It is the type of shared review, joint accountability, and systematic evaluation that a well-run Scrum Team develops as a practice. The third and most important level of fluency is about designing the AI team’s workflow, not just your own, and is inherently a team management problem.
The teams that get real value from AI aren’t the ones that abandon structure. They are the most disciplined, where Sprint Goals give AI operational direction to look for, where a Shared Definition of Action prevents technical debt from silently accumulating, and where Retrospective centers AI learning at the team level rather than leaving it to individual evaluation.
So no, Scrum is not dead. We’re in a precise moment where power, shared goals, collective accountability, and systematic testing become the difference between AI that makes your team truly better and AI that makes your team faster at producing the wrong stuff. That is not the same result, and the gap between them will define which development organizations look back at this moment as the year they got it right, and which ones are still solving the results.
