Introduction
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 maxwideman.com/papers/challenge/comments.htm
and maxwideman.com/papers/glossary6_1/goal.htm
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 maxwideman.com/guests/stateofart/specific.htm
|
