Agile Versus Waterfall Was the Wrong War — and Leadership Used It to Avoid Judgement
Methods amplify the temperament of the organisation using them.
The programme chose a side and lost the problem
The steering meeting was meant to decide how to recover a six-month delay. Instead, it became a debate about whether the programme was “truly agile.”
One group argued that the plan had failed because it was too detailed, the governance too slow and the business too distant from delivery. Another argued that the agile teams had failed because scope was fluid, dates lacked credibility and no one could see the whole dependency picture. Both sides brought evidence. Both were partly right.
After two hours, the programme had chosen a methodology and postponed the recovery decision.
This pattern has become familiar. Agile and waterfall are no longer merely approaches to organising work; they have become tribal identities. Teams use the method to explain their virtue and the other method to explain failure. Leadership, relieved to receive an apparently clear choice, asks which camp should win.
That is the wrong question. The methodology war persists because it allows organisations to debate belief instead of exercising judgement.
The argument became moral
The strongest claims on both sides are operational. Iterative delivery exposes assumptions early, invites regular business feedback and reduces the risk of discovering at the end that the wrong thing has been built. Planned, staged delivery creates visible commitments, coordinates dependencies and protects work where late change is expensive.
But the language around the methods has become moral.
Agile is associated with trust, adaptability and customer value. Waterfall is associated with command, bureaucracy and resistance. From the other trench, planned delivery represents discipline, accountability and engineering seriousness, while agile represents improvisation, weak commitment and developers avoiding dates.
Once methods carry character judgements, evidence becomes difficult to hear. A missed milestone proves that planning is obsolete. An unstable backlog proves that agility lacks control. Success is credited to the method; failure is blamed on incomplete adoption or contamination by the other camp.
This is not learning. It is identity preservation.
The practitioner sees a more awkward reality. Organisations rarely operate in either pure form. They approve budgets annually, contract suppliers against defined obligations and govern risk through committees. At the same time, they need to test requirements, demonstrate working software and respond to what users learn. The real work contains both uncertainty and commitment.
A method becomes dangerous when it denies one of those facts.
The method was asked to settle questions it could not answer
Methodology debates consume leadership because methods offer ready-made answers to questions leaders would rather avoid.
- How much uncertainty are we prepared to fund?
- Which date is genuinely fixed, and why?
- Who may change scope?
- What evidence is needed before committing more money?
- Which dependencies require central coordination?
- Who owns the benefit once working software exists?
No framework can answer these on behalf of the organisation. It can structure the conversation, but authority and risk appetite remain leadership responsibilities.
A composite £18 million programme illustrates the mechanism. Four delivery teams worked iteratively on customer-facing services, while a central infrastructure supplier followed a fixed contractual plan. The programme board demanded a single integrated milestone schedule. The teams responded with quarterly forecasts; the supplier required approved specifications twelve weeks before build.
When integration began, 27 interface assumptions were unresolved. The agile teams said the infrastructure model had prevented learning. The supplier said the teams had failed to define requirements. The board commissioned an “agile versus waterfall” review.
The review took five weeks. During that time, the key decision — whether to fund an interim interface or delay the release — remained unmade. The delay cost approximately £310,000 and consumed the contingency that would have paid for the interim option.
The methods were not the root cause. The programme had never defined how an evolving service would make binding commitments to a contracted dependency.
Where two methods meet, the failure is rarely at the boundary of process; it is at the boundary of authority.
The strongest case for choosing one method
There is a serious argument against methodological pluralism. Mixed approaches can become an excuse for indiscipline. Teams take the flexibility of agile without its transparency, or the controls of staged delivery without its rigorous definition. A so-called hybrid accumulates ceremonies from both and coherence from neither.
Consistency also matters. Common cadence, terminology and artefacts make it easier to move people, aggregate progress and govern a portfolio. Leadership cannot sensibly tailor every project from first principles.
This objection is correct. “Use what works” is not a method; it is a slogan. Careless mixing produces process by negotiation and allows each group to avoid the disciplines it dislikes.
But consistency should apply to principles and decision rights, not to every delivery mechanism.
The organisation can insist on common truths:
- benefits must have owners;
- expenditure must remain justified;
- risks and dependencies must be visible;
- working evidence should be obtained as early as practical;
- authority to change scope and commitments must be explicit;
- teams must be accountable for the quality of what they produce.
How those truths are enacted should depend on the nature of the work. A data-centre move with a fixed physical window is not the same problem as designing a new digital service. A regulatory change with a prescribed outcome is not the same as exploring what customers will use. Methodological uniformity can conceal these differences as easily as methodological chaos.
Stop asking what the programme is
The question “Are we agile or waterfall?” treats the entire programme as one kind of work. Most programmes contain several.
Some work has high uncertainty and cheap feedback. It benefits from short cycles, demonstrations and changing priorities. Some has low uncertainty but expensive sequencing. It benefits from detailed planning and controlled handoffs. Some combines uncertain design with an immovable external date. It requires learning early and commitment later.
A more honest view separates the work by the decisions it contains:
| Decision condition | Useful discipline |
|---|---|
| Outcome unclear, feedback available | Short iterations and working demonstrations |
| Outcome clear, sequence constrained | Planned stages and dependency control |
| External commitment fixed | Early risk retirement and explicit contingency |
| Several teams share interfaces | Integrated technical decisions and common cadence |
| Supplier obligation must be binding | Clear acceptance evidence and change control |
This is not a compromise between camps. It is a refusal to make the method carry more meaning than it can bear.
The programme in the composite example recovered when it stopped arguing about labels. Service design remained iterative. Interface decisions moved onto a fortnightly integration cadence with named owners. The infrastructure supplier received binding interface baselines at agreed points, with a priced mechanism for later change. The board governed expenditure, release risk and benefits rather than sprint content.
No side won. The programme became governable.
Leadership cannot outsource temperament
The methodology war also reveals a deeper attraction: methods promise to correct organisational character.
An organisation slow to decide adopts agile in the hope that iterations will create decisiveness. An organisation uncomfortable with uncertainty adopts detailed planning in the hope that the plan will create certainty. Neither works for long.
Agile practices make indecision visible; they do not force a sponsor to choose. A detailed plan records assumptions; it does not make them true. A daily meeting cannot repair divided authority. A stage gate cannot compensate for absent business ownership.
Methods amplify the temperament of the organisation using them. In a trusting, decisive environment, iterative delivery produces rapid learning. In a fearful environment, the backlog becomes another queue awaiting approval. In a disciplined environment, staged delivery coordinates complex work. In a defensive environment, the plan becomes evidence that nobody is at fault.
That is why the same framework can produce radically different outcomes.
The honest account
The methodology wars were never really about the relative merits of iteration and sequence. Those merits are observable and conditional. The war grew because methods became proxies for deeper disputes: control versus autonomy, commitment versus learning, central authority versus team judgement.
Those disputes cannot be resolved by declaring one side modern and the other obsolete.
Programme leaders should be suspicious whenever a delivery problem is explained primarily as a failure of methodological purity. The useful questions are more concrete:
- What did we need to learn, and when did we obtain evidence?
- What commitment did we make, and who had authority to change it?
- Where did work wait for a decision?
- Which dependency crossed a team or contract boundary?
- What consequence did the chosen method help us manage — and which did it hide?
These questions make less stirring conference material than “agile versus waterfall.” They also recover programmes.
The practitioner’s honest conclusion is not that both methods are equally good or that every organisation should invent a hybrid. It is that methodology is a set of disciplines, not an identity.
Leadership must choose those disciplines deliberately, connect them at their boundaries and remain accountable for the trade-offs. When it fails to do so, teams fight over the flag while the programme loses time, money and the ability to decide.