In the previous part of this series, I wrote about how projects and processes are two different languages and that mixing them without awareness is the source of most organizational misunderstandings. At the end of the article, which you can read here: https://fireup.pro/blog/project-or-process, I introduced a matrix: variability of requirements versus repeatability of actions. Its two right-hand quadrants – traditional project and innovative (agile) project – are exactly the area we will focus on today.
Waterfall vs Agile is not a choice between old and new, or between better and worse. These are two tools that 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.
Table of Contents
The history of waterfall and agile – where did these methodologies come from?
Before reaching for a tool, it’s worth knowing 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 PMI (Project Management Institute) was founded – the first organization to take on the standardization of project management. A year later, in 1970, Winston Royce published an article describing a sequential model of software development, in which successive phases (analysis, design, implementation, testing, deployment) follow one another like water cascading downhill – each beginning only after the previous one is complete.
What’s important – and often glossed over – is that in that very same paper, Royce explicitly warned that the lack of an iterative approach generates enormous risk. This 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 the author’s own caveat was ignored.
In 1996, PMI published the first edition of the PMBOK (Project Management Body of Knowledge). This handbook became a kind of bible for project managers and sanctioned waterfall as the dominant way of running projects: a specific deliverable, a specific timeline, a fixed budget.
Then, in February 2001, practitioners from various methodologies – Scrum, Extreme Programming, Crystal, and others – gathered at a mountain resort called Snowbird in Utah and, over two days, drafted the Agile Manifesto. Some ask: how can you come up with something like that in two days? The answer is: they didn’t. Scrum and Extreme Programming had already emerged in the mid-1990s. Seventeen practitioners, coming from different backgrounds, came together to collectively articulate a conviction that the traditional approach to project delivery wasn’t meeting the challenges they faced in their day-to-day work. The Manifesto didn’t create agility – it named and unified something that was already happening in practice.
And here I see a pattern: in both cases, concrete practices came first, and only then came the attempt to gather and standardize them. PMI didn’t invent project management – it described what was already working in industry. The signatories of the Manifesto didn’t invent agility – they named what was already working in their teams. Standardization always follows practice; it never precedes it.
This matters for one reason: if both methodologies grew out of real needs rather than theory, then neither of them is an evolutionary dead end. Waterfall is not an outdated predecessor to Agile, waiting to be replaced. They are two parallel currents, answering different questions – and both thrive where they’ve been placed in the right context.
What is the waterfall methodology?
Waterfall is a project management model based on the assumption that requirements are sufficiently well understood at the outset to plan every phase through to completion. Each phase – analysis, design, implementation, testing, deployment – has its inputs, outputs, and acceptance criteria. In waterfall, change is an exception requiring formal approval – and not without reason.
IBM research from the 1980s showed that the cost of fixing a defect grows exponentially with the phase in which it’s discovered: a bug caught during the analysis phase costs a symbolic dollar, while the same bug found after deployment can cost a hundred times more. These are estimates, not laws of physics, but the proportions remain relevant and explain why waterfall places such heavy emphasis on completeness of requirements at the outset. If you assume that change is expensive, the natural response is to minimize its likelihood through thorough upfront planning.
The waterfall approach works well when at least one of the following conditions is met:
- Stable requirements – systems regulated by law (aviation, pharmaceuticals, finance)
- High cost of change – bridge construction, hardware manufacturing, data centers
- Documentation requirements – implementations with audit obligations, e.g., ERP in a financial institution
- Distributed teams – when continuous synchronization is difficult or impossible
The aviation industry is a good example. Requirements defined by law, constraints imposed by physics, code written one-to-one in line with specifications, no surprises. Here, waterfall doesn’t just make sense – it’s the only reasonable answer. The same applies to pharmaceuticals or hardware. You can’t decide mid-production run of several million units that you’re doing an upgrade. What’s been manufactured is manufactured, and it represents a sunk cost.
On the other hand, waterfall in a dynamic environment – without any of the above conditions – is, in its pure form, theater of control. We pretend we’re in charge while changes happen anyway. Where the cost of error justifies rigid planning, the cascade makes sense. 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 based on the assumption that we don’t know everything at the start, and that we deliberately build in a way that allows 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 2001 Agile Manifesto defines four fundamental values. These are not marketing slogans – they are 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 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 deliver.” The key word: value. Not speed. Not the absence of documentation.
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 takes a back seat. If someone says „we don’t document because we’re Agile,” they’re either joking, misunderstanding the Manifesto, or simply can’t be bothered.
Agile makes sense when:
- Requirements are unclear or will evolve
- The cost of change is relatively low
- The client wants and is able to actively co-create the product
- Speed of learning matters more than speed of delivering a finished product
- The market is unpredictable (startups, new digital products)
Some people think Agile is about going fast. But it’s not about the speed of delivering software – it’s about the speed of learning. In 2011, Netflix split its service into DVD and streaming, creating a separate brand called Qwikster. Customers said a firm no. Within three weeks, the company had to reverse course. One can only imagine that had they tested the idea earlier with a small group of users, they would have saved significantly on subsequent reputation repair campaigns. That’s the real advantage: speed of learning, not speed of coding.
Waterfall vs agile – 5 key differences
| Dimension | Waterfall | Agile |
|---|---|---|
| Approach to planning | Contract – detailed and binding from the start | Hypothesis – verified and refined throughout the work |
| Change | Formal change request; disrupts the plan and costs money | Goes into the backlog and is prioritized like any other task |
| Delivery | Full product at the end of the project | Regularly, iteratively, and incrementally – each increment adds value |
| Risk | Identified and managed upfront (historical data, risk registers) | Revealed gradually – each iteration uncovers new risks to address |
| Client’s role | Recipient – appears at contract signing and at handoff | Co-creator – participates in reviews every iteration; their feedback shapes the product |
One thing often overlooked in this comparison: choosing a column is not a choice between better and worse. It’s a choice of what best fits the nature of your endeavor. And frankly, not every client wants to be a co-creator. Some will say: „I want this delivered, and I don’t even want to know how you do it.” That’s something you have to account for too.
Common traps when choosing a methodology
The biggest mistakes I see don’t stem from bad intentions. They come from failing to ask the right question at the outset: how certain are we about what we want to deliver, in what timeframe, and how constrained are we by regulations?
Choosing a methodology out of habit, not analysis This is probably the most costly choice – not financially, but in time and energy, because it isn’t really a choice at all. A company has been running waterfall projects for years, a new project comes in, and automatically: we do it like we always have. A year later, it turns out requirements changed three times, and the team spent more time on change request procedures than on the actual changes.
Cargo cult – form without substance This term comes from anthropological observations during World War II. In the Pacific, where American forces were stationed, island inhabitants saw planes bringing supplies for soldiers. After the war, when the planes stopped coming, they began building bamboo imitations of airstrips, runways, and control towers – hoping to attract those goods back. Search „cargo cult” in an image search; the photos speak for themselves.
Organizations implementing Agile without understanding it do exactly the same: they copy the external form (sprints, daily standups, backlogs) without understanding why, and end up with a lot of ritual and zero agility. Everyone is so agile – except the agility isn’t actually there.
Agile as an excuse not to plan Agile changes the planning horizon; it doesn’t eliminate planning. Agility often requires more discipline than waterfall – instead of one report at the end of the project, you have daily syncs and reviews every iteration.
Waterfall as an excuse to avoid talking to the client This excuse doesn’t replace the conversation; it merely delays it and inflates the bill. In the traditional model, the client appears twice: at contract signing and at handoff. Everything in between is work behind closed doors. Sometimes that’s an advantage – no changes. More often, it’s a risk – because there’s a lot you might not discover until it’s too late.
Is a sprint a mini-waterfall? This question comes up regularly, and I understand where it comes from. A sprint has a goal, an expected outcome, a defined start and end – superficially, it seems to tick several boxes of a project. But there are at least as many differences. In waterfall, quality is a separate phase; in a sprint, it’s built into the process – analysis, implementation, and verification happen in parallel, not sequentially. Moreover, the next sprint is typically a continuation of the same product, not a new endeavor – it lacks the uniqueness that a project should have. I’m inclined to say: no, a sprint is not a mini-waterfall. But it is a different kind of mental trap – a conflation of concepts that leads to false conclusions about what agility actually is.
Mixing approaches without awareness A hybrid can be the smartest choice or the greatest source of chaos – depending on whether someone designed it deliberately, or everyone just defaulted to it through lack of objection. I’ve seen this many times: a project starts agile – we have sprints, a backlog, dailies. Halfway through, the client starts pushing for a fixed end date and a fixed scope. The backlog gets frozen, sprints become phases, nobody names this, nobody changes the contract, nobody informs the team. The result: methodological chaos, role confusion – the Scrum Master becomes a taskmaster instead of a supportive educator.
Fixed Price Agile – agility within a rigid contract Back when I was a freelancer, whenever I was dealing with a difficult client, I used to draw a triangle. In the corners I’d write: fast, cheap, good and say: pick two. I was probably visibly not a natural salesperson in those moments, but the triangle did its job.
Agile and Fixed Price aren’t mutually exclusive, but they require a deliberate renegotiation of the contract structure.
In waterfall, the logic is straightforward: we fix the scope, and time and budget follow from it. In Agile, it’s the reverse: time and budget are fixed (iterations have a set rhythm and cost), while scope adjusts according to needs and priorities. If the client doesn’t understand this, they’ll feel like they’re losing control. If they do understand it, they gain something more valuable: confidence that their budget is going toward what actually delivers value.
Proven approaches:
- Fixed budget, variable scope – the client sets the budget; scope is prioritized iteratively
- Discovery phase outside the main contract – uncovering requirements before signing the primary contract
- Time & Material with a cap – flexibility with a ceiling on total cost
Decision Matrix: Waterfall, Agile or Hybrid?
My favorite diagnostic tool is a two-dimensional matrix. It won’t give you a ready-made answer – no tool will – but it will help you ask the right question. And it’s from the right question that a conscious choice of methodology begins. Before you decide, assess two variables:
First variable: how well-defined are the requirements – from unclear to precisely specified. Second variable: how costly is change – from cheap to very expensive.
| Low requirement variability | High requirement variability | |
|---|---|---|
| High cost of change | Waterfall | Hybrid with strong change control |
| Low cost of change | Agile or Waterfall – free choice | Agile |
Known requirements, high cost of change – waterfall. This is the space for precise planning and control. We know what we want to build, and each change along the way is costly enough that it pays to invest more time in upfront analysis.
Unclear requirements, low cost of change – Agile. This is the world of iteration and learning. We don’t yet know exactly what we want to build, but we can discover it step by step without incurring high costs for every correction.
Known requirements, low cost of change – free choice. Both methodologies will work. The decision depends on team preferences, organizational culture, and the nature of the client – not on the nature of the problem.
Unclear requirements, high cost of change – hybrid with strong change control. The hardest combination. We don’t yet know everything, but every mistake is painful. This requires deliberate management: iterative discovery of requirements alongside rigorous decision-making about changes.
The quadrant with known requirements and a low cost of change is also where a project can naturally begin transitioning into a process – but only when a third element appears: repeatability. If we’re doing the same thing repeatedly and care about an identical outcome every time, we’re already talking about something different from a project. I wrote about this in more detail in Project or Process – What’s the difference and which should You choose?
Choosing a methodology is, at its core, a diagnostic problem. Before reaching for a tool, we need to know what we’re dealing with – because it’s the nature of the problem that should dictate the choice, not habit or trend. A good doctor doesn’t prescribe medication before running tests.
Three things worth remembering:
- Diagnose before you choose. The requirements / cost-of-change matrix is the minimum starting point.
- Both sides are right – in the right context. Waterfall is not a relic, and Agile is not a cure-all.
- The greatest risk is lack of awareness. Cargo cult thinking, habit-driven methodology selection, unnamed hybrids – these don’t come from bad intentions. They come from failing to stop and ask: why exactly are we doing it this way?
This article is based on an internal training series on project management delivered at fireup.pro – in places it retains the rhythm of spoken language, and that’s intentional. This is the second part of the series – the first covered the difference between a project and a process; the next will look at specific frameworks: Scrum, Kanban, and approaches to scaling.
