Agile vs Waterfall
Both approaches plan, build and review. The difference is how often, and therefore how late a bad assumption is allowed to survive. Everything else in the argument is downstream of that one variable.
In short
- Waterfall runs the lifecycle once at project scale. Agile runs it repeatedly at feature scale.
- The real trade is a firm long-range date versus early discovery. You can have one; you pay for the other.
- Choose by how much you already know, how expensive change is, and whether you can ship in pieces.
- Most real projects are hybrid, and that is a legitimate answer rather than a failure of conviction.
What each one actually is
Stripped of the tribal loyalty, the two are quite plain.
Waterfall means deciding what to build, planning it, building it, and delivering it — in sequence, each phase largely finished before the next begins. It is the right shape when you can know most of the answer in advance, and it is how bridges, aircraft and regulatory filings get made.
Agile means building a small usable slice, showing it to someone who can react, and letting what you learn change what you build next — then repeating. It is the right shape when the requirements are genuinely uncertain, or when the people who will use the thing can’t tell you what they want until they see something.
Neither is a moral position. They’re answers to a question about how much you already know.
The variable that matters
Put it next to the cost-of-change curve and the arithmetic becomes visible. If a wrong assumption costs ten times more to fix at each stage it survives, then eight review points instead of two is not a philosophical preference. It is a large amount of money.
The catch is that early discovery has a price. Every iteration boundary costs coordination, re-planning and re-testing. On work where the requirements genuinely aren’t going to change, you pay that overhead eight times and learn nothing new for it.
What each buys, and what it costs
Waterfall buys
A committed long-range date and budget. A single design that can be reviewed as a whole. Contracts and approvals that fit how procurement and regulators actually work.
And costs
Discoveries arrive when they are most expensive. Anything the requirements got wrong is built faithfully anyway.
Agile buys
Something usable early. Frequent correction while correction is cheap. Real feedback from people who couldn’t have described what they wanted in advance.
And costs
A vaguer answer to “what will exist in twelve months?”, and a continuous demand on the availability of whoever gives the feedback.
That last cost is the most commonly ignored one. Agile transfers work from the plan to the conversation, and the conversation needs a person with authority available every couple of weeks. A project run iteratively with an absent decision-maker gets the overhead of Agile and the discovery rate of Waterfall.
How to choose
Seven questions. Count which column you land in more often.
| Question | Points to Waterfall | Points to Agile |
|---|---|---|
| How well do you know the requirements? | Well, and they’re stable | Partly, and they’ll shift |
| How expensive is changing your mind later? | Very — concrete, hardware, contracts | Moderate — software, content, process |
| Can you deliver in usable slices? | No — it works or it doesn’t | Yes — partial value is real value |
| Is a customer or user available regularly? | No, or only at milestones | Yes, every week or two |
| What does the contract or regulator require? | Fixed scope, price and date | Outcome-based or internal |
| How long is it? | Short enough that little changes | Long enough that everything will |
| How much does a firm date matter? | A hard external deadline | Sooner is better; exact date is flexible |
Two rows deserve emphasis. “Can you deliver in usable slices?” is the question that most often settles it — if half a bridge is worth nothing, iteration buys you very little. And “is a user available?” is the one people answer optimistically and regret, because the whole mechanism depends on it.
Hybrid is the normal answer
Most real projects do not sit at either pole, and treating that as indecision is a mistake. Common and sensible combinations:
- Fixed frame, iterative inside. The date, budget and broad scope are committed; how the team gets there is decided iteration by iteration. This is what most well-run corporate projects actually do.
- Waterfall for the parts that can’t iterate. Hardware, data migration and regulatory sign-off run in sequence; the software around them runs in cycles.
- Discovery, then delivery. A short iterative phase to resolve the genuine unknowns, followed by a planned build now that you know what you’re building.
The one rule worth holding: be explicit about which parts are which. A project where half the team believes the scope is fixed and the other half believes it is emerging has chosen the worst properties of both.
The two failure modes
Agile in name only
Two-week iterations, a scope that is fixed anyway, and no user in the review. You’ve added ceremony to a Waterfall project and called the result “sprints”. The giveaway: nothing the team learns ever changes what gets built next.
Waterfall pretending to be certain
A detailed twelve-month plan for work nobody has done before, then months of change requests against it. The plan wasn’t wrong because planning is wrong — it was too detailed for how little was known.
Both failures come from the same place: choosing an approach for reasons of identity rather than from the seven questions above.
How this looks in AB
AB Projects doesn’t impose either approach, and the practical difference shows up in which view a team lives in:
- Waterfall-shaped work lives in the Gantt timeline: dependencies, a critical path, and dates you are committing to. The question it answers is “will we make it?”
- Agile-shaped work lives in the backlog and the board: an ordered list of what’s next, and a board showing what’s moving. The questions are “what next, and why?” and “where is it stuck?”
- Hybrid work uses both, which is exactly why the same tasks appear in all three views — see 5.0 Project Tools. The fixed frame is visible on the timeline; the iterating part is ordered in the backlog.
One habit that helps a hybrid project stay honest: write in the project Wiki which parts of the scope are fixed and which are expected to change. It takes three lines and it prevents the argument where two people are both correctly following different assumptions.
Terms used on this page
- Waterfall
- A sequential approach where each phase is largely completed before the next begins. Suits work where most of the answer is knowable up front. More →
- Agile
- An iterative approach that builds small usable slices, reviews them with someone who can react, and lets the result change what comes next. More →
- Iteration
- A short fixed-length cycle in which a team plans, builds and reviews a slice of work. Called a sprint in Scrum. More →
- Increment
- The usable output of an iteration — something that works, not a partially finished layer of something that doesn’t. More →
- Cost of change
- The observation that fixing a defect or misunderstanding gets dramatically more expensive the later it is found. The economic case for frequent review. More →
- Hybrid approach
- Running some parts of a project sequentially and others iteratively, deliberately. The usual real-world answer, and only a problem when it is unstated. More →
- Scope
- The agreed boundary of what the project will and will not produce. Fixed in Waterfall, deliberately negotiable in Agile — the difference matters more than the label. More →
Related reading
5.3 Managing a Product Backlog
The ordering mechanism that makes iterative delivery work, and how to refine it.
5.1 Using a Gantt Chart
The timeline view that sequential work depends on, dependencies and all.
2.0 The Project Lifecycle
The four phases both approaches run — once, or eight times.