Waterfall as a failure-hiding algorithm

Imagine that you’ve been handed a death-march project and you need time to arrange a transfer or a new job, before the project fails.

If your company isn’t natively committed to agile, you can use the argument of “adding rigor and planning” to justify switching to waterfall, and then use waterfall to hide the failure until you can get out.

[No, I’m not seriously proposing this. Think of this as an Evil Overlord’s Handbook for development managers. I have seen it done, though, at a low-tech customer that understood neither agile nor dev/ops. ]


Keep the real requirements close to your chest.

Give the most generic description possible to QA, so they can’t write tests until the project is almost over. The longer you can keep the failure from being detected, the longer time you have to get off the project. This is the real benefit of waterfall: it’s hard to judge a project until the final stage.

Give clean requirements for a good demo subset to the architects, developers and ops. Tell them it’s a prototype or MVP (Minimum Viable Product), and there will be a rewrite in a new language before production. Preferably one they know nothing about.

Give a grandiose set of requirements to the PM, but insist you need an MVP first, so that you can see what the real customer requirements are. Encourage them to plan for the general case and ignore this preparatory work, as a “non-project”. In meetings, quote the estimates and plans for the “real” project.

In development

Fight very hard against scope creep, but be sure to lose every time.

If you accept a new requirement, stop development and go back to design, to be sure the new work is properly reflected in the design.  Be good about discarding now-obsolete code and starting over.

At the same time, be kind to developers if they need to slip the schedule.

Discourage unit tests, one the ground that it will make the MVP hard to change. In reality, the earlier testing is done, the earlier impending failure can be detected. You don’t want that.

If you’re still not getting interviews, tell QA you’re  desperately fighting scope creep and ask them to defer the start of testing for a week or two. Promise that you will slip the end date of testing by the same amount. Don’t tell anyone else that, though.


When you are forced to give the program to QA, give them the requirements for the MVP,  as late as possible so they can’t write automated tests.

Tell them it’s only an MVP, and encourage them to give it as little attention as possible, to further slow the process.

When they do report bugs, argue a bit. Delay the flow of bug reports to dev.

Declare each bug a requirements error, and carefully and thoroughly redesign the program. Feel free to add or remove entire subsystems or auxiliary programs.

If you’re still not getting interviews, tell ops the performance of a small QA server is entirely good enough for production.

In Preprod

Encourage ops to put you on  older or spare equipment initially, as this is an MVP and it’s too early to settle on production servers.

Do a good demo, but discover you needed quite a large server even to demonstrate.

Talk to purchasing and budget, and be modest about the importance of the project. Accept their objections with grace and kindness. Don’t tell anyone else that, though.

Throughout the process

Remember, there is exactly one way to do waterfall correctly:

  • first, do your requirements,
  • then design,
  • then  coding,
  • then testing,
  • then change the requirements.

Rinse and repeat.
If you’re lucky, you can keep this going for months.


















Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s