In my book, The Nomadic Developer, I have a section of the book that defines various terms in a section called, appropriatley, Appendix B, A Consulting Lexicon.  One term I define is a new term I like to call “Faith Driven Development”:

Faith Driven-Development

A development practice also known as “code n’ pray” or “Waterfall”. It relies on an ever knowing business analyst write an Old Testament like book known called “The Requirements”; non-coding architect to write New Testament like book called “The Design”. Once those are done and cast in stone tablets, a developer (you) is called upon to code the system, with results in a situation that resembles the last chapter in the New Testament, called “Revelations”, in which the forces of good and evil fight on a giant battlefield, with massive bloodshed (a process known as “Testing or Quality Assurance”) after which there is a promise of a thousand years of utopia.

Sadly, it seldom ends this well.

Of course, as you might guess, when you run into the term “Waterfall”, you get redirected to “Faith Driven Development”.  I will admit up front that I am no fan of waterfall methods.   The largest reason why I am no fan of such methods has to do with what I believe is going on, in reality, when a waterfall project is sold:

A confidence trick or confidence game (also known as a bunko, con, flim flam, gaffle, grift, hustle, scam, scheme, or swindle) is an attempt to defraud a person or group by gaining their confidence.

(from Wikipedia)

In software, this game is played when someone sells a certainty of outcome when such certainty of outcome far less likely than he or she perports it to be.  The history of waterfall projects – especially waterfall projects with durations longer than a sprint or two – tells us that outcomes are highly variable as to when such a project will complete, if it is completed successfully at all (see Standish Chaos report, among other sources).  This is nothing new, of course.  The reason companies today ask us to underwrite fixed bid projects is to use it as a risk sharing mechanism to presumably reduce the chances that they will be conned, by having a company underbid the project, and then the project’s momentum to continue billing indefinitley.

There is, in effect, a race to the bottom effect in this business that means a consultancy can go out of business – or at least lose a lot of bids, because, buyers, will rush to firms that will tell them what they want to hear.  For the same reason that I might be tempted to try a snake oil that made it such that I could lose weight without effort, because there is demand for custom software with certainty of cost outcome, there will always be companies trying to sell into that market.  The toughest part of selling agile is being an honest broker in a world that accepts selling snake oil as viable business practice.

Which gets to my main point.  It is bad enough trying to be honest when many in the business world want desperatley to believe “the big lie of waterfall certainty”.  When the downturn comes though, the race to the bottom intensifies, resulting in some of the worst, riskiest projects known to man.  These projects are the waterfall projects sold during the downturn.

So what happens in a downturn that makes this risky?  First of all, competition intensifies.  You don’t just have two players telling the buyer what they want to hear, you have four or five.  Second, downturns cause short term to come into high focus.  If you are an account executive, and you are way short of quota, you might quote something at 50% of it’s true cost just to get  the deal and buy yourself some job hunting time.  If you are running an office and have a bench, you might even assume that you can cover any mistakes by throwing your bench at the problem – despite that such a move probably turns your net margin on the deal negative – even based on your most ideal assumptions.

In other words, the things that make waterfall a bad idea for consulting – the need to make promises based on hubris rather than observable facts, become even worse when consulting during a downturn.  During a downturn, the promises tend to be bigger.  The idea of forcing developers to work unpaid overtime becomes not only possible, but probable.  Quality not only goes down, it flat out gets cut from the budget (i.e. we all have seen QA become the first to go in such scenarios).

I know we all want certainty.  Nobody wants to just keep throwing money at a problem – or even at a solution, without some basis for finding out what the return on investment is going to be.  The problem, however, is waterfall is simply bad risk management.  It spends all the time mitigating change and process controls, while saying very little about how people actually work.  Waterfall and more old school PMBOK approaches don’t deal with:

• The fact that velocity picks up during a project – if you have the same team, based on the team growing in understanding of the domain
• Changes occur late in cycle even if the business didn’t change – based on increasing understanding

In fact, if you are doing steady “earned value management” type approaches with a presumed fixed set of deliverables, because average velocity starts low and picks up, you essentially start the project from behind.  Because you start from behind, you demoralize the team – and create the initial tendency to hide information about status that goes up the chain (remember – bad news tends to get hidden).

Waterfall assumes that people don’t learn anything valuable by doing.  It assumes that change is to be controlled, not harnessed.  It lies to it’s sponsor about team dynamics – creating the basis for “cover your butt” project management that stands behind dysfunctional teams and negative suprises.  In an upturn, at least when the project fails, you can get another job.  In a downturn, for you, and the sponsor, it is a far riskier problem.

When I conceived of this post, my first thought was to say “maybe you should do a risk matrix” to be transparent about the risks… but the more I thought, the more my instinct is to “just say no”.  I think I will go with that for now.