I just found an excellent description, and name, for a “disease” that I hope I’m not afflicted by. You can see the effects of it in many places, particularly in development and engineering environments. I think many instances of Agile initiatives gone wrong can be traced back to someone with the disease. This article by Scott W. Ambler describes it in detail.
Waterfall isn’t dead, but it’s the wrong viewpoint
There has been a very active discussion on the LinkedIn Agile group on the topic of “Surely waterfall methodlogy is no more but who is secretly still using it? Come on, admit to it!!!“.
Interestingly enough, there were a number of people “admitting” to using waterfall 😉
My first comment in that discussion went on the lines of Agile and Waterfall not being two well-defined methods, but instead are strong simplifications based in two very different viewpoints. Waterfall being based in the thinking that we should think the whole thing through before starting, drawing and deciding on a detailed plan, write complete, reviewed & approved specifications before doing any implementation, and so on.
Agile on the other hand is based in the adaptive thinking. The best way to get to the goal is to start the journey. And ensuring that we get feedback along the way.
I would presume that all development organisations are doing something in between, at least I have not seen one doing “true” waterfall or “true” agile (in this sense, at least).
In the discussion, however, there where multiple comments along the lines that “once we get our first release out we can go agile, until then however we must think things through, so we’re sticking with waterfall”, or “in our environment demands on <insert requirement here> is so high that we cannot use agile”.
To me these arguments express a misconception of agile which I meet now and again. The misconception is that Waterfall is the “standard model” and if there are some particular circumstances you are “allowed to become” or “might benefit from” Agile.
I think the reasoning is backwards. There is no way that thinking everything through before starting can be better than starting out to get quick feedback. Unless your cost of adopting and adjusting based on that feedback is very costly. Agile, and Lean, techniques are very much about reducing this cost. It is the avoidance of this cost by reducing it that is Agile, and by avoiding it by avoiding the adjustment that is Waterfall.
So the only way to reason is to start with an Agile viewpoint, embrace the feedback and the adjustment that we can make based on it. That will bring us the best product to the market with the best possible cost/functionality/quality ration. If there are reasons why the cost of this adjustment is prohibitively high, look for ways to lower it, e.g. by adopting some of the Agile or Lean techniques. If that is impossible, move the problem towards a more “early decision”. But make sure that only influences the things which are prohibitively costly to act on the feedback.
I strongly believe that the viewpoint that Agile have is going to be, will have to be, the way all developing organisations will have to take in the future. The “Agile viewpoint” brings so much business benefits that companies not adopting it will not exist. There is no longer a price per hour competition, its about maximizing business value per invested dollar or euro.