When I started as a software engineer about two decades ago, a release of new functionality took months, sometimes more than a year. Agile brought that down to sprints of a few weeks. Today, coding agents build features in days, and that number keeps dropping. But when you ask most organisations whether they deliver faster than two years ago, the honest answer is: not really.
The reason is simple. Coding was always considered the most expensive and time-consuming part of the development cycle, and software development methodologies like waterfall and agile were based on that assumption. Now that it no longer holds, everything but coding has become the new bottleneck, and it is time to rethink, once again, how we will deliver functionality in the software industry.
To better understand where the future of software development might be headed, it helps to understand what we have learned from the past: from waterfall, to agile, to the upcoming agentic software development life cycle, and how these methodologies have reduced the software delivery cycle time and shaped the way people and teams collaborate inside organisations.
Waterfall was built on a premise that was true at the time: building software for complex products is hard, expensive and time-consuming. So we had to get it “first time right” and be efficient in how we collaborated.
Releases with new functionality were planned every 3 to 6 months and were divided into different phases. Multiple teams, each organised around their expertise, collaborated across phases, and when everything was clear the functionality was handed off to the next phase. The collaboration between teams within a phase was usually very efficient, and responsibilities were very clear. Documentation was always rigorously maintained and decisions were tracked and followed up: everybody knew what was expected of them in every phase of the process. IT management really liked this approach, because they felt they could control the flow of new functionality, and they focused on optimising this process.
Unfortunately, this approach had significant drawbacks. The most obvious were that customer feedback came last, requirements were drafted when you had the least information, and changing course mid-flight was nearly impossible. I have witnessed many occasions where software was written and rejected by the client after months of work, because “it wasn’t what they expected”. At the same time, these big-bang releases were nearly impossible to stabilise, and the more complex the system became, the harder it was to get a release out of the door: any delay had an immediate effect on the whole release timeline. The result was a cycle time of months, even for the smallest change.
It became clear that something had to be done, and we started experimenting with agile methodologies. Instead of one big release after months of work, every sprint delivered a working increment that customers could see and react to. If something turned out to be wrong, you learned it after two weeks instead of after a year. The idea: empowered, cross-functional, long-lived teams with end-to-end responsibility for the whole software delivery process. The focus moved to speed of delivery, working software, adaptability to change and direct customer interaction. Combined with the power of git workflows, automated CI/CD pipelines and modern testing frameworks, this greatly improved both the quality and the speed of the software being produced. High-level intake and roadmap were still decided by management, but all the rest was owned by each individual team.
At the start, agile methodologies felt liberating and gave us a sense of purpose and responsibility for the products we were working on. It worked quite well for constellations of a few very mature teams, but as scope increased and less experienced teams got involved, it became harder to keep everyone on the same page. This is why agile is perfect for smaller organisations, while larger organisations have always struggled to move to an agile way of working. They have to manage dozens, sometimes hundreds, of parallel development initiatives. The original concept of empowered, long-lived, cross-functional teams does not scale in these constellations.
To overcome these limitations, companies often introduce scaled agile frameworks (e.g. SAFe) to streamline the company-wide development process. These add standardised processes and interactions to the agile way of working: PI planning, grooming, planning, retro, stand-up, demo. Because everything is in constant flux, it is also hard to find consistent and up-to-date documentation, so most communication is done verbally to keep people and teams on the same page.
Look at where time is spent in a large agile organisation today: most of it goes to communication and collaboration, within the team and with everyone around it. That was acceptable as long as development itself took weeks. Now that development time shrinks to days, collaboration and communication become almost all that we do. The faster we develop, the more often we have to bring an ever longer list of stakeholders up to speed, and the bigger this communication bottleneck becomes. Changing how we communicate and collaborate, so that it matches the speed of development, is where the biggest gains in total delivery cycle time are still to be found. There is nothing wrong with agile. The assumption it was built upon changed almost overnight.
Coding agents with the right skills, tools and harnesses can now write software (almost) faster and better than any human can, and that will only accelerate. There seems to be no limit to what people can create with software, but it has also never been easier to build the wrong thing. Writing software became the easy part. Deciding what to build, and getting everyone aligned, became the hard part.
The companies that collaborate the best will be the winners of tomorrow.
We need a different, more efficient way of collaborating than the verbal exchange we rely on today. This is where agents can help us most, so that collaboration takes less time and avoids rework. Changing to a collaboration model where agents will support humans during all steps of the software development cycle will most likely introduce a shift in the software industry as radical as the transition from waterfall to agile.
Agents will take over the tedious and time-consuming tasks, and people will focus on judgement, vision and direction, while keeping accountability for decisions. This also means that more upfront documentation, discussion, clear processes, decisions and even phase gates can become important again when we do this at scale. That is not a step back. We will iterate over them far faster than before and reduce the cycle time even further, while holding accountability, governance and regulations in much higher regard than agile ever did.
Intake, assessment, requirements, architecture, release and support will have to catch up with the speed that coding agents have introduced for implementation and testing tasks.
People remain at the heart of collaboration and communication, but they will be supported by agents to make that process more efficient. Here is how I expect that to play out.
What we end up with is not a new methodology but the natural evolution of everything we learned along the way. Collaborative workflows supported by agents are the innovation that will get organisations there, and turn them into the winners of tomorrow.
I would like to hear your thoughts and exchange ideas about where we are headed. Please check out my earlier blogposts if you want to know more about Human-Agent Collaboration and how to Improve Team Productivity in software development.
If you are interested to see how this could work in practice, have a look at https://app.expedait.org.