At last weeks course on Agile Project Leadership I was asked a very interesting questions about the profitability of Agile development and how to convince Management it’s a good idea to release early and often. The argument made was, that there’s always cost associated with releasing to production and therefore more releases is more costly than fewer releases. The cost can be related to marketing, education, documentation, deployment to production etc.
To answer this question we walked through the fictive case below, which I however think is a fairly realistic scenario and not surprisingly it proves that multiple releases can generate a significant better ROI (Return on Investment) than a traditional one release strategy. There was however a surprisingly finding, but let’s not spoil the fun just yet.
The Case
A company has a three-year window to make money on a specific set of features. The expected monthly revenue when the entire set of features is released to production is 300,000. Development time is estimated at 12 months at a cost of 250,000 per month. The cost of each deployment is 100,000.
One Deployment After 12 Months
Using a traditional waterfall approach the company develops the entire set of features before releasing it to the market after 12 months. In this case they would spend 3,000,000 (12*250,000) in development cost plus an additional 100,000 in deployment cost before they get any return on investment.
To make matters worse, they would have spend the first of the three-year window developing the application, which would leave them with only two years to cash in on the investment. The expected revenue could therefore be calculated as 24 month times 300,000 totaling 7,200,000. Subtracting the development and release cost of 3,100,000 would give a total return on investment of 4,100,000 (132 %).
The graph below shows the cash flow in the one release scenario.
But What If Features Are Split Into Multiple Releases?
Apart from all the other benefits from releasing frequently, such as real feedback from the environments and the users, there is also significant financial benefits to be gained.
Releasing early means releasing only a subset of the features and therefore only getting parts of expected revenue until the entire set of feature is released. However using Agile prioritization techniques ensure that the highest valued feature are released first. In the case above it’s estimated that the company could produce features generating 130,000 of the total 300,000 expected revenue during the first quarter, 90,000 during the second, 60,000 during the third and 20,000 during the final quarter.
Splitting the Features In Two Releases
If half the features were to be released after six month and the rest an additional six months later, then the numbers would look like this.
During the first six months the company would spend 1,500,000 on development plus 100,000 on deployment. The same goes for the second half of the year bringing the total development and deployment cost to 3,200,000.
Adding the additional 100,000 in cost (the extra deployment) would mean that 50 % of the features would start generating revenue after six months. Since the company prioritizes the highest valued features first, the first release would generate 220.000 in revenue after six months and an additional 80.000 after twelve months when the rest of the features are released. Compared to the one release strategy, two releases would generate an additional 1,320,000 (6*220,000) in revenue at a cost of an extra release (100,000).
But What If We Do More Releases?
At some point the cost of releasing will exceed the benefits gained, but even if you reach a break even from a financial point of view, you still get all the other benefits from releasing early and often.
In the graph below you can see the effect from splitting the features into two (calculated above) and four releases. In the later case the benefits from releasing features generating 130,000 in revenue already after three months and an additional 60,000 after nine months would still outperforms the 200,000 in additional deployment cost.
And Now For the Promised Surprise
In traditional software development thinking we believe we have to develop the full set of features before closing the project. Many contracts still reflect this fact without considering the cost/benefit.
Using Agile prioritization, planning and feedback techniques the company in this example would realize they would only generate an additional 480,000 (24*20,000) in revenue per month from the least important features to be developed during the final quarter. Unfortunately it would take the company an additional three months to complete the features (at 250,000 per month) plus cost an additional 100,000 to deploy them. As shown in the graph below the impact of skipping the final release would therefore be a saving of 370,000. The graph below shows the effect of skipping the final release compared to the other scenarios discussed.
Higher Return On Investment
In this case above skipping the final release and releasing the most valuable features quarterly resulted in a total revenue of 6,060,000, which is a 237 % return on the total investment (2,550,000 – 9 months of development and three releases). That’s an increase in revenue of 1,960,000 or almost 50 % compared to the one release strategy.
The numbers above should convince you (and your skeptical boss), that delivering early and often makes good financial sense. But there are even more financial benefits to be gained from releasing early and often.
First of all a company releasing early and often will have significantly less cash invested in development at any point compared to the one release approach. With the four or drop the final release strategies in the example above, the company has never more than 1.5 million invested in development compared to the 3.1 million in the one release approach. This means that the company could potentially double production capacity without taking a bigger investment risk.
Secondly the break even on investment improves significantly. In the one release scenario the break even would be 23 months compared to 14 months in the drop the final release scenario. If the market suddenly changes because a competitor releases new superior features or a new technology changing conditions, then you are more likely to loose money with a longer break even time.
Thirdly skipping the final release frees up the development team to work on other things. What if they could start a new similar project three months early and release the first set of features worth another 130,000 in the same time frame as they would have released the features worth 20,000?
In a scenarios like the one above frequent releases are a slam-dunk. Financially they are a no-brainer and in addition you get a lot of valuable feedback from the market and decrease risk. But what is your experience? Have you experienced increased RIO from releasing early and how hard was it to sell to management?
