In Lean-Agile Clinic
Join the Discussion
Everyone knows intuitively that needless delays in software delivery impose some economic cost on the organization. But what exactly is that cost, and how do we measure it? Applying a combined Lean-Agile perspective, we can understand these costs better. More importantly, we can use the same perspective to improve the speed and reliability of software delivery, while making important choices about when you’ve delivered enough value.
Focus Your Organization on Avoiding Cost of Delay
At a gut level, delays in software delivery make everyone uncomfortable. However, for the leaders and managers of software innovation efforts, a gut feel is not enough. Not only do they need to mobilize their organizations to meet their commitments, but they also have to answer for delays to their own higher-ups. The mere fact that something is late doesn’t necessarily mean that it doesn’t have value; however, the degree to which the delay diminishes its value isn’t altogether clear.
First, You Need Some Targets
Before you can solve this conundrum, you need to demand that software innovators have a measure of value in the first place. The economic target will vary, based on the product or project. In one case, customer retention might be the goal. In another, it might be market expansion. In any case, you need to start with some definition of the economic impact that delivering the software is supposed to achieve.
It’s important to be precise, for a couple of reasons. Organizations are dumb beasts, and ambiguity usually leads to confusion and inertia. Additionally, unless you have precise measures of success, it will be extremely difficult to divide them into intermediary goals, each of which can be the rationale behind a separate release. (More on the strategy of smaller, more frequent releases in the next section.) And third, you need to provide some clarity on whether adjustments are needed. If the goal is vague (for example, “Generate more business”), then people working on the software might conclude falsely that the progress towards that goal is sufficient.
Next, You Need Shorter, More Frequent Releases
Shorter, more frequent releases are critical to success, for many reasons:
Clarity about the expected economic benefits of each smaller release is just as important as clarity for the overall economic target. For example, the goal for the first release of the mobile app might be, “Reduce customer support calls by 5%,” which is a small piece of the overall goal for the app, a 50% reduction of customer support calls. If the initial release fails to meet the 5% goal, or exceeds it substantially, you have a firmer basis for making adjustments than if no clear goal existed for that release.
Finally, You Can Assess Cost of Delay
This short article won’t go into the precise calculations for cost of delay. Instead, it’s enough to say for now that the cost of delay is something that you can calculate, based on the approach that we have described. If you expect the number of customer support calls to diminish by 5% after the first release of the mobile app, you can assess the cost to the organization, day by day, of not releasing the app when planned. This cost of delay presents people in the software value stream with a clear economic imperative that should be guiding their actions, instead of a less compelling commitment to a project management outcome.
Calculating cost of delay will also make clear the different patterns of value realization, across products or projects. While some may realize value very early, others may need more time to produce substantial value. Software innovation strategies can adjust to fit these different value curves. For instance, while one team might work very hard to meet the first two releases, another team might be more concerned about later releases.
Cost of delay is an important metric because it focuses attention on the right question, When and how are we realizing value from our software innovation efforts? It also leads to a smarter release strategy, many shorter releases instead of one expensive (and risky) moon-shot. Agile gives teams the ability to release more quickly and reliably; Lean provides a larger framework for not just the team, but the software value stream overall, to be more value-driven.