The Waterfall Technique
A few weeks ago, I was alerted by Email to a discussion on LinkedIn, which gave me both interest and amusement. I really thought that the responses were just too "good" to be lost in the annals of future history. The discussion was prompted by one: Will Toth,[1] with this question:
"Hello. Can someone explain the Waterfall technique to me? How does it differ from Agile or Scrum and is Waterfall specific to software development? Appreciate any information. Thank you."[2]
Here are a few of the responses in no particular order. If that means that some quotes are taken out of context, then so be it. Also, in this Musings I make no judgment as to who is right and who is wrong — that's up to the reader to decide.
Kris Jones:
"Threads like this just make me shake my head and sigh. The guy just asked for simple definition of Waterfall (quite why he couldn't just Google it I don't know, but anyway, it was about as simple a request as can be). If half the people on here cannot service that simple concise request, one can only wonder what you are delivering for your customers in your day job ..."
To which Anil Dilip responded:
"The reason for not to Google and use such forums is to get the practical knowledge about things from people's experience. Such info is richer than textbook definitions from Google or any other such media.
My comment: True, such info can be richer than textbook
definitions from Google or any other such media, but at the same time it may be
a simplistic, narrowly based, unproven off-the-cuff knee-jerk misleading response,
and indeed just downright wrong, as is even demonstrated in this thread.
Marko Brajak says:
"Waterfall is more rigid than agile. With waterfall you will probably do more planning at the beginning and you won't be adaptable to change during the coding period (or other later periods in the project).
Bill Duncan counters:
"Sorry, but I have to disagree with you. Properly defined, waterfall is just as flexible as agile/scrum. What waterfall (sequential phases) provides is a better idea early on about what the final results will be. Scrum or any similar iterative approach can be used during the development phase. Personally, I'm a big fan of XP for software development. Many organizations do take a rigid approach to waterfall that makes changes difficult, but that is a result of the ignorance and/or stupidity of the organization, not an inherent characteristic of the waterfall approach.
One simple example ... I had a client whose user couldn't decide whether or not something was a requirement or not. The PM suggested that they move on, and treat the item as a change during the design phase. Problem solved"
Larry Moore chimed in with:
" You can find a good definition of the "waterfall" project method at the following
web site: https://en.wikipedia.org/wiki/Waterfall_model"
To which, Bill Duncan hit back:
"The Wikipedia entry was clearly written by an advocate for non-waterfall approaches."
My comment: So much for that suggestion ...
In another entry, Werner Spreeuwenberg contributed:
"I remember the nineties when we as IT would sit with the business and gather all requirements. We would write Functional and Technical designs. Thereafter we'd build and run our own tests, before contacting the business again to perform the user acceptance tests. Yes, it was to be expected that we then had to go back to make changes to designs. And no, our lead programmer was not trained as a project leader but we survived with projects running over time and over budget. No wait, we did not plan and had no fixed budget and schedule. That was Waterfall in its purest incompetent form!"
The emphasis is mine.
In another exchange, Vince McGevna said amongst other observations:
"Waterfall is two things: a development process, and a derogatory term used by many Agile practitioners for what they, in their ignorance, define to be the dysfunctional world that only Agile can save."
Followed by Mike Richter who categorically stated:
"Agile and Waterfall are simply project management methodologies …
Of course there were a lot of other interesting comments, but I think that Larry Moore finally came the closest to hitting the nail on the head, when he said:
"Agile itself is NOT a PM methodology. It is merely a method for developing and implementing new software."
My conclusion: If only practicing project managers, consultants
and other related players would recognize and understand that there are two distinct
time-based processes involved in almost every project that is being properly managed.
These are:
- The Project Management Life Span (cycle) that the PMBOK® Guide[3] describes as Starting, Organizing, Working and Closing (that at its most simplest applies to most projects and typically requires the application of some sophisticated project management tools and techniques), and
- The Technical (technological?) Methodology, that is applied to create the intended product, that needs to be chosen to suite the product and the situation in which it is being created, and is certainly different for different types of product.
Of course, these two process strings must be carefully and properly integrated in practice. However, if we could think of them and deal with them separately, a lot of the discussions would be much simplified and a lot of the public confusion avoided.
1. A member of Agency Curriculum Business Analyst at Desjardins
2. Accessed January 30, 2017
3. A Guide to the Project Management Body of Knowledge, 5th Edition, Project Management Institute, p39
|
