Plan the discovery or discover the plan?
Waterfall vs Agile isn’t a choice between old and new, or between better and worse. These are two different tools designed to answer two different questions. Waterfall asks: what exactly do we want to build, and how do we plan it from start to finish? Agile asks: what do we still need to learn in order to deliver the right value? The choice between them depends on the nature of the problem, not on trends or team habits.
The history of waterfall and agile: where did these methodologies come from?
Before reaching for a tool, it’s worth understanding where it came from and what it was designed for. This is not a linear story and that’s precisely the point.
In 1969, the Project Management Institute (PMI) was founded as the first organization to undertake the standardization of project management. A year later, in 1970, Winston Royce published a paper describing a sequential model of software development in which phases, analysis, design, implementation, testing, deployment, follow one another like water cascading downward: each begins only after the previous one is complete.
What’s important, and often glossed over: in that same paper, Royce explicitly warned that the absence of an iterative approach introduces enormous risk. Yet the sequential model became an industry standard,not because Royce recommended it, but because it fit the logic of large organizations and government contracts. For decades, the first part of his argument was cited while his own caveat was quietly ignored.
In 1996, PMI published the first edition of the PMBOK (Project Management Body of Knowledge), now in its eighth edition (2025). This handbook became a kind of bible for project managers and enshrined waterfall as the dominant way to run projects: a defined deliverable, a fixed timeline, an agreed budget.
Then, in February 2001, 17 practitioners from various methodologies (Scrum, Extreme Programming, Crystal, and others) gathered at a mountain resort in Snowbird, Utah, and over the course of two days formulated the Agile Manifesto. People sometimes ask: how do you invent something like that in two days? The answer is: they didn’t. Scrum and Extreme Programming had already emerged in the mid-1990s. Those 17 practitioners, coming from different backgrounds, came together to articulate a shared conviction, that traditional approaches to project delivery no longer matched the challenges they faced in their day-to-day work.
The Manifesto didn’t create agility. It named and unified what was already happening in practice. And here I notice a pattern: in both cases, concrete practices came first, and the attempt to collect and standardize them came later. That matters because it means waterfall isn’t an outdated predecessor to Agile. They are two parallel currents, each responding to different challenges.
What is the waterfall methodology?
Waterfall is a project management model built on the assumption that requirements are sufficiently well understood at the outset to plan all stages through to completion. Each phase analysis, design, implementation, testing, deployment has defined inputs, outputs, and acceptance criteria. Change is the exception, and it requires formal approval.
The defining characteristic of waterfall: the cost of a defect grows exponentially depending on the phase in which it’s discovered. A mistake caught during analysis costs next to nothing. The same mistake discovered after deployment can cost a hundred times more.
When does waterfall make sense?
The waterfall approach works well when at least one of the following conditions applies:
| Factor | Example |
|---|---|
| Stable requirements | Legally regulated systems (aviation, pharma, finance) |
| High cost of change | Bridge construction, hardware manufacturing, data centers |
| Documentation requirements | ERP implementation with audit obligations |
| Distributed teams | When continuous synchronization is difficult or impossible |
Aviation is a good example. Requirements are dictated by law, code is written one-to-one against legal specifications, and there are no surprises. That’s a regulated market where waterfall it’s the only reasonable answer. The same applies to pharma or hardware. You can’t be mid-production on several million units and decide to push an upgrade. What’s already been manufactured is a sunk cost.
But, and this is the crux, waterfall applied in a dynamic environment, without any of the above conditions in place, is in its purest form a theater of control. We pretend we’re in charge while change happens anyway. Where the cost of a mistake exceeds the cost of rigid planning, waterfall deserves serious consideration. Where it doesn’t, forcing a team through formal change requests for every minor adjustment is a recipe for frustration and wasted time.
What is the agile methodology?
Agile is a project management approach built on the assumption that we don’t know everything at the start and that we deliberately build in ways that allow us to learn as we go. Instead of one big plan, we have continuous planning. Instead of delivering everything at the end, we deliver value regularly and incrementally.
The Agile Manifesto of 2001 defines four fundamental values. They’re four concrete choices, each with real consequences:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Jim Highsmith, one of the 17 signatories of the Agile Manifesto, described the essence of agility this way: „Agile methodologies allow us to create change and respond to change in a way that reflects the business value we’re delivering.” The key word is value. Not speed. Not the absence of documentation.
I want to stop here, because this is the most common misunderstanding I encounter. The Manifesto doesn’t say documentation is unnecessary. It says that when a product isn’t working, fixing it takes priority and documentation moves to second place. If someone tells you „we don’t document because we’re Agile,” they either don’t understand the Manifesto, or they simply can’t be bothered. Neither is acceptable.
When does agile make sense?
- Requirements are unclear or will evolve
- The cost of change is relatively low
- The client wants to — and can — actively co-create the product
- Speed of learning matters more than speed of delivery
- The market is unpredictable (startups, new digital products)
Some people think Agile is about going fast. But speed of delivery isn’t the point – speed of learning is. In 2011, Netflix split its service into DVD and streaming, launching a separate brand called Qwikster. Customers said: no loudly. Three weeks later, the company had to reverse course and issue a public apology. Had they tested the idea first with a small group, they would have saved a fortune on damage control. That’s the real advantage: learning faster, not coding faster.
Waterfall vs agile: 5 key differences
| Dimension | Waterfall | Agile |
|---|---|---|
| Approach to planning | A contract – detailed and binding from the start | A hypothesis – verified and refined as work progresses |
| Change | Formal change request; disrupts the plan and costs money | Enters the backlog and is prioritized like any other item |
| Delivery | Full product at the end of the project | Regular, iterative, incremental, each increment adds value |
| Risk | Identified and managed upfront (historical data, risk registers) | Revealed gradually, each iteration surfaces new risks to address |
| Client’s role | Stakeholder appears at contract signing and final delivery | Co-creator – participates in reviews every iteration, feedback shapes the product |
One thing that often gets overlooked in this comparison: choosing a column isn’t a choice between better and worse. It’s a choice of what best fits the nature of your project. And not every client, frankly, wants to be a co-creator. Some will tell you: „I want this thing and I don’t want to know how you build it.” That’s a legitimate position, and it needs to factor into your approach.
The Selection Matrix: Waterfall, Agile, or Hybrid?
My favorite diagnostic tool is a two-dimensional matrix. Before choosing a methodology, assess two variables:
- X-axis: How well-defined are the requirements? (from unclear to precisely specified)
- Y-axis: How costly is change? (from cheap to very expensive)
The bottom-right quadrant cheap change, known requirements – is the natural boundary where a project transitions into a process. When work becomes repetitive and the focus shifts to eliminating waste and standardizing, we’re no longer talking about a project in the traditional sense. I explored this in more depth in my article Project vs Process – What’s the difference and which should You choose?
6 Common Traps When Choosing a Methodology
The biggest mistakes I see don’t come from bad intentions. They come from never asking the right question at the start: how certain are we about what we’re delivering, in what timeframe, and how constrained are we by regulations?
1. Choosing a methodology by habit, not by analysis
This is probably the most expensive mistake because it isn’t really a decision at all. A company has always run projects using waterfall. A new project arrives and, automatically: we do it the way we’ve always done it. A year later, it turns out requirements changed three times, and the team spent more time navigating change request procedures than actually making the changes.
2. Cargo cult – form without substance
The term comes from anthropological observations made during World War II. In the Pacific, where American forces were stationed, islanders watched planes bring in supplies for the soldiers. After the war, when the planes stopped coming, they built bamboo imitations of airstrips, runways, and control towers hoping to bring the goods back. Search „cargo cult” in Google Images. The photos speak for themselves.
Organizations that implement Agile without understanding it operate in exactly the same way: they copy the external form sprints, daily standups, backlogs without understanding why, and end up with a great deal of ritual and zero agility. Everyone is so agile. There just isn’t any actual agility to be found.
3. Agile as an excuse for not planning
I’ve touched on this already, so briefly: Agile changes the planning horizon, it doesn’t eliminate planning. This is critical. Agility often demands greater discipline than waterfall. Instead of one report at the end of the project, you have daily syncs and reviews every iteration.
4. Waterfall as an excuse to avoid talking to the client
That excuse doesn’t replace the conversation it just postpones it and inflates the bill. In the traditional model, the client shows up twice: at contract signing and at final delivery. Everything in between happens behind closed doors. Sometimes that’s an advantage, fewer changes. More often it’s a risk, because there’s a lot you won’t discover until it’s too late.
5. Mixing approaches without awareness
A hybrid can be the smartest possible choice or complete chaos. It depends entirely on whether someone designed it deliberately, or whether it simply happened because no one vetoed it. I’ve seen this many times: a project starts off agile, with sprints, a backlog, daily standups. Halfway through, the client pushes for a fixed end date and a locked scope. The backlog gets frozen, sprints become phases, nobody says anything, nobody changes the contract, nobody tells the team. The result: methodological chaos, role confusion and a Scrum Master who’s become a taskmaster instead of a coach.
6. Fixed-Price agile – agility inside a rigid contract
Back when I was freelancing, whenever a difficult conversation came up with a client, I’d draw a triangle. In each corner I’d write: fast, cheap, good and say: pick two. It’s not a sales technique I was never a salesperson, and it probably showed. But it captures the essence of the problem.
Agile and fixed-price contracts aren’t mutually exclusive, but they require a deliberate rethinking of how the contract is structured. You can’t simultaneously have a fixed price, a fixed timeline, and a variable scope, unless the client understands they’re trading control over the details in exchange for delivered value.
Approaches that work:
| Model | How It Works |
|---|---|
| Fixed budget, variable scope | Client sets the budget; scope is prioritized iteratively |
| Discovery phase outside the main contract | Requirements are explored before signing the primary agreement |
| Time & Material with a cap | Flexibility with a ceiling on total cost |
Summary
A good doctor doesn’t prescribe medication before running tests. Before you choose a methodology, understand the problem you’re solving, because waterfall and agile are answers to different questions.
Three things I want you to take away:
Diagnose before you decide. The requirements/cost-of-change matrix is the minimum starting point.
Both sides are right, in the right context. Waterfall isn’t a relic, and Agile isn’t a cure-all.
The biggest risk is lack of awareness. Cargo cult adoption, habit-driven methodology selection, unnamed hybrids, these don’t come from bad intentions. They come from never stopping to ask: why are we doing it this way?
This article is based on an internal training series on project management delivered at fireup.pro. It’s the second part of the series. In the first, I covered the difference between a project and a process. In the next, we’ll look at specific frameworks: Scrum, Kanban and approaches to scaling.
