Taking hostages with Waterfall

It is ear­ly sum­mer, year 2013. A com­pa­ny I was work­ing for starts a new pro­ject sched­uled for re­lease in Sep­tem­ber. A few days ear­li­er, the pro­ject man­ag­er de­ter­mines that the pro­ject should take sev­en months, but the boss can't care less: since he de­cid­ed that the pro­ject will be re­leased in Sep­tem­ber, the pro­ject should be re­leased in Sep­tem­ber, with all the orig­i­nal fea­tures.

Jan­u­ary 2014. The pro­ject is at its ear­ly stage. The boss is fight­ing and scream­ing and blam­ing. The re­lease date is then resched­uled to the be­gin­ning of Feb­ru­ary 2014. “We sim­ply can­not re­lease it lat­er than that!”—tells the boss to the man­ag­er, and the man­ag­er re­peats it to the de­vel­op­ers.

March 2014. The pro­ject is resched­uled to be de­liv­ered in two weeks. Ac­tu­al­ly, it it is sched­uled to be de­liv­ered “in two weeks” for more than a month, and since we're 90% done—the pre­cise met­ric based on the fact that we al­ready shipped zero fea­tures, have -1/5 on ABCDE-T test and are cre­at­ing two bugs for every solved bug—there is no rea­son to be alarmed.

Month af­ter month, the boss tells that the pro­ject should be de­liv­ered for a spe­cif­ic date, and he's con­fi­dent that it will be. Month af­ter month, the pro­ject is not de­liv­ered. Then the boss yells at the man­ag­er, sets an­oth­er date, and be­comes one more time con­fi­dent that now, the de­liv­ery will be on time. That's smart.

Ag­ile pro­jects are mon­ey suck­ers

I was re­cent­ly talk­ing to a CEO of a small com­pa­ny. They do busi­ness which is com­plete­ly un­re­lat­ed to soft­ware de­vel­op­ment, but a few years ago, they've no­ticed a ma­jor room for im­prove­ment by adding soft­ware in their pro­duc­tion line.

So they've found a com­pa­ny which makes cus­tom soft­ware and ad­ver­tis­es it­self as be­ing at the edge of tech­nol­o­gy, be­ing a leader in this in­dus­try, and be­ing 100% Ag­ile™. Since all this mean­ing­less mar­ket­ing jib­ber-jab­ber wasn't look­ing sus­pi­cious to this CEO, the pro­ject was dis­cussed with this com­pa­ny, the price was de­ter­mined and the pro­ject fi­nal­ly start­ed.

The pro­ject was sched­uled to take three months. It took eight months and three times the orig­i­nal price es­ti­mate, and was then can­celled by the CEO. The IT com­pa­ny re­fused to give even a par­tial re­fund, ex­plain­ing that they did every­thing they could for the suc­cess of the pro­ject, and even added two more peo­ple five months lat­er to speed things up. Ac­cord­ing to the IT com­pa­ny, the fail­ure was the cus­tomer's fault, “be­cause [the cus­tomer] was con­stant­ly re­quest­ing changes which were not in the orig­i­nal con­tract.”

If this is how we do Ag­ile now, I'll start look­ing for a job in a dif­fer­ent do­main.

The old good Wa­ter­fall

In Wa­ter­fall, the cus­tomer/the boss doesn't de­cide when the pro­ject will fin­ish (and so how much would it cost). Man­agers don't de­cide nei­ther. Many of them are con­vinced they do, and con­vince their boss­es or cus­tomers that they do too. But the hard truth is that in bad­ly man­aged pro­jects (i.e. 95% pro­jects out there) cus­tomers, boss­es and man­agers have prac­ti­cal­ly no lever­age when it comes to the mo­ment when the pro­ject will be de­liv­ered.

If a CEO de­cides that the pro­ject will be com­plet­ed in three months and will cost $80,000, this doesn't mean any­thing. It can be com­plet­ed in six months and cost $160,000. Or twelve months, and $320,000.

Un­like old­er method­olo­gies of pro­ject man­age­ment, Ag­ile makes it pos­si­ble to put the cus­tomer in a po­si­tion to de­cide how much the pro­ject will cost.

In Wa­ter­fall, once you have the orig­i­nal es­ti­mate, you can re­ject or ac­cept it. Once you ac­cept­ed it, you be­come a hostage of the com­pa­ny which de­vel­ops the prod­uct.

• If you're giv­en an es­ti­mate, there is no com­mit­ment from the soft­ware de­vel­op­ment com­pa­ny to ac­tu­al­ly fol­low it. Is the es­ti­mate in the con­tract? What will hap­pen if the ac­tu­al price is high­er? That's right, you still pay.

• If you're giv­en a max­i­mum price, this is a com­mit­ment. Now, what will hap­pen if the com­pa­ny can­not de­liv­er on-time with­in the de­fined bud­get? Right, you'll have to de­cide when­ev­er you pay ex­tra to fin­ish the pro­ject or take the source code in its cur­rent stage and search for a des­per­ate pro­gram­mer to fin­ish the job rewrite the whole thing from scratch.

In both cas­es, you're screwed.

Ac­tu­al­ly, you're screwed on three dif­fer­ent lev­els:

1. If the ear­ly es­ti­mate ap­pears wrong, you have no oth­er choice than to pay ex­tra (to the same com­pa­ny or a third-par­ty) if you want to give to the pro­ject a chance to be fin­ished.

2. If your needs changed, there are some bad news for you: you will pay ex­tra, and then when the pro­ject fails, it will be your fault.

3. If your bud­get shrinks, there are more bad news for you: you still have to pay, and you don't have a work­ing prod­uct, but just a bunch of files with source code no­body can un­der­stand.

Wel­come, Ag­ile

In an ac­tu­al Ag­ile pro­ject, things hap­pen dif­fer­ent­ly.

The CEO may de­cide to start a pro­ject, ex­pect­ing it to be fin­ished in six months based on a giv­en rate per de­vel­op­er per week. Three months lat­er, he may find that it is much more im­por­tant for his com­pa­ny to fo­cus on a dif­fer­ent pro­ject and to sus­pend the old one. Mean­while, the old pro­ject re­mains in a work­ing state, and is al­ready used in pro­duc­tion. It pos­si­bly lacks some crit­i­cal fea­tures, which makes it not that in­ter­est­ing com­mer­cial­ly, com­pared to the ex­pec­ta­tions, but still, there are ac­tu­al users who find it use­ful.

Two months lat­er, it ap­pears that the sus­pend­ed pro­ject is quite a suc­cess. The num­ber of users grow every day, and some large com­pa­nies are buy­ing hun­dreds of li­cens­es, which means that the in­come is quite im­pres­sive. With all the un­ex­pect­ed mon­ey, the CEO de­cides to throw a team of high­ly skill­ful de­vel­op­ers on the pro­ject. They de­cide that the fea­tures that were not im­ple­ment­ed yet are not that valu­able, and re­ori­ent the pro­ject to­wards more in­ter­est­ing ones, based on the ac­tu­al us­age of the prod­uct. One month lat­er, the com­pa­ny ex­pe­ri­ences mi­nor mon­ey short­ages. The pro­ject is sus­pend­ed one more time, giv­en that the new fea­tures were re­leased on reg­u­lar ba­sis (twice per day), and user's feed­back was in­cor­po­rat­ed.

If a pro­ject is man­aged like that, there is no way to be­come a hostage of a com­pa­ny which haven't fin­ished the prod­uct and is ask­ing for more mon­ey. Sim­ply be­cause you're ex­pect­ing to see the ac­tu­al prod­uct with­in weeks af­ter the work be­gins. If the com­pa­ny is un­able to de­liv­er, you'll have enough time to stop deal­ing with the com­pa­ny, and go find an­oth­er one.

Wa­ter­fall and sim­i­lar mod­els make sense in very nar­row fields, for very spe­cif­ic pro­jects. Some life-crit­i­cal sys­tems don't fit well the Ag­ile mod­el, but, once again, those are rare ex­cep­tions. For all busi­ness soft­ware, Ag­ile have shown time af­ter time its su­pe­ri­or­i­ty, and it is even more valu­able for com­pa­nies where soft­ware de­vel­op­ment is del­e­gat­ed to an­oth­er com­pa­ny—one one side you keep keep lever­age over what the oth­er com­pa­ny does; on the oth­er, you be­come a hostage, with no pow­er of de­cid­ing how much would you pay, or how long would it take to re­lease a prod­uct.