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.

This article introduces the business case for Agility, the notion of the “Minimum Business Increment” (MBI) and why it is so important. It discusses some other variants of the MBI. It also points to the need for a high-level concept of overall value to the business, to complement the idea of value to the customer.

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 one delivers, but rather what is the time frame from start to finish, also called “Lead Time.”

Delivering in stages

To set the stage for incremental delivery of business value, it is important to understand why this is so beneficial. 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.

For example, suppose you are the CEO of a company that does product development projects for other companies. And suppose you have received a request for proposal (RFP) that requires 100 features to be done in 10 months with a certain amount of quality and that the price is fixed. And suppose the RFP stipulates that you cannot change any of these factors. That is, you need to deliver all 100 features by the date, not earlier nor later. That they must be of the quality specified, not better or worse, and that you must take exactly the money offered, not more nor less.

It sounds like all of the factors in the iron triangle have been specified: scope, time and cost (with quality being thrown in as well). How could you win such a contract?

Assuming your company has a more envious track record than its competitors you might win on the basis of credibility, but let’s imagine that is not the case. Although it seems that all factors have been specified, there is another that is not; the rate of delivery.

For example, if you have committed to delivering 50 features after five months and the other 50 features at the 10 months. you are complying with the requirement to deliver 100 features after 10 months; you are just delivering some earlier. Delivering the first half of the features costs you half the work and delivered half the value and begins to return income and feedback.

Now, we cannot always do this staged release scheme, most software can be delivered in increments. For example, ignore the factors of extra development time for a staged release (which would make the cost curves deeper) as well as extra delivery and consumption costs for a staged release (also making the cost curves deeper).

Delivering in stages

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. However, we’ll deal with these increased cost considerations first, before discussing other potentially even greater advantages to phased deliveries.

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.

Funding as long as value is returned

It may be that the first release gives great return and each subsequent release gives us less and less in return. Although customers who are using this product may want us to continue working on this, we run the risk of missing opportunities for other products that can give a big return on its first release. In other words, instead of getting the tail end of the Pareto curve, we may want to look for other products that will give us a big return for relatively little effort.

We often see budgeting errors in this situation. Many times companies continue to provide funding for established products because they follow the logic of basing budgets along the lines the returns are occurring in. In reality, budgets should be made along the lines of what future returns would be available. Of course, one must consider what will happen to existing systems if one does not continue to enhance them at all. But even this is looking at investment on the basis of future returns, not on past laurels or on the idea that a team belongs to a customer.

Opportunities and 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.

XP and Scrum provide a concentrated focus between the team and the customer. This can be taken too restrictively though. While at the team level this focus is appropriate, it has always implied a myopic view that the focus is on the customer and the team. In reality, a broader view is needed. Within that broader view, the focus of the team to the customer is good, but when the context within which this exists is ignored this focus can be problematic.

The Lean-Startup Movement

It is worth taking some lessons from the Lean-Start up movement here. We’ve been discussing return of business value of mostly established products. The Lean-Startup movement, however, 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.