Taking hostages with Waterfall
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 determines 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, the project should be released in September, with all the original features.
January 2014. The project is at its early stage. The boss is fighting and screaming and blaming. The release date is then rescheduled to the beginning of February 2014. “We simply cannot release it later than that!”—tells the boss to the manager, and the manager repeats it to the developers.
March 2014. The project is rescheduled to be delivered in two weeks. Actually, it it is scheduled to be delivered “in two weeks” for more than a month, and since we're 90% done—the precise metric based on the fact that we already shipped zero 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 yells at the manager, sets another date, and becomes one more time confident that now, 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 was then cancelled by the CEO. The IT company refused to give even a partial refund, explaining that they did everything they could for the success of the project, and even 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 start looking for a job in a different domain.
The old good Waterfall
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. It can be completed in six months and cost $160,000. Or twelve months, and $320,000.
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 a hostage of the company which develops the product.
If you're given an estimate, there is no commitment from the software development company to actually follow it. 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, this 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 project or take the source code in its current stage and search for a desperate programmer to
finish the jobrewrite the whole thing from scratch.
In both cases, you're screwed.
Actually, you're screwed on three different levels:
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.
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.
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.
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 project remains in a working state, and is already used in production. It possibly 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 buying 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 basis (twice per day), and user's feedback was incorporated.
If a project is managed like that, there is no way to become a hostage of a company which haven't finished the product and is asking for more money. Simply because you're expecting to see the actual product within weeks after the work begins. If the company is unable to deliver, you'll have enough time to stop dealing with the company, and go find another one.
Waterfall and similar models make sense in very narrow fields, for very specific projects. Some life-critical systems don't fit well the Agile model, but, once again, those are rare exceptions. For all business software, Agile have shown time after time its superiority, and it is even more valuable for companies where software development is delegated to another company—one one side you keep keep leverage over what the other company does; on the other, you become a hostage, with no power of deciding how much would you pay, or how long would it take to release a product.