Spirit of Waterfall
- Posted on June 24, 2009 9:34:AM by Earl Beede to Practicing Earl
- Methods & Processes, Technique, Agile, humor, waterfall, thinking
It is not uncommon for me to see on blog posts, newsgroups, or presentations the phrase or comment that something is not, "in the spirit of Agile". In fact a project team could be doing many of the practices of Agile but, if it fails, the agilist will claim that the project was not Agile in “spirit”. And I was wondering, if that is the thing that was really wrong with the waterfall approach.
Consider it. It appears that many of the failings of agile or the miss application of agile is accredited to not being in the spirit. This occurs even when, if you look down a long checklist of practices, the team appears to be doing most all of the practices. However, because they were not empowered, or some other such factor, their experience is chalked up to bad execution, not bad methodology.
So maybe that is what is wrong with the waterfall approach. Sure, we have lots of practices that we were told to do, we have lots of activities the flow one from another, but we did we really understand its spirit? What would be the spirit of waterfall? I suggest this: the spirit of waterfall is “thinking”.
On the simplest level, the spirit of waterfall—thinking—is the look before you leap philosophy. Before you start doing something, think about it. Before I start doing design, I think about the requirements. Before I think about the requirements, I have a general understanding of what the heck this thing is supposed to be and the constraints I am under. Before I start doing code, do I have any clue about what the requirements or the design is? Did I think about it? Even better perhaps, as a team, did WE think about it?
“Thinking” of course does not mean solo cognitive work only. It means taking a rational approach that also identifies clearly the limits to what can be known and creating ways expose the unknown to make it known. (Flashbacks to Donald Rumsfeld are perfectly understandable at this point.)
On a more subtle level, the thinking was there as well. How much of the requirements were knowable? How much of the design was discernible? Those who ran the waterfall well (and yes, there were people who could run the waterfall approach well) were people who thought about those things. One of the big drivers that caused many waterfall/sequential projects to fail was that people didn't think about what was knowable and turned phases/stage-gates intended to be thinking/assessment points into document signing parties. They didn't think about what was right and, even if they did, they didn't share those thoughts with the stakeholders and steering committees; they just made sure the documents were signed. They knew that if the documents were not signed, there was heck-to-pay because the people on their steering committees didn't want to think either. And when the thinking stopped, the spirit of waterfall was defeated.
If we use the argument put forth by agile zealots that when you violate the spirit, no matter how many practices you perform, you aren't really doing the method, then we could say that a vast majority of sequential/waterfall projects—even if they were executing a lot of the practices—were really not doing waterfall. Oh it may have looked like waterfall, smelled like waterfall, they even went around touting the waterfall name, but without the “thinking” it really wasn't waterfall.
So perhaps the “not in the spirit” argument can give a new lease of life to the waterfall approach to software development. Probably not. “Waterfall” is mostly used as a pejorative word in the software development community. However I say, “Long live the spirit of waterfall!” We could all use a bit more rational thinking.