Content assembled by R. Max Wideman, FPMI

Published here April 2018

Introduction | The Waterfall Methodology | The Agile Methodology
Making the Choice


I frequently receive, or come across, comments, suggestions and recommendations for improving our understanding of practical project management. I typically pursue the better ones with the author to see if I can give them broader publicity. This I can do by working them into one of my Musings, or perhaps into comments on a Book Review or Guest paper. The following is one such text, indeed several years old, but the author has requested not to be identified. Nevertheless, after several more months of contemplation, I still think it is worth exposing in this months Max's Musings.

But first of all, given the title "Waterfall vs. Agile", we must be clear that we are talking about the choice of implementation methodology for one particular group of projects. This group falls under the heading of Info Technology (& High Tech work), which is Type 4 in my simplified Typology.[1] By implication, the methodology described as "Agile" is generally not suited to the other specific groups: Construction, Healthcare, and Manufacturing.[2]

Let's look at an illustration of the comparison between Waterfall and Agile, assuming that both approaches involve seven identifiably different phases in their Product Development life span, see Figure 1.[3]

Figure 1: Product Development Life Spans for Waterfall and Agile methodologies

Assuming that this illustration is a realistic though simplified version of the comparison between the Waterfall and Agile approaches,[4] the arrangement of arrows representing progress, looks much more work-intensive in the case of Agile. That is because Agile depends in part on cyclic iteration, compared to Waterfall that is supposed to run straight through. However, the reality is that Waterfall requires virtual completion, unanimity amongst the performing stakeholders and signoff of each phase, before moving on to the next one. In effect, there is no turning back. Imagine designing and building a railroad route or new highway development, or any other type of major infrastructure project for that matter, and then up-rooting and going somewhere else? This is just not acceptable. Yes, I know it has been done, but at the cost of great public outrage and expense.

The Agile approach, on the other hand, says: "OK, we know where we are, and we know its not perfect, or there's more to be done. But let's 'send up a trial balloon' (perhaps representing the end of a stage), and let us learn from that. If it doesn't work the way we want, we'll simply go back and fix it!" This represents a huge saving of time as it effectively cuts off any lingering doubts that could otherwise extend the current stage or phase. And if it really doesn't work, in IT projects you can much more easily go back and rework, with the loss of time and cost minimalized, compared to the Waterfall approach.

Now, suppose you are faced with a new IT category project. One of the first decisions you face is "Which product development methodology should we use?" This is a topic that usually gets a lot of discussion (and often heated debate).

If this is not something you've had to face before, descriptions of the two development methodologies is in order. Put very simply, each is the way of organizing the work of software development. This is NOT about a style of project management, nor a specific technical approach,[5] although you will often hear these terms all thrown together or used interchangeably. Hence:
   Waterfall: Perhaps better recognized as the "traditional" approach, and
   Agile: a specific type of Rapid Application Development.
Agile is newer than Waterfall, but not that new. It is often implemented using "Scrum".[6] Both of these are usable, mature methodologies.

Our original author shares her thoughts on the strengths and weaknesses of each approach in the following pages.


1. See and
2. Although even in these groups, it is not unusual to set up a trial section to test the feasibility of any new technology, or to test the particular challenges to be faced in execution.
3. This illustration is a modified version of the one presented with the original text, both for clarification and copyright concerns.
4. A comparison though obviously simplified.
5. Actually, I rather think it is. That is, it is about the preferred management of the development of the product.
6. See
Home | Issacons | PM Glossary | Papers & Books | Max's Musings
Guest Articles | Contact Info | Search My Site | Site Map | Top of Page