Agile vs Waterfall: Choosing a Software Delivery Method

By Grocito14 October 2026

Waterfall plans and specifies a whole project up front, then builds it in sequence: requirements, design, build, test, release. Agile delivers in short cycles, adjusting the plan as you learn. Choose waterfall when scope is fixed and changes are costly, and agile when the problem is uncertain and you want to steer. Most real projects borrow from both.

Key takeaways

Waterfall suits stable, well-defined scope. Agile suits uncertainty and products that will keep changing.
Agile does not mean no planning or no documentation. It means planning in smaller steps and documenting what is useful.
Agile asks more of the client: regular feedback, prioritisation and quick decisions.
Contracts under agile usually fix the team and the cycle, and keep scope flexible within a budget cap.
Judge a vendor by evidence of their process, such as demos, a visible backlog and honest reporting, not by the label they use.

What are agile and waterfall in plain terms?

Waterfall

Waterfall treats a project as a series of phases that finish before the next begins. You gather requirements, approve a specification, design, build, test and release. It is easy to explain and easy to contract because the scope is written down at the start. Its weakness is that you only see working software late, and changing your mind after the specification is signed off can be expensive.

Agile

Agile builds the product in small increments, each one usable and reviewable. After each increment the team and client look at what exists, decide what matters most next and adjust. The plan is a living list rather than a fixed document. Its weakness is that without discipline it can drift, and a fixed deadline with an open scope can cause tension.

How do Scrum and Kanban fit in?

Scrum and Kanban are two common ways to practise agile.

Scrum works in fixed-length sprints, usually a couple of weeks. At the start the team picks the work it can complete, at the end it demonstrates the result and reflects on how to improve. Roles are explicit: a product owner who decides priorities, the development team, and often a facilitator who keeps the process healthy.
Kanban has no fixed cycles. Work flows across a board from "to do" to "done", with a limit on how many items can be in progress at once. It suits support and maintenance work where requests arrive unpredictably.

Many teams blend the two. What matters is the habit of short feedback loops, not the vocabulary.

When does waterfall still fit?

Waterfall is not outdated. It makes sense when:

The scope is fixed by a regulation, a standard or a contract, and cannot realistically change.
The project depends on hardware or physical processes with long lead times, so late changes are very expensive.
The requirements are well understood because you are rebuilding something that already exists.
Formal sign-off is mandatory at each stage.

Even then, teams often use short build and test loops inside the build phase.

When does agile fit best?

Agile fits when you cannot know everything in advance:

A new product where users' real behaviour will teach you what matters.
A project where the market, the business or the priorities are likely to shift.
Work where you want to launch a useful first version early. Our guide on MVP development shows how this works in practice.
A product with a long life, where continuous improvement matters more than one big release.

The hybrid reality

In practice, most business projects are hybrids. You might fix the overall goals, budget range and key milestones up front, as a waterfall plan would, then build in sprints with regular demos. Or you might run a short, structured discovery and design phase, then switch to iterative delivery. Insisting on purity helps nobody. Ask what combination gives you enough predictability to plan the business and enough flexibility to respond to what you learn.

What does agile mean for you as the client?

Agile changes your role as well as the vendor's.

Involvement. Someone from your side needs to be available, ideally a named product owner with the authority to decide.
Regular demos. You will see working software every cycle and be expected to react to it honestly.
Backlog prioritisation. The backlog is the ordered list of everything that might be built. You decide the order, and you accept that not everything will fit.
Changing scope. You can add, remove or reorder items, but every change has a trade-off. Adding something means something else moves later or out.
Faster decisions. A team that waits days for an answer loses its pace.

If you cannot provide this involvement, an agile approach will disappoint you however good the vendor is.

Contracts and budgeting under agile

Agile does not mean an open cheque. Common ways to keep control:

Capped time and materials. You pay for the team's time up to an agreed ceiling, with a review point before more is committed.
Fixed team, fixed cycle. You pay for a team of a given shape per month, and scope flexes within that capacity.
Phased contracts. A defined first phase, such as discovery and a first release, followed by decisions on the next phase.
Fixed price with defined variation. A fixed price for a prioritised core, with agreed rates for additions.

Whichever you choose, agree how progress is reported, how scope changes are decided and how you can stop or pause the work. Our article on reading and comparing software estimates explains how to judge the numbers.

Documentation and common misconceptions

Does agile mean no documentation?

No. It means valuing working software over exhaustive paperwork, not abandoning records. You still need user stories or requirements, decisions, architecture notes, test evidence, and handover documentation. A good team writes what the next person genuinely needs.

Does agile mean no planning?

No. Agile teams plan constantly, in smaller pieces. There is usually a high-level roadmap, a prioritised backlog, and detailed planning for the next cycle.

Does agile mean the scope can change forever?

No. Change is welcome, but within a budget and timeline. Someone must decide what to drop when something new arrives.

Who does what: the product owner and other roles

The product owner is the single person who speaks for the business, orders the backlog and accepts or rejects the finished work. When this role is shared by a committee, or filled by someone without authority, the team gets conflicting instructions. Other typical roles are the developers and testers who build and check the work, a delivery lead who removes obstacles, and a designer. Make sure you know who plays each role on your project, and who from your side is the product owner.

Signs your delivery process is failing

Demos are postponed or consist of slides rather than working software.
The backlog is huge, unordered or nobody can say what is next.
Deadlines keep moving and the reason is always "something unexpected".
Bugs pile up while new features continue to be added.
Decisions wait for people who are never available.
Status reports are all green until suddenly they are not.
Team members change often and knowledge is lost.

How to evaluate a vendor's process

Ask for specifics rather than labels.

How do you run a typical cycle, and what will we see at the end of it?
Can we see a sample backlog, a sample sprint report or a recent demo recording?
How do you handle a change that arrives mid-cycle?
How do you estimate, and how do you report when estimates are wrong?
How do you test, and when does testing happen?
What do you need from us each week?
How is the work handed over at the end, including documentation and source code?

Tooling

Whatever method is used, a shared place to track the work is essential. A project and task management tool gives both sides a single view of the backlog, priorities and progress. For agencies and development teams choosing software for this, see our guide to project management software for agencies and dev teams.

A worked example

Imagine a logistics company wanting a customer portal. Part of the project is fixed: it must integrate with a regulated customs system whose format cannot change. Another part, the customer dashboard, is not clear at all. The company and its vendor agree a hybrid. The customs integration is specified up front and built in a defined phase. The dashboard is built in two-week cycles, with the operations manager acting as product owner and reviewing a demo at the end of each. After the third demo they drop a planned reporting screen and replace it with a delivery-status view that users actually asked for.

FAQ

What is the main difference between agile and waterfall?

Waterfall completes each phase of the project before starting the next, based on a specification fixed at the start. Agile builds and reviews the product in short cycles and adjusts the plan as it goes.

Is agile better than waterfall?

Neither is better in every case. Waterfall suits stable, well-defined scope with costly changes, and agile suits uncertain or evolving products. Many projects use a hybrid of the two.

Can agile projects have a fixed budget?

Yes. A budget cap, a fixed team size or a phased contract keeps spending under control while the scope stays flexible. What gets built is decided cycle by cycle, within that limit.

How much should a client be involved in an agile project?

Quite a lot. You need a product owner who can prioritise, attend regular demos and make decisions quickly. A lack of involvement is one of the most common reasons agile projects struggle.

Next steps

List the parts of your project that are fixed and the parts that are still uncertain, then ask each vendor which method they would use for each part and why. If you want help choosing a delivery approach, or a team that can work in the way that suits you, contact us.