When agile approaches were created, developing software was an entirely human activity. People wrote code, ran tests, documented, integrated components, fixed errors, and all of that took time. Sprints emerged as a way to organise that work - a period of one to two weeks - that allowed teams to plan, develop, assess what was delivered and audit the way of working itself in a logic of continuous improvement, until reaching the highest possible speed. Rituals that, despite the dynamism and the pace of value delivery, kept the multidisciplinary team from being constantly interrupted or having its priorities changed, while providing some predictability.
In a previous reflection I wrote about how AI is changing the "build or buy" dilemma in the public sector. The point was that AI reduces the friction between those who understand the problem and those who can turn it into a working solution, and that as a result the real difficulty moves to design, architecture and governance. I now want to move from the strategic side to the operational dimension of the transformation and look at what happens to project management when that acceleration reaches the ground.
Production stopped being the bottleneck
The whole structure of ceremonies we know, the planning, the daily, the review, the retrospective, was designed around the constraint that developing was expensive and slow. If a feature takes days or weeks to take shape, it is reasonable to plan in blocks, protect the team from constant shifts in priority and create formal moments to show what was done and gather feedback. These principles are good, they were tested and they work, I am not saying they are wrong, but the context has changed and it is fair to ask whether these rituals still apply.
Today an AI agent can write a feature, create the tests, review the code and suggest improvements in minutes. Anyone working with these tools day to day knows this is not a promise about the future, it is the current reality - with nuances worth not hiding. This speed is mostly true when building from scratch. When there are legacy systems to integrate, security validations, controlled environments and reference architectures that impose separation between components and teams, things do not lose their complexity, not least because in a large system the production of a feature can be fast and everything else around it can remain slow.
But that is precisely why the point still stands. The cost of producing a first working version has fallen drastically and, when one part of the process accelerates like this, the assumptions the ceremonies were designed around no longer hold. Continuing to manage as if writing software were the most expensive step in the process, when it no longer is, means managing with an outdated map.
I feel this in practice - there are moments when the speed of solving problems and building features is so fast that it feels like we are just performing, waiting for the end of the sprint to formally present something that has been ready, tested and validated for days. Sprint plannings where we discuss whether we "have capacity" to build certain features when everyone in the room knows capacity is not the problem. Reviews showing work everyone has already seen.
In my team we have stopped doing story points and task sizing, not because we disagree with the methodology but because it stopped measuring anything useful. Estimating effort made sense when human execution effort was the scarce resource to manage; now that a significant part of execution is done or amplified by agents, in the time we would spend estimating a feature the development is already done.
None of this means the ceremonies are useless. The daily still serves to align people and the retrospective is still one of the best instruments for improving how a team works. The problem appears when the fixed cadence, designed to protect a slow workflow, starts imposing artificial waits on a workflow that is no longer slow. Waiting two weeks to review a feature that was ready in twenty minutes goes against agile's own principle of delivering value fast.
Where the effort moved to
In a large programme, with several teams and modules that have to work together, what consumes most of our time and energy today is not building features. It is the alignment between cross-cutting modules and between teams, it is release management, it is knowing where changes were made and making sure the various environments, configurations and pipelines are consistent with each other. The effort curve has moved from production to coordination, integration and decision.
In practice, smaller teams with high delivery capacity are far easier to coordinate than large ones. With the production capacity AI gives each person, having too many people on a project has stopped being a synonym for speed and often become a synonym for entropy - more dependencies, more alignment, more confusion about who touched what.
This new way of working is being called "agent driven development", continuous cycles where a requirement comes in, one agent implements, another tests, a third reviews, the system deploys, monitors, generates feedback and immediately a new cycle begins. If execution tends towards the continuous, managing in fixed blocks of time stops making sense.
The bottleneck has become the decision. Deciding what to build and what is a priority, validating results, ensuring quality, managing risk. Execution speed has increased but decision speed is still human, and the focus of the project manager also has to change. Instead of asking who is going to carry out an activity, you decide what deserves to be carried out and whether the result can be trusted. Instead of controlling tasks, you orchestrate flows. Instead of tracking hours worked, you track the quality of decisions and results. Instead of managing the project team, you start managing "upwards" - the project sponsor, the steering committee, whoever holds the power to decide.
Reinventing without throwing away
I distance myself from those declaring the death of agile - and of project management as a whole. The principles not only remain valid, they seem more current than ever. Delivering value early and continuously, working with MVPs that help identify the path before investing everything in one direction, short feedback cycles, adaptation instead of rigid plans - in a world where things change so fast that we cannot rely on the past to prepare for the future, this logic is all the more necessary.
What is at stake are the practices that stayed tied to the context they were born in. The two-week sprint, story points, the fixed cadence of ceremonies, all of that was designed to manage a scarce resource that is ceasing to be scarce. I do not know exactly what replaces the sprint structure in a context of near-continuous execution, nor where the line sits between adapting practices and throwing away discipline, because ceremonies also serve to align people and people still need alignment. What I do know is that the future of project management will rest mostly on what is strictly human - judgement, decision, change management, risk - less on the analysis and information-processing side, where agents do more and more, and more on the human interaction side of sensing when it is time to change course or stop a project, influencing, negotiating, bringing people along with the pace of change. Removing the daily does not remove the need to know what is going on. The question is whether that alignment needs a ritual on a fixed cadence or whether it can happen continuously, like the execution itself.
Perhaps the future of agile management is not abandoning agile but reinventing it for teams made up of people and AI agents working together - keeping the principles, questioning the practices and accepting that some ceremonies which for years were a synonym for good method may be turning into ritual. The sprint was an answer to a problem that is disappearing. In a world where execution tends towards the instantaneous, what remains genuinely scarce is human judgement, deciding well what to build, for whom and why.