“The Mystery of the Waterfall Methodology”
By Holger Heuss, Pragmatic part-time Methodologist and Agile Practitioner
Edited by Kit Friend, Agile Evangelist and sporadic Methodologist
Disclosure: I am admittedly a bit of a methodologist. How do I know that? Well, mainly because I know the difference between a methodologist and a terrorist. What’s the difference? Let’s see to that later…
So as a methodologist and through the unpredictability of a professional career, driven in parts by the large numbers of mergers and acquisitions I went through, I have been exposed to and worked with several software development approaches from RUP (Rational Unified Process) and DSDM (Dynamic System Development Method), to project management methodologies such as PRINCE2 (PRojects IN Controlled Environments) or PMI (Project Management Institute).
(Un)surprisingly enough I would have described both RUP and DSDM as iterative and incremental approaches when I worked with them those many years ago in the 90s. For comparison, the Manifesto for Agile Software Development only emerged in 2001 — since then, I have noticed the exponential trend for people referring to “waterfall methodologies” and “agile methodologies” (and my agile coaching colleague cringing at the latter and correcting them to ‘mindset’ and ‘frameworks’ etc).
So how does this statement compare to the title of this article? Isn’t this a contradiction?
To provide an answer to those questions, we need to understand where the concept of the “waterfall” comes from, which are those “waterfall methodologies”, what do those methodologies portrait, and then try to explain why it is they are called “waterfall” after all.
So, where is the concept of the “waterfall” coming from?
The waterfall is attributed to Winston W. Royce who described seven implementation steps (Figure 2) to develop a computer program for delivery.
Analysing the process model, Royce identified inherent risks for failure and proposed a more incremental or iterative approach.
I believe in this concept, but the implementation described above is risky and invites failure.
Unfortunately, that commentary was on the next page of the paper (Figure 4) and the recommendation got lost — though I’m reliably informed many agile coaches delight in using it abundantly in their various outings.
Which are those waterfall methodologies?
“The waterfall is seen as the traditional methodology of software development”- so I thought and was surprised to hear that the project management methodologies are actually “waterfall”. So, after learning that the supposed inventor of the waterfall, who was describing a software development model, suggested that anyone with a logical view would take anything but a waterfall approach, now we come to the second mystery how and why the table was turned on project management methodologies.
What do those Waterfall methodologies portray?
“Scrum Masters don’t use PRINCE2” or so says my colleague Kit Friend, agile evangelist. I suspect there to be a multitude of reasons for the statement.
- PRINCE2
First check — visual; there aren’t any similarities to the typical look of the waterfall.
Themes and principles, by definition, are non-contentious.
The PRINCE2 processes are more interesting…
- Starting Up A Project
- Initiating A Project
- Directing A Project
- Controlling A Stage
- Managing Product Delivery
- Managing Stage Boundaries
- Closing A Project
The diagram portraying the relationships between the various processes, helps tremendously.
6 out of the 7 processes are either concerned with “Directing” or “Managing” the project.
This leaves us with “Managing Product Delivery” as the crucial process for further investigation.
The Managing Product Delivery process is binding together project management with product delivery. There is a whole section available, giving details on the how to complement PRINCE2 with agile under PRINCE2 Agile guidance for Managing Product Delivery (axelos.com).
Quel surprise! If you go onto a PRINCE2 training course you will learn to adopt a product delivery process that is most likely to guarantee the successful delivery of your project which might well be an agile delivery approach.
So, somehow, we failed to find real evidence that PRINCE2 is a waterfall methodology — (Kit: don’t you think now is the time to advise those agile coaches of your findings! They might learn something, you never know 😉).
Editor: added to the backlog Holger — always up for iteration
Maybe we have more luck looking at a programme management methodology…
- Managing Successful Programmes (MSP)
MSP is built similarly to PRINCE2 — consisting of a set of principles, themes, and processes that provide a roadmap for a programme lifecycle.
One of the main elements of MSP and its structure is the transformational flow represented by different steps that the programme will follow.
The steps of the transformational flow are
- Identifying a Programme
- Defining a Programme
- Managing the Tranches
- Delivering the Capability
- Realizing the Benefits
- Closing a Program
Looking at the steps, surely “Managing the Tranches” will help us finally to find the culprit, the clear indication for THE waterfall methodology!
The purpose of the “Managing the Tranches” process is to implement the defined programme management governance for the programme, ensure that the capability delivery is aligned to the strategic direction of the organisation, and enable the realisation of benefits. This specifically accepts that, as the programme progresses, this will need to be adapted and refined to assure the effective delivery of the tranches and the final outcomes/capability. So, let’s have a closer look.
- “aligned to the strategic direction” — tick, no issues
- “enable the realisation of benefits” — tick, no issues
- “will need to be adapted and refined” — tick, no issues but not only that, isn’t adaptability the very essence of agile?
Again, we failed miserably in our quest to find a waterfall methodology with the infamous steps…
We could continue this journey, looking in details at “Management of Portfolios” or indeed the equivalent project, programme and portfolio methodologies provided by PMI — the results will be the same and if we think back to poor Winston W. Royce this was somewhat expected given that what he described was the software development lifecycle.
Maybe a true ‘agilist’ is better placed to tell us what the waterfall methodology exactly is? I remain convinced it does not exist — but you can negotiate with me (which also answers the initial question of the difference between a terrorist and the methodologist — as I am an agile terrorist and not a methodologist!).
Editor: Stay tuned for Kit’s follow-up “When a team says Waterfall they often mean ‘chaos with gates we invented’”
