Methodology comparison
Agile vs Waterfall
Two schools of thought on how to build software. Knowing the vocabulary and trade-offs is essential for stand-ups, retrospectives, and any conversation with a product manager, scrum master, or client.
TL;DR
- Waterfall moves through fixed sequential phases — Requirements → Design → Implementation → Testing → Deployment. Each phase is signed off before the next begins. Changes late in the process are costly.
- Agile works in short iterative cycles called sprints. Requirements evolve; working software ships frequently; feedback is built into every cycle.
- The choice depends on how stable your requirements are and how much you value early user feedback over upfront predictability.
Side-by-side comparison
| Aspect | Waterfall | Agile |
|---|---|---|
| Flexibility | Low — changes require going back to a previous phase | High — backlog can be reprioritised each sprint |
| Feedback loops | Late — customer sees the product near the end | Continuous — demo every sprint, feedback incorporated immediately |
| Documentation | Heavy upfront — detailed specs before coding begins | Lightweight — just enough to support the current sprint |
| Risk | Discovered late — unknown unknowns surface during testing | Surfaced early — each sprint reveals risks in working software |
| Team structure | Specialist silos (analyst → dev → QA) | Cross-functional teams (dev + QA + design together) |
| Delivery | Big-bang release at the end | Incremental — potentially shippable after every sprint |
| Contract type | Fixed-price, fixed-scope | Time-and-materials or fixed-budget / variable-scope |
| Best for | Regulated industries, hardware, fixed-requirement projects | Product software, startups, evolving requirements |
When to use Waterfall
- Requirements are fixed and well-understood. Construction, defence, and hardware projects where changes mid-build are prohibitively expensive.
- Regulatory documentation is mandatory. FDA medical device submissions, government contracts, and financial systems often require phase-gate sign-offs.
- Fixed-price contracts. When a client needs a precise scope and price upfront, Waterfall's predictability is a selling point.
- Large distributed teams with hand-off boundaries. When different organisations own different phases, sequential stages reduce coordination overhead.
When to use Agile
- Requirements will evolve. Product discovery, SaaS applications, and consumer apps where user feedback drives direction.
- Early delivery of value matters. Shipping a working MVP in the first sprint lets stakeholders test real assumptions quickly.
- Small, co-located, cross-functional teams. Agile ceremonies (standups, retros) have low overhead when the team is small and communicates easily.
- Competitive markets. Faster iteration cycles mean faster response to competitors and market shifts.
English phrases engineers use
Agile conversations
- "We're running two-week sprints with a demo every Friday."
- "We iterate based on feedback from the last review."
- "That story is in the backlog — we'll pull it into the next sprint."
- "The velocity has been stable at around 40 points per sprint."
- "Let's timebox that discussion to 15 minutes."
Waterfall conversations
- "The requirements are fixed — we signed off on the spec last month."
- "The project has a hard deadline of Q4 for delivery."
- "We can't start coding until the design phase is signed off."
- "This change is out of scope — it would require a change request."
- "We're in the UAT phase now — go-live is in three weeks."
Key vocabulary
- Sprint — a fixed-length iteration (1–4 weeks) in Agile during which a shippable increment is built.
- Backlog — a prioritised list of work items (user stories, bugs, tasks) waiting to be scheduled into a sprint.
- Velocity — the average amount of work a team completes per sprint, used for planning.
- Retrospective (retro) — a ceremony at the end of each sprint where the team reflects on process improvements.
- Phase gate — a Waterfall checkpoint where a phase must be formally approved before the next begins.
- UAT (User Acceptance Testing) — the final Waterfall phase where end users verify the system meets requirements.
- Increment — a working, potentially shippable piece of the product delivered at the end of a sprint.
Quick decision tree
- Requirements are fully defined and unlikely to change → Waterfall
- Regulatory phase-gate approvals required → Waterfall
- Customer feedback should shape the product → Agile
- Time-to-market is critical → Agile
- Fixed-price contract with defined scope → Waterfall
- Cross-functional team empowered to make decisions → Agile
- Large programme with multiple vendors → Hybrid
Frequently asked questions
Is Agile always better than Waterfall?
No. Agile thrives when requirements will change, when customer feedback is available throughout, and when the team can ship increments of working software. Waterfall fits projects with fixed, well-understood requirements, strict regulatory documentation needs, or large hardware/infrastructure components where iterations are costly or impossible.
What is a hybrid approach?
A hybrid combines elements of both. A common pattern is using Waterfall for the initial discovery and architecture phase (where requirements are clarified and documented) and then switching to Agile sprints for development and delivery. Some organisations run Waterfall at the programme level (fixed milestones) and Agile at the team level.
Why does Waterfall still exist?
Many industries require it: defence, aerospace, and government contracts often mandate fixed-price, fixed-scope contracts with detailed upfront documentation. Large physical infrastructure projects (buildings, hardware) cannot iterate the way software can. Regulatory compliance in healthcare and finance sometimes demands phase-gate reviews before proceeding.
What is a sprint in Agile?
A sprint is a fixed-length iteration — typically 1 to 4 weeks — during which the team builds a potentially shippable increment of the product. Each sprint starts with planning (selecting items from the backlog), runs through daily standups, and ends with a review (demo to stakeholders) and a retrospective (team reflects on process).
What does "velocity" mean in Agile?
Velocity is the amount of work a team completes in a sprint, measured in story points or another unit. Teams track velocity over several sprints to forecast how much they can commit to in future sprints. It is a planning tool, not a performance metric — comparing velocity across teams is meaningless because point scales are team-relative.
How does risk management differ between the two?
In Waterfall, risk is front-loaded into the design and planning phases; unknown risks discovered during development are expensive to handle. In Agile, each sprint surfaces risk early through working software. If a feature turns out harder than expected, the team adapts the backlog. The cost of change is intentionally kept low throughout.