Home Home

Taking hostages with Waterfall

Arseni Mourzenko
Founder and lead developer, specializing in developer productivity and code quality
December 11, 2014

It is early summer, year 2013. A company I was working for starts a new project scheduled for release in September. A few days earlier, the project manager determined that the project should take seven months, but the boss can't care less: since he decided that the project will be released in September, why wouldn't it be?

January 2014. The project is at its early stage. Management and direction are fighting and screaming and blaming. The release date is rescheduled by the boss to the beginning of February 2014. “We simply cannot release it later than that!”—tells the boss to the manager and the manager to the developers.

March 2014. The project is scheduled to be delivered in two weeks. It has been more than one month that it is scheduled to be delivered “in two weeks”, and since we're 90% done (the precise metric based on the fact that we already shipped 0 features, have -1/5 on ABCDE-T test and are creating two bugs for every solved bug), there is no reason to be alarmed.

Month after month, the boss tells that the project should be delivered for a specific date, and he's confident that it will be. Month after month, the project is not delivered. Then the boss fixes another date, screams on the manager, and is again confident that this time, the delivery will be on time. That's smart.

Agile projects are money suckers

I was recently talking to a CEO of a small company. They do business which is completely unrelated to software development, but a few years ago, they've noticed a major room for improvement by adding software in their production line.

So they've found a company which makes custom software and advertises itself as being at the edge of technology, being a leader in this industry, and being 100% Agile™. Since all this meaningless marketing jibber-jabber wasn't looking suspicious to this CEO, the project was discussed with this company, the price was determined and the project finally started.

The project was scheduled to take three months. It took eight months and three times the original price estimate, and then cancelled by the CEO. The IT company refused to give even a partial refund, explaining that they did everything they could to make the project work, especially added two more people five months later to speed things up. According to the IT company, the failure was the customer's fault, “because [the customer] was constantly requesting changes which were not in the original contract.”

If this is how we do Agile now, I'll go search for another job.

The Real Sucker™

In Waterfall, the customer/the boss doesn't decide when the project will finish (and so how much would it cost). Managers don't decide neither. Many of them are convinced they do, and convince their bosses or customers that they do too. But the hard truth is that in badly managed projects (i.e. 95% projects out there) customers, bosses and managers have practically no leverage when it comes to the moment when the project will be delivered.

If a CEO decides that the project will be completed in three months and will cost $80 000, this doesn't mean anything.

Unlike older methodologies of project management, Agile makes it possible to put the customer in a position to decide how much the project will cost.

In Waterfall, once you have the original estimate, you can reject or accept it. Once you accepted it, you become the hostage of the company which develops the product.

  • If you're given an estimate, there is no commitment of the software development company to actually follow its own estimate. Is the estimate in the contract? What will happen if the actual price is higher? That's right, you still pay.

  • If you're given a maximum price, there is a commitment. Now, what will happen if the company cannot deliver on-time within the defined budget? Right, you'll have to decide whenever you pay extra to finish the damn project or take the source code in its current stage and search for a desperate programmer to finish the job start from scratch.

In both cases, you're screwed.

Actually, you're screwed on three different levels:

  1. If the early estimate appears wrong, you have no other choice than to pay extra (to the same company or a third-party) if you want to give to the project a chance to be finished.

  2. If your needs changed, there are some bad news for you: you will pay extra, and then when the project fails, it will be your fault.

  3. If your budget shrinks, there are more bad news for you: you still have to pay, and you don't have a working product, but just a bunch of files with source code nobody can understand.

With Agile, it's the customer/the boss who actually decides

In an actual Agile project, things happen differently.

The CEO may decide to start a project, expecting it to be finished in six months based on a given rate per developer per week.

Three months later, he may find that it is much more important for his company to focus on a different project and to suspend the old one. Meanwhile, the old one which is on rails of Continuous Deployment represents a fully-featured product which is already used in production. Unfortunately, it lacks some critical features, which makes it not that interesting commercially compared to the expectations, but still, there are actual users who find it useful.

Two months later, it appears that the suspended project is quite a success. The number of users grow every day, and some large companies are using hundreds of licenses, which means that the income is quite impressive. With all the unexpected money, the CEO decides to throw a team of highly skillful developers on the project. They decide that the features that were not implemented yet are not that valuable, and reorient the project towards more interesting ones, based on the actual usage of the product.

One month later, the company experiences minor money shortages. The project is suspended one more time, given that the new features were released on regular basics (twice per day), and user's feedback was incorporated.