Agile vs waterfall: which method fits your software project?

A year ago a company signed a contract for a new membership platform with an 80-page requirements specification. In month nine they see the finished system for the first time. It does exactly what the specification says, but the world has moved on: half the members now use their phones, a new payment method has become standard, and two of the key features turn out to be too cumbersome in practice. Nobody did anything wrong. The method simply only gave them answers when change had become expensive. That is the heart of the agile vs waterfall debate.

This guide is written for those of you buying software who need to understand what the supplier’s method means for price, risk and your own time. You get the differences explained, a comparison table, a decision table, a worked example and a concrete answer to how a fixed price and agile development fit together.

What is the difference between agile and waterfall?

What is the waterfall model?

The waterfall model is the classic way to run projects. It gets its name because work flows downwards from phase to phase, and each phase must be finished and approved before the next one starts. The method comes from construction and manufacturing, where it makes good sense: you cannot recast the foundations once the roof is on.

Its strength is predictability: you know scope, price and deadline from the start, and there is thorough documentation. Its weakness is that you only see and try the solution late. If the specification has a gap, or the need has changed, it is discovered during testing, when changes are most expensive. It is one of the most common reasons software projects fail.

What is agile development?

Agile development is an umbrella term for methods that build software in small, finished pieces and use feedback to steer direction. The term was coined in the Agile Manifesto of 2001, in which a group of software developers set out four values, among them that working software and customer collaboration weigh more heavily than comprehensive documentation and contract negotiation. The most widely used methods are Scrum and Kanban. In practice an agile project typically consists of these elements:

• A backlog: a prioritised list of user stories describing what to build.
• A product owner on the client side who prioritises the list and makes decisions.
• Short cycles called sprints, typically 1–2 weeks, in which part of the list is built to completion.
• A demo at the end of each cycle where the client sees and tries what is new.
• A retrospective where the team improves its way of working.
• A definition of “done”, so everyone knows when a story is ready for use.

Agile vs waterfall: a point-by-point comparison

When should you choose agile, and when waterfall?

Can you combine a fixed price with agile development?

Yes, and in our experience it is the model that suits most small and mid-sized businesses best. Many believe agile requires hourly billing because the scope can change. But agile is about prioritising and delivering in small pieces, and that can easily happen inside a fixed frame. The key is to separate three things: what is fixed, what can be adjusted, and how changes are handled.

• Fixed: the price, the overall frame and the number of features and integrations.
• Fixed: the must-have stories, described with acceptance criteria before the start.
• Adjustable: the details of design and flow, clarified sprint by sprint.
• Adjustable: the order, so the most important things are built and shown first.
• Changes: a new idea can be swapped for a feature of equal size at no extra cost.
• Changes: if more is wanted, the addition is priced fixed before it is built.

Our packages follow the same thinking. You get a written fixed-price proposal within 24 hours, with the number of features and integrations listed, and you follow progress in our client panel, where you can see what is done and what is waiting on you. To dig into the economics behind the models, read our guide to fixed price vs hourly billing.

How the hybrid model works step by step

Worked example: the same customer portal with two methods

Picture a customer portal with 24 features and two integrations. The figures are an example. In the waterfall version everything is described up front, and the client sees the portal for the first time in week 12. It turns out customers want to download invoices as a single file, and the order overview is too heavy on mobile. Both require changes to code that is already finished, and the result is an extra invoice and a four-week delay.

In the hybrid version the same 24 features are agreed at a fixed price, but the order overview is built and shown in week 4. The client tests it on a phone and asks for a simpler mobile version, which is adjusted in the next cycle. The wish for bulk invoice download appears in week 6 and is swapped for a statistics page that everyone agrees can wait for version two. The portal launches on time and at the agreed price. Same team, same hours, same budget. What differs is when the questions get asked.

Which myths about agile development should you know?

• “Agile means there is no plan.” Agile projects have a clear direction and a prioritised list. The plan simply becomes more detailed along the way.
• “Agile means no documentation.” What gets documented is what creates value: user stories, acceptance criteria and technical decisions.
• “Agile is always more expensive.” With a fixed frame the price is known, and early feedback often saves hours.
• “Waterfall is outdated.” For projects with fixed requirements and many dependencies it is still a strong choice.
• “We need Scrum to be agile.” Scrum is one method. What matters most is short cycles, frequent demos and a prioritised list.

Which questions should you ask a supplier about their method?

1. How often do we see working software we can try ourselves?
2. Who on your side builds the solution, and do we meet them from the start?
3. How do you handle changes, and what do they cost?
4. What is fixed in the agreement: price, scope, deadline or all three?
5. How do you define when a feature is done?
6. How much time do we need to set aside each week?
7. How can we follow progress between meetings?
8. What happens if we want to stop halfway?

Good answers are concrete: a demo every week or two, a named contact in the team, a written rule for changes and access to an overview you can check yourselves. If you are starting from scratch, begin with a product discovery workshop, and see what a typical timeline looks like in our guide to how long it takes to build an app. If you are ready for a number, describe the project here and get a written fixed-price proposal within 24 hours.