If you are commissioning software, someone will soon ask whether you want the project run "agile" or "waterfall". The question sounds technical, but it is really about how you want to make decisions, how much you know at the start and how you prefer to manage risk. This guide to agile vs waterfall explains both approaches without the jargon, so you can choose deliberately rather than by fashion.
Waterfall: plan, then build
The waterfall model runs a project as a sequence of phases, each finished before the next begins:
- Requirements: everything the system must do is gathered and signed off.
- Design: architecture, data structures and screens are specified.
- Build: developers write the code.
- Test: the complete system is tested against the requirements.
- Deploy: the system goes live.
- Maintain: defects are fixed and small changes made.
The name comes from the way work flows down from one phase to the next. Going back upstream, such as changing requirements during the build, is possible but expensive.
Agile: build, learn, adjust
Agile is a family of approaches rather than a single method. They share the values in the Manifesto for Agile Software Development, published in 2001. In practice, agile teams work in short cycles, often called sprints or iterations, typically one to four weeks long. Each cycle delivers a small piece of working software that stakeholders can see and react to.
Work is kept in a prioritised list called a backlog. At the start of each cycle the team takes the most valuable items from the top; at the end they demonstrate what was built. Feedback reshapes the backlog for the next cycle. Scrum and Kanban are the most widely used agile frameworks: Scrum uses fixed-length sprints with defined roles, while Kanban manages a continuous flow of work with limits on how much is in progress at once.
Agile vs waterfall side by side
| Aspect | Waterfall | Agile |
|---|---|---|
| Requirements | Defined fully up front | Refined continuously |
| First working software | Near the end | Within weeks |
| Handling change | Formal change control | Expected; reprioritised each cycle |
| Client involvement | Heavy at start and end | Steady throughout |
| Budget and date predictability | Clear for fixed scope | Clear for time and cost; scope flexes |
| Documentation | Extensive, produced early | Lighter, produced as needed |
| Main risk | Building the wrong thing well | Drifting without clear goals |
Where waterfall still fits
Waterfall has an unfashionable reputation, but it is a reasonable choice when:
- Requirements are stable and well understood, such as replacing a legacy system with known behaviour.
- Regulation demands extensive upfront documentation and formal sign-off at each stage.
- The work depends on fixed external milestones, such as hardware delivery or a legally mandated date.
- Stakeholders cannot be available regularly during the build.
Where agile fits
Agile tends to work better when:
- You are building something new and are not yet sure what users want.
- The market or business process is changing.
- Getting something useful into users' hands early has real value.
- You can provide a product owner: someone empowered to set priorities and answer the team's questions quickly.
Common misunderstandings
"Agile means no planning"
Agile teams plan constantly, just in smaller increments. A good agile project still has a product vision, a rough roadmap, a budget and a target release date. What it avoids is detailed planning of work that is months away and likely to change.
"Agile means no documentation"
Agile values working software over comprehensive documentation, but that is a preference, not a ban. Systems still need architecture notes, API documentation and user guides.
"Waterfall guarantees the budget"
Only if the requirements were right. When they turn out to be wrong, as they often do for new products, change requests erode the certainty that waterfall promised.
"We do agile" because there are daily meetings
Ceremonies are not the point. If working software is not shown to stakeholders regularly and priorities never change based on what they see, the project is not really agile.
Hybrid approaches
Many organisations combine elements. A common pattern is an upfront discovery phase that defines scope, architecture and a budget (waterfall-like), followed by iterative delivery within that frame (agile). Another is to run software development in sprints while hardware, procurement or regulatory steps follow a fixed plan. Hybrid is not a compromise to be embarrassed about; it is often the honest reflection of a project's constraints.
Questions to help you decide
- How confident are we that our requirements are complete and correct?
- What happens if we learn something important halfway through?
- Can someone on our side commit a few hours each week to reviewing work and setting priorities?
- Do regulators or funders require formal phase sign-offs?
- Is early partial delivery valuable, or is the system useless until complete?
Your answers also affect how you contract the work. A fixed scope pairs naturally with waterfall; an evolving backlog pairs with time-based contracts. If you are unsure how to structure delivery, project planning is part of software consulting, and most web application development teams will adapt to whichever approach suits your situation.
Key takeaways
- Waterfall completes each phase before the next; agile delivers in short, repeated cycles.
- Choose waterfall for stable, well-understood or heavily regulated work.
- Choose agile for new products and changing requirements, if you can supply an engaged product owner.
- Hybrids are common and often the most realistic option.