My interest in this article isn’t really in denigrating Waterfall. It’s in the reinforcing feedback loop and the human tendencies that lead to its generation. If badly-done Waterfall is the straw man, then badly-applied Agile is the true enemy. While there isn’t any “rule”, there are certainly those tendencies in us, and without recognising them we end up overapplying certain Agile practices – particularly those that focus on knowing outcomes up-front. The audience of my blog is mostly made up of Agile newcomers and practitioners, and I hope that my focus is useful when it’s read in this context.

No twitter comment, blog post, or book has ever been a silver bullet, and my posts won’t be either!

But:

It’s a bit annoying that everyone deliberately ignore the fact that Winston W. Royce, in his paper about what’s now called Waterfall, clearly advocated an iterative approach.

“Feedback could (should, and often would) lead from code testing to design (as testing of code uncovered flaws in the design) and from design back to requirements specification (as design problems may necessitate the removal of conflicting or otherwise unsatisfiable / undesignable requirements). ”

Please, read again Royce’s paper, and stop blaming at waterfall.

“There is no explicit methodology called “waterfall” and there never has been.

It is nothing more than a straw-man used to criticize well established and proven analysis, design, and development practices.

No “rules” are being broken by going back and changing requirements models or artefacts when something is discovered during later phases for example. Neither is there any “rule” which says you must design everything in minute detail before starting to code, or that you can’t use OOAD, UI prototypes, feature backlogs (prioritized lists), or that developers can’t have direct end-user contact when using a “waterfall” process”
http://www.infoq.com/articles/agile-hybridization

I think you may have misunderstood the essential nature of SBCE (Set-Based Concurrent Engineering),at least as Toyota practices it. According to Kennedy, Ward, Toyota (TPDS) does not waste it’s investment in solutions not chosen (for the current model) but rather retains all the learning up to the point where a solution is “dropped” – for later use in future model developments. And three is just some notional number, concurrent options can range from several to twelve or more, as I understand it.

HTH

- Bob

Oh, and I think you’ll find the Chocolate Santas is my reference, I think I got the story from John Nolan

http://www.higherorderlogic.com/2010/07/bad-code-isnt-technical-debt-its-an-unhedged-call-option/

Long time, no see.

Lovely article, I particularly like the sound of those chocolate santas.

You really get to the heart of why I think Agile works for me. At heart we are all theory builders and poets. Whenever asked, how is it going, we used to have the tendency to create a little poem like “Analysis is 50% complete, or development is 99% complete… I’ve just….”

Agile gets us to bring reality back to our lives. To compare what is real in the world with those little theories and poems we have built in our minds. “50% complete” is replaced by I have tested two of my five hypotheses.

Agile is about knowing things with certainty, and nothing more than that.

As the purple kitten said

“When I’ve not started, I am 100% certain I am not doing it.
When I’m doing it, I’m 100% certain I am doing it.
And when I’m finished, I’m 100% certain I am done.
….for now.
When I say anything less or more than 100% I know that I’m dreaming up poetry for the entertainment of the professor….
And as I’m dreaming, I really have no idea where I really am and I could end up anywhere”

That’s an excellent post on change management. I would love to republish it on PM Hut (under the change management category) where many project managers will be able to benefit from it.

Please either email me or contact me through the “contact us” form on the PM Hut website in case your’re OK with this.