Comments on: Waterfall Projects Create Naivete

By: Andrew

Andrew — Mon, 30 Jun 2008 05:48:44 +0000

With due diligence, any process can be made to work for you. However, there is commonly held belief - backed up by some good research - that states that waterfall was accidental. Refer to Craig Larman’s book - Agile and Iterative Development, a Managers Guide.

In the past, I have definitely found SMOP attitudes foster negative thinking and assumptions that development of software can be likened to that of a car production line.

What I like about iterative and incremental approaches, is that they help focus us on scope management to address time and money issues of the past. I can now comfortably state that our project will be done by X. What constitutes that release is negotiable and comfortably accommodates change and I have not worked with any managers/customers who have found this disagreeable, in fact just the opposite, most like the idea that they will get something for their money.

Using the waterfall approach, there is a deadline which team members often realize cannot be met - so there is no feeling of when things will be done. Development can drag on, often because of change and misunderstanding, managers lose confidence because they have seen nothing and sometimes end up pulling the plug on the project.

By: Glen B. Alleman

Glen B. Alleman — Wed, 25 Jun 2008 15:25:26 +0000

I’ve found the best escape from the Water Fall / Iterative loop is to ask if the proposed approach to project can answer the following:
1. How can we recognize “done,” in this process or plan?
2. What are the units of measure of “done,” that is “what is the unit of measure of physical percent complete?” This can be partially complete or fully complete?
3. How long am I willing to wait before I find out I’m late, over budget, or the product doesn’t work at this point in the project?
These question invert the argument of “my process versus your process.”

By: David Wright

David Wright — Tue, 24 Jun 2008 21:01:56 +0000

“But there’s an even more insidious assumption in waterfall: that the time to finish the project doesn’t matter”.

‘Scuse me? Business Management loves waterfall because they can see phase end and project dates in the project plan. They hate iterative because they don’t know what they are getting or how long it will take. If you can get by that, by all means, go Agile, but I don’t know how you get by it with management that thinks this way.

The correct length of time for a release cycle is 3 months. You can deliver a useful product release in that time-frame with any methodology without so much of the requirements change everyone fears (let alone project team turn-over), add another in 3 monthhs and so on. Go longer and change and business impatience will kill you. Go shorter, and the business will say you are disrupting their operations too often with implementations. Business everywhere operates and reports on quaterly cycles, we should too.

By: Dwayne Phillips

Dwayne Phillips — Mon, 23 Jun 2008 15:03:40 +0000

Johanna, maybe we are using the same words to mean different things. I think I disagree with your statement that “waterfall projects create naivete.”

I am currently working a project that is waterfall. We know what we want and will hold to that. There are ten people working nine months on the project. This will produce a system comprising hardware and software, is embedded, and does real-time processing.

Time to deliver matters on this project.

Perhaps this project is a simple matter of design, build, test, deliver. If it is simple, that is because I am holding the complexity of the system down to the minimum. I have seen too many systems never built because of complexity growth.

So again, maybe we are using the same words differently.

By: links for 2008-06-23 | the markfr ditherings

links for 2008-06-23 | the markfr ditherings — Mon, 23 Jun 2008 12:33:56 +0000

[...] Managing Product Development » Waterfall Projects Create Naivete Commentry on the shortcomings of waterfall. I’ve been there and done that in a software house. Things never change when you fail to met expectations and money is involved. That said the software house always feels safe pointing back to a naive spec. (tags: agile management programming waterfall projects article) [...]