Agile Vs Waterfall, The Honest Comparison

The agile-versus-waterfall argument is conducted almost entirely between straw men. One side describes a world of eighteen-month specifications and signature ceremonies that nobody has defended in print for two decades. The other describes a world of undisciplined teams refusing to commit to anything, which is equally a caricature and equally useless as a basis for deciding how to run your programme.

The argument persists because it is conducted at the wrong level. It is framed as a choice of organisational identity — what kind of company are we — when it is properly a choice made per workstream, on the basis of two variables: how much you know at the start, and how expensive it is to change your mind later. Answer those two honestly and the appropriate approach is usually obvious. Refuse to answer them and you get the thing most large organisations actually have, which is iterative ceremony bolted onto sequential governance, producing the costs of both and the benefits of neither.

What follows is the case for sequential delivery made properly, the case against it made properly, and a way of choosing that does not require anyone to lose an argument about values.

Royce, and what he actually argued

The sequential model is usually traced to a 1970 paper by Winston Royce on managing the development of large software systems. It is worth knowing what the paper says, because it is cited constantly by people who have not read it and who would be startled by its contents.

Royce did present a diagram of sequential phases — requirements, analysis, design, coding, testing, operations. He presented it as the way large systems were then being built. He then spent the remainder of the paper arguing that this approach, implemented naively, was risky and invited failure, principally because the phases where the greatest uncertainty lives — design and testing — sit at the point where the cost of correction is highest. His recommendations included building the thing twice, with the first version treated as a pilot to retire uncertainty; involving the customer throughout rather than at the boundaries; and iterating between adjacent phases rather than treating each gate as final.

The word "waterfall" does not appear in the paper. What happened subsequently is that the diagram was extracted, the caveats were discarded, and the stripped version was codified into defence procurement standards and from there into corporate practice, where it became the default for a generation. The model that dominated software delivery for thirty years is, in a real sense, the illustration from a paper arguing against it.

This is not merely a historical curiosity. It tells you what the actual failure mode of sequential delivery is, and it is not "planning". It is the deferral of the riskiest learning to the most expensive moment.

What sequential delivery is, when done well

Set aside the caricature. Competent stage-gate delivery has real properties that iterative delivery does not automatically provide.

It produces a single agreed scope that many parties can coordinate against. When a programme involves six suppliers, a hardware build, a physical rollout and a regulator, the specification is not bureaucratic overhead — it is the coordination mechanism, and there is no cheaper substitute.

It produces cost and schedule commitments that can be contracted and financed. Capital allocation processes in most large organisations require a number before work starts. A sequential plan supplies one. An empirical approach supplies a better forecast later, which is analytically superior and commercially inconvenient.

It produces auditable evidence of control, phase by phase, in exactly the form that assurance functions and regulators are trained to consume. This is a genuine advantage, not just an accommodation to bureaucracy, and it is the reason stage-gate persists in environments where the consequences of failure are measured in lives rather than in churn.

And it front-loads decision-making into the period when change is cheapest, which is the correct strategy whenever the cost-of-change curve is steep. This is the crux of the whole comparison.

The cost-of-change curve decides everything

Every delivery approach is an implicit bet about how expensive it is to change your mind at time t.

For a printed circuit board, a pharmaceutical trial protocol, a building's structural design or a regulated financial product that has been filed with a supervisor, the curve is brutally steep. Changing the design during fabrication costs orders of magnitude more than changing it during design, and sometimes the change is simply not available at any price. Under a steep curve, extensive up-front analysis is not waste. It is the cheapest form of the work.

For most business software, the curve is nearly flat, and has become flatter with every improvement in automated testing, infrastructure-as-code and deployment tooling. If the cost of changing your mind on Thursday is roughly the cost of changing your mind on Monday, then deferring the decision until Thursday is free information. The whole argument for iterative delivery reduces to this: when change is cheap, commitment is expensive, because commitment forecloses learning you could have had for nothing.

Where each approach genuinely wins

Factor	Sequential / stage-gate wins	Iterative / empirical wins
Requirements certainty	Known, stable, externally specified	Hypothesised, contested, discovered through use
Cost of change late	Steep — physical build, filed design, safety case	Flat — software, reversible, automated verification
Deliverable	Physical, regulated, or contractually fixed	Digital, incrementally usable
Coordination	Many parties on fixed dates; specification as contract	Small number of teams with direct customer access
Feedback availability	No usable feedback until the whole exists	Partial delivery generates real usage signal
Funding model	Capital approval requiring a number up front	Rolling allocation against demonstrated outcomes
Assurance	Phase evidence for an auditor trained on gates	Continuous evidence, automated controls
Primary risk	The plan was wrong and you find out at the end	Drift, no forecast, local optimisation

Read that table honestly and two things follow. First, a great many organisations have workstreams in both columns and should be running both. Second, the left-hand column describes a much smaller share of modern software than its share of modern governance would suggest — most organisations govern as though everything were in the left column because that is how the finance and assurance functions were built, not because the work requires it.

The failure modes are different, and both are real

Sequential delivery fails by discovering the important thing too late. Integration reveals an incompatibility in month fourteen. User testing at the end reveals that the workflow the specification described is not how the job is actually done. The failure is concentrated, arrives near the end, and is maximally expensive.

Iterative delivery fails by optimising locally forever. Each increment is sensible; the sum is incoherent. Architecture erodes because no increment justified addressing it. Nobody can answer when the thing will be finished, and after four quarters the answer "we are responding to feedback" stops being credible to the people paying. The failure is diffuse, arrives gradually, and is maximally political.

Notice that neither failure mode is a moral defect. Each is the predictable consequence of the approach's own logic taken without compensating discipline. Sequential delivery needs early risk retirement — the thing Royce actually recommended. Iterative delivery needs architectural intent, an outcome that can be judged, and an honest forecast from throughput data rather than from optimism.

Most organisations run a hybrid, and should say so

What large organisations actually do is fund annually against a business case, plan the year in phases, run the delivery teams in sprints, and release through a change board into a quarterly window. The team is agile. The programme is not. The two are separated by a layer of translation whose full-time job is converting empirical reality into gate-shaped evidence.

This arrangement is worth naming precisely because the people inside it usually cannot: it is examined as water-scrum-fall, and it is the modal state of enterprise delivery rather than an aberration.

The honest position is that hybrids are legitimate. A programme with a hardware dependency, a regulatory filing and a software product genuinely has different work in different quadrants, and forcing a single method across all of it is doctrinaire. What is not legitimate is the unexamined hybrid — the one where nobody has decided which parts are which, and where the sequential governance is applied to the iterative work by default because that is what the template does.

The test of an honest hybrid is whether you can say, for each workstream, which approach it is under and why. If the answer is "we do agile delivery within a waterfall plan" and nobody can explain which decisions are fixed and which are open, you do not have a hybrid. You have a translation layer.

Choosing, per workstream

Four questions, answered by the people who will do the work rather than by the people who own the method.

Who holds the requirements knowledge, and can we reach them weekly? If the answer is a regulator, a published standard or a signed contract, much of the discovery is already done and sequential planning is efficient. If the answer is "users, and we would have to observe them", you cannot specify your way to it.

What does it cost to change this decision in six months? Get an actual figure, or at least an order of magnitude. This single question resolves most method disputes without any reference to values.

What is the smallest thing that could be put in front of a real user? If a coherent answer exists, iterate. If the honest answer is "the whole system, because half a bridge is not a bridge", stop pretending and plan properly.

What evidence does assurance require, and in what form? Very often this constraint is softer than it looks and is being enforced by habit rather than regulation — see agile in regulated environments. But where it is genuinely binding, it belongs in the decision rather than being treated as an obstacle to route around.

What to do on Monday

List your current workstreams on one page. For each, write down two numbers: a rough percentage of the requirements you would call genuinely settled, and an order-of-magnitude cost of reversing the main design decision in six months' time.

Sort by those two columns. Workstreams with settled requirements and a steep reversal cost should be planned and gated, and you should stop apologising for that. Workstreams with contested requirements and a cheap reversal cost should be delivered in small increments against an outcome, and you should stop asking them for a twelve-month scope commitment they cannot honestly give.

The ones in the middle are where the argument lives, and the useful move there is not to pick a method but to ask what it would cost to flatten the cost-of-change curve. Usually it is test automation, environment provisioning and release path — and usually that investment is cheaper than the coordination overhead you are currently paying to manage around the fact that changing your mind is expensive.