Key takeaways
- Waterfall plans everything first and builds in one pass; agile builds in short sprints and replans after each one.
- Pick waterfall when the scope is fixed and the requirements are clear; pick agile when they will change as you learn.
- Many projects mix the two: plan the scope and architecture upfront, then build in sprints.
- Waterfall’s main risk is defects found late; agile’s is scope creep. Both can be managed.
- Match the contract to the method: a fixed price for a fixed scope, time and materials or a monthly team for agile.
“Agile or waterfall?” usually comes up just before you commission software, when someone asks how the project will be run. Neither method is better in general. Each one handles uncertainty in its own way, and the right choice depends on how much of your project you can know before it starts. This guide explains how each method works, sets them side by side, covers the hybrids that many projects use, gives you a checklist for your own project, and shows how the method you pick shapes the contract you sign.
What is the difference between agile and waterfall?
Waterfall builds the whole product in one pass through fixed phases, each finished before the next begins; agile builds it in short cycles, each ending in working software that people review before the next cycle is planned. Waterfall settles the scope at the start. Agile expects the scope to change as you learn.
How waterfall works
A waterfall project moves through its phases in order: requirements, design, development, testing and deployment. Extensive planning happens at the outset, with documents that set out the scope, the features and the deadlines. Each phase is signed off before the next begins, which makes progress easy to report and the plan easy to follow.
The cost of that structure shows when something changes. Once a phase is complete, going back to it is slow and expensive. And because testing comes near the end, a serious defect found then can take a lot of time and money to fix.
How agile works
An agile project is broken into short, time-boxed cycles, usually called sprints, typically one to four weeks long. In Scrum, one common agile framework, the 2020 Scrum Guide describes sprints as “fixed length events of one month or less”. Each sprint delivers a working set of features, which stakeholders review before the next sprint is planned. A new requirement goes into the plan for a later sprint, rather than forcing a phase to be reopened.
The idea comes from the Manifesto for Agile Software Development (2001), which values “working software over comprehensive documentation” and “responding to change over following a plan”, while adding that “there is value in the items on the right”. So agile doesn’t drop planning or documents. It plans in smaller pieces and writes down what the team needs.
You will also hear of Kanban (a board that limits how much work is in progress), Lean Startup (Eric Ries’s approach of building a minimum viable product and learning from users) and DevOps (development and operations sharing responsibility for releases). They are ways of working that sit alongside agile, not a third way to plan a project.
What are the strengths and drawbacks of each?
Waterfall’s strength is predictability and its weakness is change; agile’s strength is change and its weakness is predictability. The table sets the two side by side, with a hybrid that plans first and then builds in sprints.
Two risks in the table deserve a closer look, because they are the ones that cost buyers most.
- Late defects in waterfall. When testing waits for the end, problems in the design surface after most of the budget is spent. Ask for a build you can test at each milestone, even in a waterfall plan, so you see working software before the final phase.
- Scope creep in agile. Flexibility can turn into a backlog that never stops growing. Keep the backlog ranked, with one person on your side who decides its order, set a goal for each sprint, and write down every change, so you can see how far the plan has moved.
Agile also leans heavily on communication. If nobody on your side can review the work and answer questions each sprint, the team ends up guessing, and the main benefit of the method is lost. Waterfall asks for your time in a different shape: a lot at the start and at each sign-off, and little in between.
What are the hybrid options?
The common hybrids are agile with an inception phase, phased agile, and a waterfall plan with agile sprints inside it. Each one puts the parts of the project you can plan into a fixed plan, and the parts you can’t into sprints.
Agile with an inception phase is often the easiest place to start a product build, because a short planning phase answers the questions that make the rest of the choice hard. In a 2–3 week Discovery Sprint we run workshops and user research, plan the system, prioritise features, prototype key screens and write a build estimate. It costs ₹1.5–3 lakh. If you are not sure yet what the scope is, it helps to plan before you build.
Planning how your project will run?
See how a Tailwebs project runs, from the first call to launch, with each step ending in something you can check.
Which method fits your project?
The method that fits is the one that matches what you know today: how settled the scope and requirements are, how fixed the date is, and how much time your people can give the project. The checklist turns those into seven yes-or-no tests. Each test you tick points towards waterfall; few ticks point towards agile.
If you land in the middle, split the project: plan and fix the parts that are settled, and build the rest in sprints. A first version of a new product usually lands on the agile side, because its most important requirements are the ones you will learn from the first users. Our guide to building an MVP with agile covers that case, and agile works best with a roadmap that changes with the evidence: see the data-driven product roadmap.
How does the method shape the contract?
The method and the contract should match: waterfall pairs with a fixed price against a written scope, and agile with time and materials or a monthly team, because the contract decides who pays when the plan changes.
- Waterfall and a fixed price. The scope is written and signed before the build, so it can be priced as one outcome. Changes go through change requests, each estimated and approved before it is built.
- Agile and time and materials. You pay for the time the team spends, and you decide each sprint what it works on next. A monthly team is the same idea for a product with no end date.
- Hybrids and mixed contracts. A paid discovery followed by a fixed build, or fixed-price milestones priced one at a time, follow the hybrid methods above.
A mismatch is where projects go wrong. An agile build sold at a fixed price turns every sprint review into a negotiation about what the price covered. A waterfall plan billed by the hour loses the predictability that was the reason to plan everything upfront. Our guide to fixed price or time and materials follows one project through both contracts, and our pricing page shows how we set out fixed-price and monthly work.
How does Tailwebs run a project?
Our projects run in four steps, a call, a discovery sprint, a written proposal, then build and launch, and each step ends in something you can check. A team member is assigned within 10 days of approval. You can see how we run projects, step by step.