Part I. What changes and what does not
The bottleneck always moves
From waterfall to agents: what got cheaper in each era and what stayed expensive
A story you have already lived
I started developing on large web projects for banks in 2000, at IBM Lotus. An analyst handed us an exhaustive functional document and the project manager split the modules among different people on the team. There were no formal test plans, so whatever the project manager reviewed went straight to production.
As a result, we got a lot of incidents back, and the occasional shouting. It was a "cowboy" project model that kept going because we put in very long hours every day. After 4 years I decided to leave development and move to another department (IBM Rational), where I could help other teams develop better.
The bottleneck shifted from informal communication between colleagues to producing more documentation. But there I discovered something that changed everything: continuous integration. The bottleneck was no longer handing over large blocks of work, but tracking when the flow of tasks passed the technical and functional tests.
Yet there were still big production releases, with all their uncertainty. Then came DevOps and cloud environments. Building and delivering software has become ever faster and cheaper. By then I was no longer doing hands-on development, but I was supporting teams as they adopted those practices and that change of mindset.
Ramón, GymTonic's CTO, put it his own way at the steering committee. "When I joined, a version of the app took three months to reach the stores. With the cloud we started releasing every week. Now the team writes in an afternoon what used to be a Sprint. And even so, the virtual trainer has been stuck for four months." Nobody asked him to explain why.
Each era made one step cheaper
To reach a member, an idea travels a path: someone decides what is worth doing, someone builds it, it is integrated with what already exists, it is tested, it is deployed and someone uses it. That path is the value stream (in Spanish). Each era of software development made one step of that stream cheaper, and each time the jam moved to the next step.
In the nineties, getting it wrong was extremely expensive. Integrating and deploying took weeks or months, so people tried to get it right the first time with phases and documents: requirements, design, construction, testing. The bottleneck was everything that came after writing the code.
At the turn of the century, continuous integration and automated testing made integrating cheaper. That is where XP and Scrum grew: if integrating is cheap, you can deliver something small every few weeks and learn from it. The jam moved to deployment.
In the 2010s, DevOps and the cloud made deploying cheaper. Going from once a quarter to several times a day stopped being a feat. The jam moved to writing: there were more ideas than capacity to build them, and teams organised themselves to protect that capacity.
In the 2020s, AI makes writing code cheaper. And the jam moves again: to deciding what to build, to validating that it works, to reviewing what has been written and to being accountable for it.
What Scrum really protected
Scrum survived each leap because it never protected the programmers' capacity. It protected learning: short cycles so you don't spend months getting it wrong, one person who decides on value, and a review with the people who use it.
Many companies, it's true, used it for the other thing. Sprints to hand out tickets, estimates to negotiate capacity, a Daily to keep control. That ticket-factory Scrum is the one that becomes unnecessary with AI, because the factory is no longer the problem.
The opposing argument, head-on
Some people say Scrum is no longer needed. Jeff Gothelf, in Product Management and AI (Sense & Respond Press, 2026, chapter 1), writes that when producing a feature takes minutes rather than months, delivery stops being an event, and that processes like Agile and Scrum are no longer necessary in the same way. Marty Cagan talks about the AI productivity paradox: teams go faster and companies cannot say what they have gained.
They are right about what they criticise. If your Scrum was about protecting the capacity to build, with AI you don't need it. But what they propose instead (hypotheses, experiments, measuring how people's behaviour changes and deciding with that evidence) is Scrum's empiricism (in Spanish) done well. They don't replace Scrum: they strip away what it should never have had.
The uncomfortable data
There is a figure worth keeping at hand when someone says AI speeds everything up. The 2024 DORA report, which measures every year how thousands of teams deliver software, found that a 25% increase in AI use was associated with a drop of around 7% in delivery stability and 1.5% in delivery throughput.
A 2026 study points in the same direction, with real usage data. Three economists from MIT and Wharton (Mert Demirer, Leon Musolff and Liyuan Yang), in a paper published by the NBER (the US National Bureau of Economic Research), followed more than 500,000 GitHub developers and compared their work before and after using AI tools.
With autonomous agents, the code changes they pushed (commits) rose by 240%. But the effect faded as it got closer to the user: projects grew by 80% and published releases by only 30%. In the app stores they analysed, many more new apps appeared, but total usage did not grow.
The authors attribute this to the human bottlenecks in the chain: AI multiplies what gets written, not what ends up being used.
More speed in one step is not more value in the stream. If writing gets faster and reviewing doesn't, code piles up in front of review and reaches production in worse shape. We will come back to this in chapters 11 and 13.
In short
Each era made one step of the value stream cheaper and the jam moved to the next one. With AI, it sits in deciding, validating, reviewing and being accountable. That is exactly what Scrum does well when it is used to learn and not to hand out tasks.
Try it this week
Go over the events of your last Sprint and, for each one, write down a decision that was made in it. If none of them decided anything, the critics are right about you, and chapter 10 is for you.
If you want the short version of this argument to share with your team, it is in the article AI has not killed Scrum (in Spanish).