Get your FREE 30-day trial.
Please complete all fields.
For years, IT teams in medium to large enterprises released updates to applications in large batches with the belief that this is more efficient, less impactful, and a better return on the investment. Because we believed this, we built processes, compliance checks, architecture guidelines, and measures to support the large sized, complex releases. But this belief is incorrect.
Since the inception of the Agile Manifesto in 2000, there has been a renaissance in the way we view application development. The Agile way of thinking with significant influence from Lean, shows us that large batch sized releases actually has a negative effect on the return of investment (ROI) in software.
When we break down how ROI on software is recovered, we begin to see the problems with large releases. Large batch releases happen when we decide to delay the release until all features are developed. This delays the ability for consumers to actually use the application for their business purposes and make it useful.
This is illustrated in figure 1. The point in time, Rm, when we push the full batch to production is the first point that value is generated. That value continues to generate a return over the life of the application. In our illustration, we've used the one year mark, Rm + 1 year, to represent the end-of-life. Only after the release do we begin to recover our investment in to the application.
However, there is a problem with this large batch approach. From the first day we kicked off the project, our teams were building features that would generate value. This is fine for the features that were developed in the last two weeks before the software was released. But the features that were completed in the first two weeks waited in the ready-to-deploy queue. Holding these features in the queue requires maintenance and tracking which adds costs to project. These costs are known as holding costs.
More importantly, these features are not accessible to the users to start generating value. If they are not generating value, we are not building ROI for that feature. Instead, that feature is losing the opportunity to bring us a return while waiting in the queue.
Small batch releases change the ROI outlay by increasing the future value payment schedule. When we looked at the simple ROI example for a major or big-bang release we saw that it was only after the full development, testing and deployment life-cycle did we start recovering on ROI. But what if we released smaller batches more frequently? What impact does this have on ROI? We will reduce the additional project costs that come from tracking and queuing features that are ready for production but not released yet. But will our ROI improve?
Instead of waiting to release the product all at once, let's move the features into production as soon as they are ready. In our example, that is six small batch releases occurring rapidly. We see that the total project cost aspect the same when we aggregate the cost across all of the smaller releases.
While the simple graph does not accurately show it, we can assume that small batch releases and large batch release required the same amount of engineering effort. Therefore, by the time R6 is released to production, we have the same number of features in production at the same cost. We also see that at R6, we can begin recovering our full investment like we saw with the classical or large batch release example.
The difference with the small batch release is we have an accelerated investment recovery schedule for R1 through R5. When we release the first small batch at R1, our consumers get value out of what we released immediately. They don't need to wait till R6 before they can use any of the application. This results in improvement in our organization and ROI for our efforts.
When we look at it over six releases, we find that we are getting incremental recovery of our investment. It's only the small set of features at R6 that are not returning value over the life of the project.
While this is a simple illustration of the ROI improvements from releasing small batches earlier and more frequently, the principle applies to real world enterprise application development. In fact, the addition of holding costs and transactional costs incurred during product development strengthen the case for small batch releases.
Transaction costs are the labor and effort of moving developed features through system, integration and user acceptance testing. In Donald Reinertsen’s book The Principles of Product Development Flow, he calculates that transaction costs are 2 or 3 to the power of x where x is the number of features being released.
The more time between releases, the more features are created and placed in the 'waiting to be accepted and deployed' queue. With every incremental feature, there is an increase in the complexity of the release. Experience from 25 years of enterprise software development has shown the exponential increase in complexity with lager release batches.
All of these factors exponentially contribute to transaction costs. However, transaction costs are not recoverable from ROI. The application's consumers do not get direct value from executed tests. From their perspective, this should be a given of the application. We only earn a return on our investment from the features the customers can use to solve their problems.
Larger batch releases not only delay the incremental return on each feature that is developed but in reality has a negative impact on the ROI of the application. The increased complexities both in the application, deployment, and the planning adds costs to the project that cannot be recovered.
