Spirit of Waterfall

Published 24 June 09 09:34 AM | Anonymous

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.

Filed under: , , ,

Comments

# mattmcknight said on June 24, 2009 10:51 AM:

Well, that's not very charitable to the agile zealots, but all zealots are somewhat annoying, so, good show.  I think the "agile spirit" comments tend to be referring to the principles and the values expressed in the manifesto, wherein some non-agile process gets relabeled agile.  So "Working software over comprehensive documentation" is a value, but the team might be placing a very high level of importance on the documentation.  There is documentation in Agile, so you are not going outside of agile practices, but you are putting too much emphasis on the wrong part.

In fact, Agile, as defined by the Agile manifesto is a set of values and principles, not a process. In fact, the very first Agile value is to value "individuals and interactions over processes and tools".  A conflict arises when people become obsessed with a particular process, typically scrum, and begin to enforce adherence to that process without a focus on the underlying principles.

I think the waterfall spirit is less about "look before you leap" and more about "act as if everything is knowable" and "CYA".  Statements like,  "You signed off on those requirements and that's what you're going to get" seem to typify agile thinking.