How waterfall is wrong for software
We've known for decades waterfall and software don't mix; why do we keep doing it?
You’re working on an automotive assembly line. Your job is to install the steering column assembly and steering wheel. The next car rolls down the line. You grab the parts and lean in, tools in hand and try to fit the column. It won’t fit. Something’s off.
You look closely and realize the mounting point isn’t where it should be — it’s offset by a few inches. You figure, you’ll try anyway. No good. Worse, the chassis is aluminum and your steel column will cause galvanic corrosion on contact. You think to yourself — maybe this car is supposed to have something else entirely — a joystick, perhaps? You’re going to need time to research the platform and figure out what belongs here. But you’re out of time. The line grinds to a halt. Delivery stops. Something unforeseen has surfaced, and you need time to research the right solution.
That’s not how automotive assembly lines work. But it is how software works. Building software is about research, discovery and development.
If you’re new, welcome to Customer Obsessed Engineering! Every week I publish a new article, direct to your mailbox if you’re a subscriber. As a free subscriber you can read about half of every article, plus all of my free articles.
The “big mistake”
Waterfall treats software like an assembly process: define everything up front, hand off designs to builders, assemble in sequence and test at the end. It assumes you know what you’re building before you start building it — the same way an automotive engineer knows every dimension of a steering column before it reaches the assembly line.
The trouble is, software doesn’t work that way. When you’re writing software, you’re inventing something new — combining emerging tools in novel ways to create products that have never existed before. You’re not assembling known parts. You’re conducting research, running experiments and adapting to what you discover. That’s fundamentally a research and development process, not a manufacturing one. It’s more like discovering a new drug therapy than assembling a car.1
And we’ve known this for over fifty years.
We were warned — in 1970
The great irony of waterfall is that the person credited with defining it actually warned us not to use it.
In 1970, Dr. Winston W. Royce — a software engineer at Lockheed who had spent nine years building mission planning and analysis systems for spacecraft — published a paper titled “Managing the Development of Large Software Systems.” In it, he presented the now-familiar sequential diagram: requirements → design → coding → testing → deployment. Then he said this:2
“An implementation plan to manufacture larger software systems, and keyed only to these steps, however, is doomed to failure.”
He said it was “risky and invites failure.” He spent the bulk of his paper explaining why projects should iterate — passing through development “at least twice,” with the first pass serving as a prototype to validate assumptions.
People extracted his diagrams and ignored his warnings.
By 1975, the U.S. Department of Defense had already identified the consequences: a study from the Office of the Secretary of Defense cited requirements changes as the most significant factor in cost growth, alongside poor visibility into development progress and late defect discovery. And yet, in 1985, the DoD formally adopted waterfall as its official software development standard — DOD-STD-2167 — mandating six rigid sequential phases. It took until 1994 for them to replace it.34
The pattern is familiar. The evidence mounts, and the institution keeps doing what it’s always done.
Why waterfall costs more
Barry Boehm’s research at TRW and IBM in the late 1970s quantified what Royce predicted: fixing a requirements error after delivery costs up to 100 times more than catching it during the requirements phase. Even on smaller projects, the multiplier is roughly 4:1. This isn’t surprising if you think about it — in a sequential process, every mistake bakes itself deeper into the foundation with each subsequent phase. By the time you discover the steering column doesn’t fit, you’ve already welded the chassis, painted the body and installed most of the interior.56
This is the hidden tax of waterfall. You pay for certainty up front — detailed requirements documents, comprehensive design specs, elaborate Gantt charts — and then you pay again when reality diverges from the plan. And it always diverges, because software development is research.7
Modern data confirms the cost difference. The Standish Group’s CHAOS Report, drawing from over 50,000 project profiles, found that agile projects succeed at a rate of 42% compared to just 13% for waterfall. Waterfall projects fail outright 59% of the time versus 11% for agile. For large-scale projects, agile approaches are six times more likely to succeed.89
McKinsey’s research found that waterfall-style organizations average 89 days from code completion to production, while agile teams average 15 days. That’s not a marginal improvement — it’s a fundamentally different relationship with time-to-market.10
What does work
If waterfall is a manufacturing process misapplied to research, what does a research-friendly process actually look like?
It starts with acknowledging uncertainty. Software development proceeds through discovery — you formulate hypotheses about what users need, build small increments to test those hypotheses and adapt based on what you learn. Sometimes discoveries open new opportunities you hadn’t anticipated. Sometimes they reveal limitations that force a pivot. Both are valuable signals, but only if your process can accommodate them.
That’s the philosophical shift. But philosophy alone doesn’t ship software. You need a concrete process that embodies these principles — one that’s structured enough to be repeatable but flexible enough to absorb the surprises that research inevitably produces.
An iterative delivery process
The approach I’ve refined over decades — and captured in the Delivery Playbook — organizes software delivery into four overlapping phases: Mobilization, Blueprinting, Delivery and Operations. Each phase contains specific activities, and each activity has clear inputs and outputs protected by quality gates. Think of it as a subway map — you can see where you are, what comes next and what you need before you move forward.11
Here’s why this matters for our conversation about waterfall: every one of these phases incorporates feedback, iteration and course correction. You don’t finish mobilization and hand off a frozen requirements document. You discover your product vision, validate it with stakeholders and revisit it as you learn. Blueprinting doesn’t produce a static design — it produces a target state architecture that evolves as the team’s understanding deepens through techniques like event storming and domain modeling.12
Mobilization marshals the team and launches discovery. You build a product vision, define strategic goals and map your value stream. But you’re not locking anything down. You’re establishing a direction and identifying what you don’t yet know — which, early on, is most things.
Blueprinting is where the real architectural thinking happens. Strategic event storming captures requirements by collaborating directly with the customer — not by having a business analyst disappear for three months and return with a 400-page document. Domain modeling, context mapping and target state architecture emerge iteratively, each activity refining the output of the last. The team builds a shared understanding that no specification document can replicate.
Delivery is where code meets reality. But unlike waterfall’s “build it all, then test it” approach, delivery proceeds in thin vertical slices. You prove the concept-to-production pipeline end-to-end with a steel thread — a narrow slice of functionality that validates your architecture, your deployment pipeline and your assumptions all at once. Then you iterate, expanding from that proven foundation. Each iteration includes specification, elaboration, validation and verification — not as sequential phases but as tightly coupled activities within every increment.13
Operations isn’t an afterthought bolted on at the end. Monitoring, observability and operational readiness are woven into the delivery activities from the start. You don’t discover your system is opaque six months after launch — you instrument it as you build it.
The subway map makes this tangible. Every “stop” on the map follows the same design: goals, inputs, process and outputs. To advance, you need the output from the previous stop. It’s a checklist — not a straitjacket. The structure keeps you honest about following the important steps, while leaving room for the team to adapt their approach, substitute tools and evolve their methods.
The mechanics that make iteration work
Within this framework, specific practices compress the feedback loops, where waterfall stretches across months. For instance, validation of each feature (or “testing”) happens before the feature is coded.
Test-driven development embodies the scientific mindset that software demands. TDD and its cousin BDD aren’t just testing techniques — they’re design disciplines that force you to articulate expectations before writing code, creating a tight feedback loop between intention and validation. We design our experiment before we look for results.
The key insight is blending design thinking with experimentation: you think carefully about what you’re building, then prove your assumptions through working code rather than through documentation and downstream inspection.1415
Shifting left — or moving testing, security and compliance earlier in the development cycle — collapses those same feedback loops. Instead of discovering a flaw in integration testing weeks after you wrote the code, you discover it minutes later, while the context is still fresh. Rather than hastily bolting on observability after a server crashes and customers start hollering, it’s there as a feature from the get-go.16
Every control process you move earlier accelerates the entire pipeline. But waterfall doesn’t allow this to happen: instead, each monolithic stage gate is a barrier stopping the efficient flow of information. It’s creating a static model out of an evolving system.
And crucially, you need a delivery pipeline that integrates experimentation, prototyping and testing as continuous activities — not phases. The steel thread approach I mentioned earlier gives you architectural confidence without requiring everything to be designed up front. You prove the pipeline works before you fill it with features.17
The real cost of “safe”
Waterfall feels safe. It promises control through documentation and predictability through planning. But the safety is illusory. What you actually get is a process that locks in assumptions before you’ve had a chance to validate them, discovers problems too late to fix cheaply and delivers products that may already be stale by the time they reach the market.
The 89-day pipeline McKinsey documented isn’t just slower — it means the product you ship reflects decisions made three months ago. In a market that moves in weeks, that’s not a delivery timeline. It’s a time capsule.
We’ve had the evidence for over fifty years. Royce told us in 1970. The DoD learned the hard way through the 1980s. The Standish Group has been publishing the data since the 1990s. The question isn’t whether waterfall works for software — it doesn’t. The question is why we keep pretending it does.
For more on treating software development as the research process it is, see Stop measuring effort. For practical guidance on shifting your delivery pipeline, see Moving away from the monolith — “shift left?” and The balancing power of TDD. If you’re ready to rethink your delivery approach entirely, the Delivery Playbook is a good place to start.
If you enjoyed this article, consider sharing it with a colleague who’s still stuck in a waterfall process. And if you haven’t subscribed yet, you can do so below — every new article lands directly in your inbox.
I’ve written about this in Stop measuring effort and The balancing power of TDD; software development is research, not manufacturing.
Winston W. Royce, “Managing the Development of Large Software Systems,” Proceedings of IEEE WESCON, Vol. 26, pp. 328–388, August 1970.
U.S. Department of Defense, Office of the Secretary of Defense, Report on Weapon Systems Software Management, 1975.
DOD-STD-2167, “Defense System Software Development,” U.S. Department of Defense, 1985. Superseded by MIL-STD-498 in 1994.
Barry Boehm, Software Engineering Economics, Prentice-Hall, 1981.
Capers Jones, Software Assessments, Benchmarks, and Best Practices, Addison-Wesley, 2000. Extended Boehm’s findings with data from HP, IBM, Hughes Aircraft and TRW.
See footnote 1.
Standish Group, CHAOS Report 2020. Based on analysis of 50,000+ project profiles from 2013–2020.
Standish Group, CHAOS Report 2015. Large-scale agile projects found to be 6X more likely to succeed than waterfall counterparts.
McKinsey & Company, “Beyond Agile: Reorganizing IT for Faster Software Delivery,” 2015.
The Delivery Playbook is organized as a subway map — a navigable, visual representation of the entire delivery lifecycle. See How to use a playbook for a walkthrough.
See 2.3 Strategic event storming for how collaborative requirements discovery works in practice.
See Solve delivery with a steel thread for how to prove your pipeline end-to-end without over-engineering up front.
See footnote 1.
See How to fix a $25 bug before it becomes a $37,500 problem for a deep dive on BDD’s design-first approach.
See Moving away from the monolith — “shift left?” for the mechanics of compressing feedback loops.
See footnote 13.