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.
Thanks for a good post, Thomas! This sentence was simply awesome: “It is the avoidance of this cost by reducing it that is Agile, and by avoiding it by avoiding the adjustment that is Waterfall.”
Wow. This statement “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.” is waaaaayyyyy over the top. I’ve done both methodologies. Agile is better. But Waterfall also works. To say it doesn’t work is either naive or misleading. The truth of the matter is that when doing Waterfall, there was still a period of feedback and adjustment involved. Unfortunately it was at the end instead of being embraced up front. But to say Waterfall is wrong, doesn’t work, or will be a thing of the past is ridiculous.
Well, I didn’t say that Waterfall (whatever that might be) doesn’t work. I’ve also done “both”. I said that taking the viewpoint that figuring everything out before starting (the viewpoint of Waterfall), is not the best view point. You will get better development, products, ROI if you take a completely adaptive viewpoint from the on-set. If there are things that you really need to figure out first, adjust your approach to do that. And most project will have some of those things. But don’t start out by thinking that you can avoid the cost of adjustment by thinking long and hard from the beginning.
Of course most Waterfall have a period of feedback and adjustment at the end. They have to. Because complete, true, Waterfall can never exist since development is exploration of possibilities and the world around a project is never static. But the time elapsing before you get this feedback is driving your development costs up and the first point of return on your investment into the future.
I truly believe that there are so much business value benefit in taking the “Agile” viewpoint that companies adopting it will outlive companies that doesn’t. Agile isn’t a single thing and definitely not a silver bullet. So I’m not really talking about the Waterfall/Agile religious war.
It will be the viewpoint that ensuring early, continuos and concrete feedback, and continuously adjusting to it with the lowest possible cost, that will be the competitive advantage.
Thomas, this was very well put:
“Because complete, true, Waterfall can never exist since development is exploration of possibilities and the world around a project is never static. But the time elapsing before you get this feedback is driving your development costs up and the first point of return on your investment into the future.”
That’s just one of the things that make agile better. ”
I’m not so sure waterfall will ever go away, but I do agree that companies which adopt agile will have more efficient IT departments. It all comes down to communication amongst stakeholders. Good post Thomas.
What often happens in my experience is that when people see the typical stage-gate project model with project phases and distinct decision points (gates) they map the “phases” of the (technical) development process on this model. So “pre-study” becomes “requirements phase” etc. A more reasonable relationship between the project phases and the (technical) development process was of course already described in e.g. RUP but it’s easy to fall into this linear trap. -Arto