Why Waterfall Exists
Before we discuss Agile, Scrum, or Kanban, you need to understand what they were reacting against. The Waterfall model is a sequential approach to project management where work flows in one direction — like water down a series of steps — through distinct phases: Requirements → Design → Implementation → Testing → Deployment → Maintenance.
Waterfall was borrowed from manufacturing and construction, where changing the plan mid-build is catastrophically expensive (you can't move a load-bearing wall after the building is up). In software, it was the dominant methodology from the 1970s through the early 2000s. A typical Waterfall project looked like this:
- Requirements phase (months 1-3): Business analysts write a 200-page specification document.
- Design phase (months 4-5): Architects create detailed technical designs based on the spec.
- Implementation phase (months 6-12): Developers build exactly what the spec says.
- Testing phase (months 13-14): QA tests the finished product against the original spec.
- Deployment (month 15): Ship it.
The fatal flaw: by month 15, the market has changed, users want different things, and half the assumptions in the original spec are wrong. But the team built exactly what was specified — so the project is "on time and on budget" yet delivers the wrong product. This is sometimes called the BUFD (Big Up-Front Design) problem: the longer you wait to show users something real, the more expensive your wrong assumptions become.
When Waterfall Still Makes Sense
Waterfall is not universally wrong. It works well when:
- Requirements are genuinely fixed — regulatory compliance, hardware interfaces, safety-critical systems (medical devices, aviation software).
- The cost of change is truly high — embedded firmware that ships on physical devices where a field update is expensive or impossible.
- External contracts demand it — government procurement often requires fixed-scope, fixed-price contracts with formal change-control processes.
The key insight is that Waterfall assumes you can know everything upfront. Agile assumes you can't. Most software projects fall into the "can't" category, which is why Agile emerged. The question to ask is: "What is the cost of discovering a wrong assumption late?" If the answer is "catastrophic," Waterfall's front-loaded rigor is justified. If the answer is "we can adjust," Agile's iterative approach is more efficient.
Interviewers sometimes ask "What's wrong with Waterfall?" to test whether you'll give a nuanced answer or a reflexive one. The trap is trashing Waterfall entirely. The strong answer: "Waterfall optimizes for predictability when requirements are stable and the cost of late changes is high — which is appropriate for safety-critical or hardware-constrained systems. Agile optimizes for adaptability when requirements are uncertain and feedback is cheap to incorporate — which describes most software products. The mistake is applying either methodology without considering the actual constraints of the project."
Key Point: The real lesson from Waterfall's failures is not "don't plan" — it's "don't defer feedback." Any methodology that delays showing working software to real users for more than a few weeks is accumulating assumption debt. The longer you go without validation, the more expensive your corrections will be.