Someone has just asked you, “Are we doing waterfall or agile?” and you would like to answer without bluffing. Good news: this is a simpler decision than the internet makes it look.
The short answer
Neither method is better. The right one depends on how much you know up front and how much is likely to change.
- Choose waterfall when you know exactly what you need, changes later would be expensive, and the work follows a natural order (building, moving offices, a regulated submission).
- Choose agile when the requirements are unclear or will change, you can deliver in small pieces, and someone can give you feedback along the way (software, marketing, new products).
- Choose hybrid when both are true: a fixed deadline or contract on the outside, with room to learn on the inside.
Waterfall in plain English
Waterfall works in stages, one after another: requirements, design, build, test, release. You plan the whole project up front, agree the scope, then work through the plan. Each stage finishes before the next starts, a bit like a waterfall running downhill.
Where it shines: everyone knows what “done” looks like, the budget and dates are fixed, and the order of the work matters. You cannot pour a roof before you build the walls.
Where it hurts: you only see the finished result at the end. If the customer’s needs shifted, or you misread the requirements, you find out when it is most expensive to fix.
Agile in plain English
Agile works in short cycles, often called sprints, usually one to four weeks long. In each cycle the team picks the most valuable items from a prioritised list (the backlog), builds them, shows the result and gets feedback. Then the next cycle adjusts to what was learned.
Where it shines: the problem is not fully understood yet, the customer will react better to something real than to a document, and priorities may change. You get working pieces early and can steer.
Where it hurts: it needs people who can talk to the customer often, a team that can decide quickly, and discipline. Without them, “agile” turns into “we have no plan”. It is also harder to promise a fixed price for a fixed scope.
You will also hear about Scrum and Kanban. They are two popular ways of doing agile, not separate rivals to it. Unfamiliar terms? Our plain-English PM glossary has them.
Waterfall vs agile, side by side
| Waterfall | Agile | |
|---|---|---|
| Planning | Detailed plan up front | Light plan up front, re-planned every cycle |
| Scope | Fixed early, changes go through formal change control | Expected to evolve, reprioritised every cycle |
| Delivery | One main delivery at the end (or at big phase gates) | Small usable pieces delivered every 1 to 4 weeks |
| Customer involvement | Heavy at the start and at sign-off | Regular, throughout the project |
| Change | Costly once you are past the design phase | Welcome, and cheap if you keep cycles short |
| Documentation | Detailed and formal | Just enough, kept close to the work |
| Best for | Clear requirements, fixed contracts, regulated or physical work | Unclear or changing requirements, software, creative work |
| Biggest risk | You discover too late that you built the wrong thing | Scope drifts and nobody can say when it will be finished |
Five questions to decide
Answer these honestly for your project. Do not worry about what your company calls its method.
- Do we know what we need? Clear, stable requirements point to waterfall. Fuzzy or changing ones point to agile.
- What does a change cost? If late changes mean ripping out concrete or recertifying a product, plan carefully up front. If a change is a few days of work, stay flexible.
- Can we deliver in small, useful pieces? If yes, agile works. If nothing is useful until everything is done, lean towards waterfall.
- Can the customer give us frequent feedback? If nobody is available to react every couple of weeks, agile loses most of its value.
- Does a contract or regulation fix the plan? Fixed scope, price and dates usually mean waterfall at the top level, even if the team works in sprints below it.
Mostly “yes” to questions 1 and 2? Waterfall. Mostly “yes” to 3 and 4? Agile. A mix, or a hard “yes” to question 5? Hybrid is probably your answer.
Quick examples
- Waterfall: an office move, a building fit-out, a compliance audit, an equipment installation.
- Agile: a new mobile app, a website redesign, an internal tool, a marketing campaign you will tune as results come in.
- Hybrid: a product launch with a fixed date and budget, where the team builds in sprints; a contract with fixed milestones and an agile team doing the work between them.
Hybrid: the pragmatic middle
In real organisations, pure versions are rare. Hybrid usually means you plan the big picture like waterfall (the goal, budget, major milestones, approvals) and deliver the details in short agile cycles. It is not a cop-out. It is how many teams get fixed commitments and flexibility at the same time. We will go deeper in a separate article on hybrid project management.
Four mistakes to avoid
- Choosing by buzzword. “We are agile now” is not a reason. Start from your project’s facts.
- Using agile as an excuse for no plan. Agile still needs a goal, priorities and a way of knowing what is done.
- Running waterfall with no checkpoints. Even a fully planned project needs regular reviews, so surprises show up early.
- Forcing a method nobody knows. A simple approach your team can actually run beats a perfect one nobody understands.
In practice, many real projects blend the two: agree the big milestones and approvals up front, then work in short cycles inside each stage. If you are unsure, start with the approach that matches how much you know today, and revisit it at each milestone.
What to do on Monday
Whichever method you choose, the first step is the same: write down the goal, the scope, who is involved and what success looks like on a single page. The free Accidental PM Starter Kit includes a ready-to-use project charter, a tracker and a first-30-days checklist.
Leave a Reply