PM-Partners Agile Learning Consultant and Facilitator Quinn Dodsworth explores what sets these two methodologies apart and explains why you always need a fit-for-purpose approach to project management in order to get the best results.

Agile and Waterfall explained

A cursory glance online at the value of waterfall projects will return mixed reviews. The most prevalent, however, can be summarised simply as: ‘waterfall projects are bad, agile projects are good’.

So why is waterfall getting such a bad rap? And should every project manager drop the use of waterfall to manage projects and deliver products?

As with most things in life, it’s not quite that simple.

Exploring the Waterfall Methodology

Let’s first take a look at waterfall projects, what they are and why people have used the waterfall methodology for many years.

Its history can be traced back to a 1970 paper by Winston W Royce, in which he outlined a way in which to develop software. The model was a breakdown of project activities in a linear sequence; each activity relied on the completion of the previous one in order to commence.

The main benefit of this approach is that it creates a simple process to follow, with defined steps or stages that can be planned well in advance. As it is inherently rigid, resources can be allocated ahead of time. This structure helps to manage and mitigate risk and, in theory, results in the efficient delivery of the product.

The problem is that while these projects are destined to be risk averse to ensure safety in delivery, the risk is then largely placed at the end of the project – in other words, the stage at which most of the time and resources have already been spent building the product. When the product is tested or presented back to the customer, serious issues may arise because, for example:

• The requirements have changed, due to today’s fast-paced business environment; or,
• The product did not meet the customer’s expectations.

In either instance, this would increase costs as the waterfall approach would require the team to start all over again, wasting considerable time, effort and money building something that was no longer fit for purpose. Ouch!

The Difference Between Agile and Waterfall Methodologies

This is where agile comes in. By working to shorter delivery and feedback cycles, the customer is able to input alongside its development, addressing changing requirements or expectations as the project evolves. By constraining work to a two to four-week block, that is the most time that would ever be wasted by the development team – rather than the entire development life cycle for a waterfall approach.

So, waterfall must be bad. Right?

Not quite. The approach that a project manager or organisation takes will depend on two things: what they are developing and the risk averse nature of the work.

Agile doesn’t necessarily lend itself to many products or organisational environments, and in fact it may prove a more costly, risky or less-efficient approach over the long term. Take, for example:

• A construction company is building a new gas plant. The company has an efficient process for constructing this type of facility and, given the potential risk involved, has planned and documented every stage. Thus, a waterfall approach is the smartest choice because there is no further need to ‘test and learn’ for deployment. On the other hand, when the plant is up and running and the gas company is looking for the most efficient way to read the pressure in the plant, an agile approach would be the most appropriate method of delivering the best solution.
• A small retailer wants to create an online store to increase sales. This is an entirely new venture for the company and could potentially secure the future of the business. They have a relatively small budget and are keen to see if their business fits an online sales model. Here, an agile approach would be the ideal fit so the retailer could test their online presence and see whether customers are interested in purchasing through them online.
• A firm is developing a new medical tool used for heart surgery. There is an extremely low risk appetite as the minimum viable product must be a fully functioning tool. Despite being a completely new product, requiring phases of prototyping and testing, a more blended approach between agile and waterfall would be most appropriate given the nature of the product and the critical service it will perform.

Agile Project Management is not the Only Solution

These are very simple examples but they illustrate key ways in which agile and waterfall have their strengths and weaknesses. Organisations are often pressured into embracing an agile approach at all times, simply because waterfall is seen as outdated. This is simply not the case.

I want to finish this post by introducing you to the Cynefin framework, created by Dave Snowden. In his own words, it’s designed to “help executives sense which context they are in so that they can not only make better decisions but also avoid the problems that arise when their preferred management style causes them to make mistakes”.

Below is a representation of Cynefin as depicted in PRINCE2 Agile®. Each segment provides a description of the different types of environments you might find yourself working in, and how to respond accordingly.