Agile vs waterfall: which suits a business software project

What agile and waterfall actually mean

Waterfall is named for the way it flows in one direction: discovery, then design, then build, then testing, then release, each stage finished before the next begins. Changing your mind partway through means reopening an earlier stage, which is expensive and usually resisted.

Agile - most commonly run as Scrum or Kanban - breaks the same life cycle stages into short cycles, often called sprints, typically one to four weeks long. Each cycle produces working software, which is reviewed before the next cycle is planned. The plan is expected to shift as you learn.

Why most bespoke software projects lean agile

In our experience, the businesses who benefit most from bespoke software are usually not able to describe every requirement precisely before they've seen something working. A screen that looked right on paper often needs changing once someone actually tries to use it for a real order. Agile is built around that reality rather than pretending it away.

The other reason is money. If a waterfall project discovers a misunderstanding in month five of six, fixing it usually means reopening design and rebuilding. In an agile project, the same misunderstanding is usually caught within the sprint it appears in, at a far smaller cost.

When waterfall is the right choice

Waterfall earns its keep where the requirements genuinely are fixed and well understood before work starts - a system built against a defined regulatory standard, for instance, or one replacing a legacy system feature-for-feature with no scope for change. It also suits fixed-price contracts where the client wants cost certainty above flexibility.

• The requirements are genuinely stable and unlikely to change once written down.
• Compliance or audit rules require a documented sign-off at each stage before the next begins.
• The business needs a fixed price and fixed date more than it needs the ability to change direction.
• The system being replaced is well understood and there's little to discover along the way.

How this affects what you're quoted

This choice connects directly to how a project is priced. Waterfall projects are more often quoted fixed price, because the scope is fixed too. Agile projects are more often run on a day-rate or retainer basis, with the total cost depending on how many cycles you choose to run - which puts more control in your hands, provided someone is watching the budget each cycle.

Neither pricing model is a red flag on its own. What matters is whether the model matches the methodology - a fixed price quoted against an agile, evolving scope is where disputes usually start.

Can you mix the two?

In practice, most projects we run are a hybrid: a waterfall-style discovery phase to fix the overall scope and budget, followed by an agile build so the detail can adapt as it's built. This gives you the cost certainty of waterfall at the start and the flexibility of agile once work is under way.

The Agile Manifesto, first published in 2001 and still the reference point for the approach, is a short, useful read if you want the values behind it rather than a vendor's interpretation - see the Agile Alliance for a plain summary.

If you're weighing this up for a live project, our how we work page explains which approach we default to and why, and we're happy to talk through your specific scope on a call before you commit to either.