Waterfall Projects Create Naivete

I've been working with several clients on their transitions to agile–or at least, more agile approaches to their projects. In each case, the managers decided to move towards agile because the technical staff were in their words, “naive” about the project goals. To be fair, none of the projects had a vision or release criteria, so it's not surprising the technical folks didn't understand the project goals.

But waterfall, with it's emphases on understanding up front,  helps create that naivete. If you could understand requirements or design up front, then the project is just a SMOP (Simple Matter of Programming). And the testing is just a SMOT, and the writing is just a SMO (Testing and Writing). With a SMOP attitude, everyone assumes the predictive schedules are correct, creating a sense of naivete for the entire project–not just the technical staff. The managers are naive about what the milestones really mean, and everyone's naive about the entire schedule.

But there's an even more insidious  assumption in waterfall: that the time to finish the project doesn't matter. This attitude arises even more if a senior manager or program manager or project manager says something like, “Quality is Job 1.” At some point, this project has to end and the product has to ship. Maybe not next month, maybe not even next year, maybe the year after. But at some point in time, the product will ship, regardless of the technical staff's perception of quality. And that's where waterfall lets down the entire project team.

I haven't worked on a project or consulted with a company where they had endless time to get to release for at least 20 years. (I can only remember one project where we were not under time pressure back in the early 80's. But maybe I can't remember much 🙂 Granted, I tend to work on or with projects in commercial organizations, so if you're working on a government project, maybe you have more flexibility in time.

But a waterfall project organization, where you have milestones such as “requirements complete” or “feature freeze” or “feature complete” provide a disservice to the entire project and management team. We know the requirements are not complete. We know the features will change. Saying they are complete or frozen won't change reality. But those complete or frozen milestones provide a sense of inevitability about the eventual ending of the project, and infer that since we're “meeting” (ha!) the project milestones, that we will continue to. That's the naive part. (See There is No Such Thing as Percent Complete and Showing Project Progress (NOT percent complete) for why.)

Waterfall is fine for a few weeks (4 or fewer), and a few people (4 or fewer) and where you're sure the requirements are not going to change. Absolutely, positively sure. No surprises. But if you have a larger project or a longer project or you have a suspicion things might change, you want to work differently. I recommend you read my recent Cutter IT article, What Lifecycle? Selecting the Right Model for Your Project to see ways to organize your projects so they make more sense.

Naivete can be charming in people. But it makes for badly organized and executed projects and programs. Waterfall reinforces naivete. Any other lifecycle allows you to take a more empirical approach, rather than a more predictive approach. The agile lifecycles are all about empiricism, so they banish naivete–at least, about schedule–completely. Choose any other lifecycle, and you can take a mature, not a naive, approach to your projects.

5 thoughts on “Waterfall Projects Create Naivete”

  1. Pingback: links for 2008-06-23 | the markfr ditherings

  2. 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.

  3. “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.

  4. 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.”

  5. 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.

Leave a Comment

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: