People, unfortunately, do the same thing. It is this instinct that has allowed us to live through the years of the cold war with its danger of total nuclear annihilation without dying from the stress induced by the risk. Whilst it is a great survival trait the ability to ignore the stress caused by seriously risky situations can be an expensive problem in business.
So it’s not really our fault that we tend to ignore the fact that somewhere between 70% and 95% of all software development projects are a failure in one way or another. Its our genes telling us that this high-risk situation is actually not a real problem, and that if we ignore it and keep still it will go away.
If we examine the risks of project failure, examine the causes, then we will see that there are things that can be done to reduce the risk. Now, this is a big step, because it means that we’ll have to lift our heads out of the sand, and admit the truth.
If you have a one-year project, for argument’s sake costing $50,000 a month (that’s about six Java developers) and it’s cancelled after nine months, it is likely that the business commissioning the work will have wasted at least $450,000.
What if that same project released working software every three weeks of its life? The business will have had a working system only a few weeks after the project was initiated. Admittedly the system would have very little functionality, initially, but the functionality would grow every three weeks. How much would the business have lost if the project were again cancelled after nine months?
The business will have lost a maximum of around $35,000, this being the cost of three weeks work. Now, please compare these losses. Same project, same cancellation, one loses $450,000, the other loses $35,000. Which would you rather invest in?
Further, these projects could be funded in three-week chunks. No need to invest $600,000 in a project ever again. Invest $35,000 instead, and if you like the results invest another $35,000 three weeks later. Repeat until you consider the return on the investment to be of less value than the investment capital, and then stop; that’s the end of the project.
There are other benefits of this rather extreme release schedule too; early release. If the business runs a successful one-year project they’ll get the software at the end of that year, and at that point they’ll hopefully start to recover a return on their investment. That is, return begins after the project is complete.
In our extreme scenario we’ll produce a working system, with hugely reduced functionality after only a few weeks. This will enable the business to gain benefit from that software immediately, and therefore begin to realise return on their investment immediately.
Imagine it, not having to wait until the end of a project to get your hands on a working system. This means that you can use the software immediately for your benefit, but also that you’ll rapidly gain a better understanding of how this software will affect your business. You can then take this understanding and feed it back into the project, which will use it to produce even better software.
You are going to have two arguments against this. The first is that it can’t be done, and the second is that your business needs a rather significant subset of a system’s functionality for the system to be at all useful.
In both cases you are wrong.
First, it can be done. It has been done. Many times, on many projects. Your developers can be trained to do it to. A three-week release schedule isn’t even that extreme; most XP projects could release daily, but we don’t think that anyone could keep up with us.
The answer to the second argument is adaptability. Businesses are adaptable, even if you think that yours isn’t. The reason it seems that they need a significant subset of functionality is because this is how we’ve trained them to see the world. All you need to do is retrain them, and they’ll adapt. Of course, retraining them is difficult, but if you’re going to develop agile solutions, rapidly, and with low risks, then you have no choice but to retrain the business.
Offer your business the facility and they’ll work out how to use it.
This three-week release schedule is one of the practices of XP. To support it you need the other practices too, such as test-first-design, merciless refactoring, constant integration, on-team customer and the planning game.