What Comes After Agile and Waterfall?
For more than 25 years, organisations have debated whether work should be managed through Agile or traditional plan-driven approaches.
That debate has produced useful insights. It has also become too narrow for the reality of complex delivery today.
Agile still works well at team level. It helps teams collaborate, learn quickly and respond to changing requirements.
Plan-driven approaches still have value where sequencing, integration, assurance and regulatory evidence matter.
But most important products and programmes no longer exist at either level in isolation.
They span multiple teams, technologies, disciplines, suppliers, systems and decision forums. The challenge is no longer simply how one team should work. It is how the whole delivery system should remain coherent while different parts of it move at different speeds.
That is why we need to move beyond the Agile–Waterfall debate.
Agile reflected the challenges of its time
Agile emerged as a response to the development conditions of the late twentieth century.
Software development was often slow, heavily documented and separated from the users it was intended to serve. Requirements were treated as fixed, even when the problem was not well understood. Teams were expected to follow plans created long before the consequences of those plans became visible.
Agile challenged this logic.
It introduced shorter feedback loops, closer customer involvement, incremental delivery and greater autonomy for development teams. It recognised that uncertainty could not be removed through more planning alone.
That was an important correction.
Many of those principles remain valid. The problem is not that Agile has stopped working.
The problem is that the delivery environment has changed.
Today’s products do not stop at the team boundary
Modern products and programmes increasingly combine:
software;
hardware;
data and artificial intelligence;
cloud and digital infrastructure;
cybersecurity;
operations and service delivery;
regulation and compliance;
external suppliers and technology partners;
commercial and organisational change.
A team can work effectively and still fail as part of the wider system.
Its output may depend on an architecture decision made elsewhere. Its release may be constrained by hardware availability, supplier maturity, regulatory approval or operational readiness. Its priorities may conflict with other teams working on the same product or platform.
This is common in complex NPD, NPI, R&D, engineering and transformation programmes.
Local agility is not the same as organisational adaptability.
A group of well-functioning Agile teams does not automatically create an effective programme, product organisation or portfolio.
The real challenge is integration
The central management problem has therefore shifted.
The question is no longer:
Should this team work in an Agile or plan-driven way?
The more important question is:
How should the organisation coordinate different forms of work across one integrated delivery system?
Consider a product combining embedded software, electronics, cloud services and manufacturing readiness.
Each team may deliver effectively within its own backlog. Yet the programme can still miss its market window because hardware maturity, software releases, supplier capacity and production validation are governed through separate plans and decision forums.
No individual team necessarily failed.
The delivery system failed to integrate their work.
That is the real challenge in complex delivery.
Some parts of a product may benefit from rapid experimentation.
Other parts may require detailed engineering, physical prototypes, formal verification or long supplier lead times.
Some decisions can be delegated to teams. Others affect architecture, safety, investment, market commitments or the viability of the entire product.
These differences cannot be resolved by applying one method consistently across everything.
They require a deliberate operating model.
Beyond flexibility versus control
The Agile–Waterfall debate is often framed as a choice between flexibility and control.
That is the wrong choice.
Complex delivery requires both.
Organisations need enough flexibility to respond when assumptions prove wrong, technologies change or customer evidence points in a new direction.
They also need enough control to manage dependencies, protect major investments, integrate technologies and maintain clear accountability.
Too much rigidity creates slow decisions, late learning and unnecessary escalation.
Too much local freedom creates fragmentation, competing priorities and integration problems that only become visible near the end.
The objective should not be maximum flexibility or maximum control.
It should be the right balance between adaptation and coherence.
Adaptive delivery governance
A more useful way to think about the next development is adaptive delivery governance.
This is not intended as another universal methodology.
It is a way of designing governance around the conditions of modern delivery.
Adaptive delivery governance connects:
strategic direction;
investment decisions;
portfolio priorities;
architecture and systems integration;
delivery execution;
evidence and learning;
risk and assurance;
operational readiness;
accountability.
The important word is not only “adaptive”.
The word “governance” matters because adaptation without decision rights and accountability quickly becomes drift.
Good adaptive governance does not mean adding more meetings or approval layers. It means creating clarity about:
which decisions belong where;
what evidence is required;
when assumptions should be revisited;
when teams can act independently;
when integration requires coordination;
when an initiative should continue, change direction or stop.
This is governance as an enabling system, not governance as administration.
Different parts of the system can work differently
One implication is that organisations should stop trying to force one delivery model across all work.
A complex product may combine:
Agile software development;
Stage-Gate investment decisions;
systems engineering;
supplier development;
formal verification;
operational transition;
continuous product discovery.
That is not a failure of methodological consistency.
It is an appropriate response to different types of uncertainty, risk and technical work.
The real discipline lies in connecting them.
The organisation needs shared milestones, clear interfaces, common decision points and a coherent view of risk and value.
Without this, hybrid delivery becomes little more than multiple methods operating beside one another.
Hybrid Agile–Stage-Gate is already one mature form
In complex product development, Hybrid Agile–Stage-Gate is one of the most mature examples of adaptive delivery governance.
It combines iterative development with structured investment and governance decisions.
At its best, it allows teams to learn and adapt while ensuring that senior decision-makers continue to assess:
strategic fit;
customer value;
technical feasibility;
business viability;
integration maturity;
operational readiness;
risk exposure.
But the distinction between good and poor implementation matters.
A weak hybrid model simply places Agile teams inside an unchanged Stage-Gate process. Teams work in sprints, but decisions are still based on outdated plans, fixed assumptions and formal gate presentations.
A stronger model allows evidence from development to change the plan, the business case, the scope and sometimes the direction of the product itself.
The gates are not administrative checkpoints.
They are decision points informed by current evidence.
AI changes the delivery system again
Artificial intelligence adds another reason to rethink the model.
AI can already support:
customer and market analysis;
requirement development;
concept generation;
design exploration;
simulation and testing;
risk identification;
forecasting;
reporting;
decision preparation.
In time, more work will be completed through combinations of people, automation and specialised AI agents.
This changes the speed and volume of delivery.
It also increases the need for stronger governance.
Faster analysis does not guarantee better decisions. More generated options do not remove the need for judgement. Automated recommendations do not remove accountability.
The organisation must still decide:
which evidence is trustworthy;
which assumptions are material;
where human review is required;
who owns the final decision;
when AI-supported work is sufficiently mature to progress.
AI will therefore not make governance less important.
It will make good governance more important.
The unit of management is changing
Agile made the team the central unit of delivery.
That was appropriate for many of the problems it was designed to solve.
But in today’s complex landscape, the team is no longer the only meaningful unit of management.
The relevant unit may be:
the product;
the platform;
the programme;
the value stream;
the technical system;
the portfolio;
the supplier ecosystem.
This does not reduce the importance of teams.
It places them inside a wider system of decisions, dependencies and outcomes.
The next step is therefore not to abandon Agile.
It is to recognise that team agility must be connected to organisational adaptability.
The practical Escape perspective
In complex technology and engineering environments, delivery problems are rarely caused by one team using the wrong method.
More often, the problems sit between teams, disciplines and decision forums:
ownership is unclear;
dependencies remain unresolved;
priorities conflict;
integration decisions arrive too late;
governance reviews status rather than evidence;
different delivery approaches are used without a common operating model.
The practical response is not another methodology transformation.
It is to design the delivery system around the work.
Senior leaders should begin by testing five areas.
1. Decision architecture
Are the critical product, investment and integration decisions clear, with named owners and timely escalation paths?
2. Delivery interfaces
Are the dependencies between software, hardware, suppliers, operations and commercial functions actively managed?
3. Evidence and learning
Can new evidence change scope, priorities, investment decisions and the business case?
4. Governance cadence
Do governance forums make decisions, or mainly review status and request more reporting?
5. Method fit
Is each part of the work using an approach suited to its uncertainty, risk and technical constraints?
Agile practices may be appropriate for some teams. Sequential planning and formal assurance may be essential elsewhere. Hybrid Agile–Stage-Gate may provide the right structure for complex product development.
The objective is not methodological consistency.
It is a coherent delivery system that enables teams to adapt while the organisation maintains direction, integration and accountability.
What comes after the Agile–Waterfall debate is adaptive delivery governance.
In complex product development, Hybrid Agile–Stage-Gate is already one of its most mature forms.
The next step is not to choose a new side in an old debate.
It is to build a delivery system suited to the technologies, organisations and projects we have now.
