By Andy Brandt
My outsourced software development company is based totally on the agile approach. We work in Scrum and have come to regard it as a natural approach to managing requirements, releases, and changes in a project. However, most prospects and clients we talk to are not as familiar with agile development. And almost all of them ask for a fixed bid on any project they want to build. They collect the bids, choose the best contender (usually taking the lowest bid), order the project, and then go away for the duration of the contract, hoping to get a working system in the end. More times than not, what they end up with is a half-finished system not fit for release. They then have to start over, this time stressing that they want an accurate price.
We don't work like that. We believe that fixed bids are a bad idea when it comes to software. First of all, you'll never get an "accurate price." Developing software, especially new systems built to individual needs, is a creative, inventive process. It is not possible to accurately say how long developing “Feature A” might take. It is possible to make a prediction, an estimate, but it's just that—an estimate. This is especially true when you consider the amount of information about each feature that is typically available at the project start.
Every software developer knows they can't accurately predict how long a particular feature will take, so they guess. There’s nothing wrong with that. The problem starts when this guess is presented as solid reality, which is exactly what happens in a typical bidding process. Since each company knows there is a risk in their estimates, they compensate for it by overestimating. Industry standard for security margin on estimates is somewhere around 25 percent, which shows how inaccurate they typically are. In any case, what you get as a bid is in actuality a guess, bloated by some margin so that the developer feels safe they won't lose money if things go wrong.
Let's say someone tells you a project will cost $25,000. We all know that in the end it might cost $24,998 or $25,231 but it won't cost exactly $25,000. In fact it's more likely that it will cost either $20,000 or $30,000. In the first case, you lose $5,000 in money or features that might have been developed. In the second case, you’ll receive an inferior project. Why? Because if the project is over budget but a contract is on a fixed price, every sane company will do all they can to limit their losses. In other words, they’ll finish the product as quickly as possible—just kick it out the door, the sooner the better. In software, kicking it out the door usually involves developing poor, undocumented code, solving problems via quick hacks rather than elegant solutions, and reducing testing to the absolute minimum. To further reduce costs, the company may replace senior developers with interns, working overtime. If, heaven forbid, not only the price but also the deadline was fixed and penalties apply, the software company has an even bigger incentive to lower the quality to limit losses. That’s one reason so many IT projects (be it software development or deployment) end up disappointing clients or failing altogether.
Another reason fixed bids are bad for clients is because the bidding process by its very nature requires the scope to be fixed as well. That means clients have to provide all the features they might ever want from the development team upfront, before any development starts. Many clients start by writing a list of everything they want from the envisioned software system. There is nothing wrong with writing that list; it is a very helpful effort. What is bad is fixing it, making it carved in the contractual stone. Why? Because you write this document thinking that if you forget to put something there you will never get it. Result: you end up putting many things there which are not needed, the “nice-to-haves.” Worse, you won't put there many things that will be needed only because you haven't thought of them yet. And you haven't thought of them yet because those ideas will occur to you only after you will start using the software, even in an early version. In other words, writing a fixed scope document and then freezing it by making it a part of a contract means trading many useful but yet unknown features for many nice-to-haves or things that no one will use.
Agile companies do think long-term planning is a good thing, but we don't sell the illusion that a plan is anything more than it is. At my company, we fix quality and release dates (every iteration, usually two weeks) and we fix the price of each iteration before we start that iteration. We don't fix scope and we don't fix the total price for the project. If a client has a great new idea two months into the project, that's fine; we'll just implement it. If by fourth month a client decides that what has been developed is enough - that's fine too; a client can end the engagement at any time. Agile companies offer flexibility that traditional development based around static documents can't match. Most offer services at a set, negotiated price. We'll build as much as possible at the best quality for the amount a client is willing to spend on the project.
One last thought: with an agile team you'll never be left with a heap of code that can't be used for anything except showing it around in hope someone will finish it. Why? Because at the end of each iteration you get a new, complete product release that is 100 percent tested and 100 percent functional. It might not contain all of the features you ultimately desire. In fact, the first release (two weeks after the project starts) probably won’t do much at all. But those features that have been finished to date are indeed done—fully working, fully usable. From the very beginning, you have a working software system that is upgraded every two weeks with new features. You're never held hostage by the development team: you own the code and you have something that is useful. The best part is that you decide which features are most important *now* and should be delivered in the next iteration. Flexibility, customer involvement, and working software. Now there’s a recipe for success.
Thanks to Paul Klipp whose podcasts on selling agile software development remain a source of inspiration. Many ideas for presenting the merits of the agile approach used in this article are based on those podcasts and discussions during our meetings with Paul.
