Agile vs waterfall comes down to when decisions are made. A waterfall project decides everything at the start and delivers the system at the end. An agile project decides the outline at the start, delivers working software in small pieces and settles the detail as it goes. Which will work best for you depends on how well you already know what you need, how fixed your budget and date are, and how much of your own time you can give the project. For most business systems the answer is a combination: agree the scope and the acceptance checks first, then build in short cycles you can inspect.
How a waterfall project runs
Waterfall is a sequence of stages, each finished and approved before the next begins: requirements, design, build, test, release. The name comes from the way work flows down from one stage to the next and does not flow back up.
Its strengths are the ones a finance director likes. There is a written specification, a plan with dates and a price that can be set against it. Everybody knows what stage the project is in. The documents produced along the way remain useful after the project ends.
Its weakness is timing. The people who will use the system see it working only near the end, which is when misunderstandings in the requirements come to light and when they cost the most to fix. A requirement that was written down wrongly in month one is built faithfully and discovered in month six. Changing your mind after a stage has been approved means reopening earlier work, so change is discouraged and expensive.
How an agile project runs
Agile is a family of methods that share the values of the Manifesto for Agile Software Development, published in 2001. The manifesto prefers working software to comprehensive documentation and responding to change to following a plan, while saying plainly that the second item in each pair still has value.
In practice the work is done in short cycles. In Scrum, the best-known agile framework, a cycle is called a Sprint and lasts a month or less; two weeks is common. Each cycle ends with working software that you can try. Between cycles the list of remaining work is reordered, so a new idea or a discovered problem can be dealt with next instead of waiting for the end.
The strength is early feedback. You find out in week four, not month six, that the booking screen does not match how your staff take bookings. Risky parts of the project can be tackled first, while there is still time and money to respond.
The weaknesses are less often mentioned. Agile needs a steady supply of your time: somebody with authority to decide has to review each cycle and answer questions quickly. Without an agreed scope, the end date and the total cost can drift, because there is always one more useful thing to add. And “we are agile” is sometimes offered as a reason for having no plan and no documentation, which is not what the manifesto says.
Agile vs waterfall side by side
| Waterfall | Agile | |
|---|---|---|
| Requirements | Agreed in full before design starts | Outline first, detail agreed cycle by cycle |
| First working software | Near the end | After the first cycle or two |
| Changing your mind | Costly once a stage is approved | Expected between cycles, though it still affects the total |
| Your time | Heavy at the start and at acceptance | Steady throughout |
| Cost and date | Predictable if the requirements hold | Depends on how firmly scope is controlled |
| Documentation | Produced at every stage | Has to be asked for |
| Typical failure | The wrong system, delivered as specified | A system that is never quite finished |
Which will work best for you
Four questions settle most cases.
How well do you know what you need? If you are replacing an existing system with one that does the same job, or connecting two systems with defined inputs and outputs, most of the requirements can be written down in advance and a plan-first approach is efficient. If the process itself is still being worked out, or the software is a new product whose users have not yet been asked, you will learn by seeing it, and short cycles are the cheaper way to learn.
How fixed are the budget and the date? A board that has approved one figure needs a defined scope to set it against. An open-ended agile engagement billed by the month is the wrong vehicle for that, however well it is run.
How much time can your people give? A waterfall project asks for a lot of attention during requirements and again at acceptance testing. An agile project asks for a few hours every week from someone who can make decisions. If nobody can commit to that, the cycles will stall waiting for answers.
What does a mistake in live use cost? Where an error has legal, financial or safety consequences, more has to be specified, reviewed and tested before release, whichever label the project carries.
One further case sits outside the comparison. Ongoing support and small improvements to a system already in use are not a project at all, and suit a flow-based approach such as Kanban.
Why the sensible answer is usually a mix
The two approaches are not rivals so much as answers to different risks. Waterfall guards against uncontrolled cost. Agile guards against building the wrong thing. A business buying software faces both risks, so it makes sense to borrow from each.
That is how a well-run fixed-price project works. Before the price is set, the supplier and the client agree the scope, look into anything uncertain and write down the checks that will show each part is finished. That is the waterfall discipline, applied briefly. The build then proceeds in short cycles with a demonstration at the end of each, so that misunderstandings surface early, and any new request is assessed and quoted before it is added. We explain the reasoning in when fixed-price software development works, and the role of the finishing checks in the importance of acceptance criteria.
Other methods you may be offered, including Scrum, Kanban and DevOps practices, are compared in the top software development methodologies.
What to ask a supplier before you start
The label a supplier uses tells you little. These questions tell you how the project will run:
- What do we approve before the build begins?
- When will we first see working software, and how often after that?
- How is a change requested, assessed and priced?
- Who do you need from our side, and for how many hours a week?
- How will we know each part is finished?
- What documentation will we hold at the end?
Our list of questions to ask a software supplier adds the commercial ones. If the answers are specific, the approach will probably suit you whatever it is called. If the answer to the first question is “nothing” or the answer to the second is “at the end”, ask again before you sign.