In this blog, we will look at the merits of using waterfall or alternatively agile.
Both approaches have their merits but in some organisations the proponents of waterfall and those of agile seem to think that one approach is good and the other is bad.
This zealotry is misplaced and as we will see both approaches are relevant.
Has the waterfall method of delivery projects had a bad rap?!
Many LinkedIn commentators and indeed organisations are going ‘agile’.
There is a reasoning amongst some professionals that agile means nimble, flexible, adaptive etc.
All of which are good attributes for any methodology.
Conversely, if you are not ‘agile’ you must be: rigid, slow, fixed, etc.
On the face of these attributes who wouldn’t pick an agile approach compared to a waterfall approach.
This is, of course, far too simplistic.
Let’s look first at what a waterfall approach to delivering projects really means and also the misconceptions around it.
The waterfall methodology is so described because the stages of a project tend to be sequential rather than iterative.
Each phase needs to be completed before the next stage starts.
A depiction of a waterfall project approach is shown below.
In the initiation phase you are understanding the objectives of a project, the scope, costs, benefits and mobilising the team.
You then progress to the requirements phase where you document and get the users to sign off the user or business requirements.
Next, you specify these requirements in more detail, undertake technical design, build, test and then transition into a live service.
The criticism that is often levelled at waterfall is that users get involved in requirements gathering and specification, but then there is a gap of user involvement until user acceptance testing.
In this intervening gap, requirements may change and / or the requirements are misunderstood by the project team.
The logic then continues that as the business environment is changing at a rapid rate, the requirements are likely to change and, if the users are not involved in the mid-part of the life cycle, changes to requirements are not fed into the project team.
This leads to projects being delivered that may meet the original business requirements but no longer reflect what is actually needed.
The reality, in my experience, is that this does not happen in a well-run project.
A ‘good’ project manager wants to deliver the outcomes that the users want and need.
It makes sense for the project team to liaise and communicate with the user community during all aspects of the project and not just the requirements gathering and specification.
There are many situations where the requirements do not change a great deal over time and there is an advantage of defining requirements and specifying these to a low level of detail.
Some project teams are more comfortable with the waterfall approach because – if the requirements are not likely to change – there is more certainty in what is needed to be delivered and it is easier to manage a set of sequential phases.
There are a number of situations when a waterfall approach is ideally suited.
The agile methodology has a very different approach to waterfall. There is more emphasis on flexibility and speed of delivery.
There is a real focus on delivering modules or part of a project quickly. There are numerous agile approaches.
A common one involves developing user stories which are a set of mini requirements or features of a system.
These user stories are developed in close conjunction with the key users.
As we will see later the agile philosophy is to work very closely with the users and the product owner.
These user stories will have broad estimates and then placed in what is called a sprint.
These sprints are typically time bound and during the sprint some stories may be demoted from the sprint and not delivered as there is typically a fixed sprint delivery date.
There are a lot of feedback loops in agile and it delivers software in a set of iterations unlike waterfall which tends to be more sequential and often results in a ‘big delivery’.
The original team of professionals who developed agile as a method developed a number of agile principles which I have detailed below:
Source: Agile manifesto
These are a great set of principles but they also rely on certain organisational factors to be in place.
For example, there is more emphasis, than in waterfall, on self-organising teams and a level of trust is needed to get the job done.
There is also a requirement for teams to be collaborative and the users / sponsors to be part of the team.
Ideally, the team is located in the same place as this makes collaboration and self-organising easier.
Yes, a lot of teams are now working from home and using Teams or Zoom, but this is not as efficient as collaborating in the same place.
There are a number of situations when an agile approach is ideally suited. These include:
There are many benefits of agile and these include:
A number of years ago I was called in to review a large software redevelopment.
This retailer wanted to upgrade the technology platform of their Point-of-Sale system.
The were happy with the requirements and, to reduce training costs, they wanted the new system to look and operate in exactly the same way as the current system.
The requirements of the new system were very clear and understood.
The scope was also very clear and it was not acceptable to drop anything out of scope.
The development manager had adopted an agile approach to this project using an off-shore partner in India.
This project was not going well and headed for the rocks.
There was no benefit in going agile for this project; in fact quite the reverse as the team was not used to the fluidity of the agile approach or able to self-organise.
Requirements were documented and were unlikely to change.
The scope and end goal were also clear.
Agile was chosen because the development manager wanted to try this new approach.
In this case the project would have been more successful if a more traditional waterfall approach was used.
This project met all the criterial listed above that would suggest a waterfall approach.
For as long as I have been involved in project management IT has been searching for the silver bullet that would deliver projects more quickly and more successfully.
Unfortunately, the statistics on project success rates have not improved despite the various ‘silver bullets’ that have been tried.
In my opinion, agile is a great approach for certain types of projects but it can be a more complex set of processes to manage.
The agile teams have to be adaptive and absorb frequent change.
Not every team is capable of delivering in an agile way nor are all projects suited for an agile approach.
Unfortunately, too many organisations have ‘gone agile’ for every project.
As I have stated, not every project is suitable for agile and before you throw out the ‘old-fashioned’ waterfall method, ensure that the proposed project and team are suited to an agile approach.
Waterfall has had a bad rap over the years and people who still run waterfall approaches are considered dinosaurs and behind the times.
The reality is that some projects are ideally suited to waterfall, and you will improve your project delivery success rate by choosing the right approach for each project.
PM3’s Support for Agile and Waterfall
PM3, Bestoutcome’s award-winning Project, Portfolio Management (PPM) tool supports both traditional waterfall projects and also agile projects.
PM3 supports: user stories, sprints, Kanban and also burndown charts.
I am always wary of the organisations that have gone agile for every project.
Some projects and teams are suited for agile, but others are more suited for a traditional waterfall approach.