The linear, phase-gated process everyone calls "waterfall" comes from a 1970 paper that drew it as the thing to avoid. Winston Royce drew the pure sequential model as the naive approach, never used the word "waterfall," and spent the rest of the paper proposing iteration to fix it. The industry kept his cautionary diagram and dropped the caution — then spent decades mandating the version he warned against. This leaf is the history straight, and the honest other half: where phase-gated development is still the right call.
Waterfall is a development discipline in which work moves through fixed phases — requirements, design, implementation, verification, maintenance — and each phase completes and is signed off before the next begins. Change is controlled formally; the plan is fixed early; the sequence flows one way, like water over a series of ledges. Strip the caricature and it is a context-and-commitment-transfer discipline, optimised for one specific case: that the requirements are genuinely knowable, and correct, up front.
That framing is the point of rhyme with the rest of this branch. Planning with agents argues that sprint ceremonies were always about transferring context to a worker who holds none; waterfall is the same instinct pushed to its extreme — transfer all the context, once, up front, and freeze it. When requirements really are fixed, that's efficient. When they aren't, freezing them early is the whole problem.
Waterfall bets that you can know the right thing to build before you build any of it, then locks that bet in with phase gates. The bet pays off exactly when requirements are fixed and verifiable in advance — and fails, expensively, every time they turn out not to be.
The paper cited as waterfall's origin is Winston Royce's Managing the Development of Large Software Systems (Royce, 1970, IEEE WESCON). Read it and the story inverts. Royce drew the pure sequential model — each phase finished before the next — as his Figure 2, the naive approach, and called it, in the one line this leaf will quote him on, "risky and invites failure." The rest of the paper is the correction: feedback between adjacent phases, and "doing it twice" — building a throwaway pilot first so the hard lessons land before the real build.
He never wrote the word "waterfall." The industry took the diagram he presented as a warning, discarded the five iterative fixes he wrapped around it, and institutionalised the picture. (A comparable staged model had been presented earlier by Benington in 1956, so Royce didn't invent the sequence — but he is the one blamed for it.)
The word "waterfall" first surfaces in Bell & Thayer (1976). The mandate came from defence procurement. DOD-STD-2167 (4 June 1985) and its revision DOD-STD-2167A (29 February 1988) codified phase-gated, document-heavy development for US defence contractors — and both were widely criticised as waterfall-biased. From there the shape radiated into PMBOK- and PRINCE2-flavoured governance and into regulated industries generally. The irony states itself cleanly: the model drew its institutional authority from a standard arguing for exactly what its supposed originator's paper had argued against. By MIL-STD-498 (1994) the DoD had walked it back, explicitly permitting incremental and evolutionary strategies.
And the "waterfall dominated software for thirty years" story is itself partly myth. Larman & Basili trace iterative and incremental practice back to the 1930s–50s, running alongside waterfall the entire time. Waterfall was heavily mandated — in defence and regulated builds especially — not universally practised. The teams shipping working software were often iterating quietly under a plan-driven cover sheet.
The structural objections are, tellingly, the ones Royce made first. Testing is deferred to the end, so the first time real timing and I/O behaviour is observed is too late to fix cheaply — his Figure 4 point exactly. Requirements are assumed correct and frozen when they rarely are. Feedback latency is long and delivery is big-bang: you learn whether you built the right thing at the moment it is most expensive to have been wrong.
The figures everyone reaches for come from the Standish CHAOS Report (first published 1994), whose 1994 data is widely quoted as roughly 16% of projects successful, 53% challenged, 31% failed, with average cost overruns near 189%. State them with their critics in the same breath: Jørgensen & Moløkken, and Eveleens & Verhoef, argue the sample skewed toward failures and that the overrun figure is far higher than comparable surveys. CHAOS is a contested, self-reported dataset, not a clean verdict on waterfall — the gap between its influence and its rigour is the genuinely interesting part.
The Manifesto for Agile Software Development (2001) was the organised reaction to heavyweight up-front process. It is the antithesis of waterfall, not a proven cure for it — treating "agile succeeds more" as settled fact is Standish's own disputed framing, and this leaf declines to repeat it. What's true and duller: iterative delivery attacks waterfall's specific failure mode — late, concentrated feedback — by moving the feedback early and often.
Waterfall is the wrong default for software, and it is not wrong everywhere. It remains the rational choice when three things hold at once: requirements are genuinely fixed and externally specified, the cost of change mid-build is very high, and an auditable phase-gate trail is a hard external requirement rather than a nicety. Regulatory submissions, certified safety-critical systems, hardware with long-lead-time tooling, and fixed-scope / fixed-price contracts all sit in that shape — you cannot iterate a bridge or a medical device the way you iterate a web app.
Fixed-price public-sector tenders and heavily regulated builds — POPIA/FSCA-audited, safety-certified — still contract on phase gates in South Africa, because the versioned phase sign-off is the change-control evidence the reviewer asks for. That is the same move the agent-ops leaves make with "the PR trail is the audit record" — here the artifact is a signed gate rather than a merged pull request. If your contract or your regulator demands a documented, approved sequence, a phase-gated method isn't nostalgia; it's the deliverable.
The agent era does not revive waterfall, but it changes one term of the trade. Thorough up-front specification — waterfall's one real virtue — just got cheap: an agent can draft the spec, the tests, and the plan in an afternoon. That is exactly the tension planning-with-agents names when it says spec-driven development is not waterfall with extra YAML. The difference is that the spec is now living and cheap to change, not frozen and expensive to touch. Cheap specification is not the return of the frozen plan; it's the removal of the reason the plan had to freeze.
The anti-hype position is not "waterfall bad, agile good." It's narrower and more useful: waterfall is wrong by default in software, and right by exception where change is genuinely expensive and requirements genuinely fixed. Naming that exception honestly — instead of declaring the method dead — is what separates an engineering judgement from a slogan.
Read Royce's actual paper before repeating what "waterfall" supposedly says. The Standish figures and the DoD standards are cited inline above with their dates; the primary anchors are below.