Should I Use Waterfall or Agile?

So, your development team keeps saying you MUST adopt agile but your business change team insists on waterfall - how do you choose?

If you have any involvement with software development, you must have heard about how great Agile is and why you absolutely must use test-driven development with extreme programming, daily scrums, etc., etc.. So, what do "waterfall" and "agile" really mean, and how do you choose which one to use?


Simply put, waterfall is an approach where detailed design happens first, then build, then test comes last.

It is simple enough, and makes sense – at least until you get halfway through and realise there is a three-week chunk of work missing from Section 8, sub section C, paragraph iii. Or the market changes six months in and you need to re-work something you did in month one.

Both of these WILL happen at some point and they highlight the need for very good change management and project governance. It is perfectly OK to discover a new requirement or need to change a specification so long as you treat them as formal change requests and are prepared for the associated cost increase. To do this, you need to understand:

  • what the new specification is (to the same level of detail as the original project)
  • how it impacts on the original project and what additional costs will be involved
  • what the business case for the original project looks like without the changes (to decide if it is still viable).

With this information, your Change Management team can assess the business case for each change and decide whether or not to accept it (and whether or not the project is viable without it). This obviously takes time and resource, during which some or all aspects of the project will need to slow down or stop - as a result, all but the most trivial change requests will result in delay and cost increases, whether or not they get accepted.


Agile methodologies such as Scrum and Kanban give an alternative approach where design is roughed out up front, then the product is built in iterations with a little more functionality being defined, built and tested in each iteration.

This is also simple enough (and you won’t have that problem with Section 8, sub section C…) but it isn’t great if you want to tell your customer up-front how long it will take and how much it will cost to deliver their functionality, and fabricators with three month lead times won’t appreciate being told to change the metal-work every two weeks!

One major factor that you simply cannot afford to ignore when considering agile is your business environment. If you have not used agile before, there is going to be a learning curve across the whole business. It is not enough to just adopt agile within the development team as this team needs support from elsewhere. As a rough rule of thumb, look at your internal stakeholders and project board:

  • if they are already using agile principles effectively, you are fine and can probably rely on internal support
  • if they willing to adopt and support agile principles you have a good chance but will probably need external agile mentoring to make it work
  • the more that are not willing to support agile, the harder it will be to run an agile software development approach
  • if more than a few key players are not, you are going to have real difficulties and need to consider other options

Delivering Fix Cost Projects

Many contracts are fixed cost and most people thinks this means waterfall is essential. However, if you take a look at the "Iron Triangle", you will see that if you fix scope (inherent in the nature of waterfall where the scope is set up front) then the only things that can change are time and budget (or you might be able to cut corners on quality). In reality, you are going to be in one of two scenarios:

  1. limited costs so time must move and the project runs late or
  2. rigid deadline so costs go up as you throw resources at the problem

There is even a good chance that both will happen.

iron triangle comparison

Comparing this with agile approaches and we can fix the time and cost so long as we accept the scope can shift. This means the project will be on budget and on time but that some functionality may need to be left to a later project phase.

Scrum and Kanban both handle this very well and the product backlog gives a very neat mechanism for prioritising requirements with the customer so that the lowest priority ones are the ones that are dropped first.

The upshot of all this is that, for truly fixed cost projects, the only real option you have is agile.

Is PRINCE2 Waterfall?

Emphatically, no.

PRINCE2 gives a very useful structured approach to tackling a project but does not set out any particular methodology. In fact, one of PRINCE2's great strengths is its flexibility if it is used right.

At The Peak Consultancy, we typically use PRINCE2 to give a structured project management approach (and MSP for larger programmes), then use either waterfall or agile depending on the specifics of each deliverable. Please read our "How to Plan Successful Projects" series to understand more about this.

Which Methodology Should I Use?

Coming back to the original question, “should I use waterfall or agile”, the only honest short answer we can give is “either, or both – it depends”. Just please make sure you don’t fall into the trap of thinking that adopting a new methodology will fix all your woes!

For help and advice on choosing a project methodology, or if you are considering adopting agile in your business, we can help: please get in touch to arrange a free consultation.