Agile is often described as iteratively building software in increments. It is more effective to think of it in terms of being the incremental delivery of business value. Software by itself is not useful. Software that helps deliver business value is. The focus should be on the value to the business, not on the software. While we all know the importance of “time-to-market,” investigating how this relates in the software arena is particularly useful.

The Business Case for Agility

The business case for Agility revolves around value in time, like so much else in business. How can we speed delivery of value to those who are waiting to receive it?

Shorter Lead Times

We are all too familiar with companies that cannot deliver value quickly. While deliveries may take place on a quarterly basis, the work being delivered has often been under development for a year. The issue is not how frequently you can deliver but rather what is the time frame from start to finish. This is called “Lead Time.”

Delivering in Stages

Mark Denne and Cleland-Huang put forth some compelling arguments for quick, frequent delivery in their book, Software By Numbers. At the beginning of a software project, you lose money during the investment period. After the product is released, you enter a payback period and hopefully go on to make enough money to incur profit.

Delivering in stages means that your costs are less since you are doing only delivering part of the features and you are delivering part of the value sooner. The customer begins to realize value sooner and your payback period begins sooner.

Of course, it is not as simple as this. Building the software in stages may take more effort than building it in one pass. Furthermore, two deliveries may cost more as well as be more disruptive for customers. These factors would all take the return curves down by adding more cost. However, there are some other factors that might vastly increase the return curves.

Does Delivering in Stages Involve Extra Costs?

Development costs. It does not necessarily have to cost more to build and deliver in stages. If you are extending a legacy system that has large amounts of technical debt and is difficult to test, then multiple deliveries may, in fact, cost more. But if your code quality is good and you have automated tests, it often costs less to build and deliver in stages. See Scott Bain’s excellent book, Emergent Design: The Evolutionary Nature of Professional Software Development.

Deployment costs. At the beginning, it can cost more to deploy. Making an investment in being able to release and deploy quickly is important so as to take advantage of the extra return it affords.

Costs of consumption. While there are some applications which users do not want updated on a regular basis, studies have shown that users often prefer small, frequent upgrades too large, infrequent ones. The goal is to minimize the level of disruption to the user.

Use Minimum Business Increments to Increase the Returns of Staged Delivery

When planning staged deliveries, you won’t arbitrarily pick half the features and release them. Instead, you select those features that make the most sense to deliver: what can offer the greatest value to customers for the least cost to build, deploy, and consume? The smallest release that does this is called the “Minimum Business Increment” or MBI.

The Need to Look Across Products

The team is focused on delivering value to a customer. Budgeting and planning has to take into account what will deliver value to the customer. And what is required for existing systems. This opens up the opportunity for better product portfolio management. You can pick those features, regardless of which product they are for, that produces the greatest value to the organization.

Lessons from the Lean-Startup Movement

It is worth taking some lessons from the Lean-Start up movement here. We have been discussing return of business value of mostly established products. The Lean-Startup movement suggests delivering business value incrementally in order to determine which products actually have value. In other words, delivering part of a system that may not be complete yet but which will provide some value to customers while indicating how much value the product can eventually provide is a useful consideration.

Summary

Agile, implemented in MBIs, puts the focus of programs on the business value they deliver. Agile at scale takes us firmly beyond traditional Agile by addressing the need for a more global idea of what “value” is to the enterprise. This requires both the atomic focus on MBIs, as well as a broad focus across all the enterprise’s programs.