The Business Case for Agility

This is an excerpt from Going Beyond Lean and Agile: Introducing FLEX – FLow for Enterprise Transformation (online book). If you are looking for an alternative to SAFe, this is it. To those who'd like to study along with me as I publish this on linkedin, please ask to join the True North Consortium Linkedin Group where I will be happy to answer any questions or, even more importantly, discuss things you disagree with in the book. See prior chapter on linkedin. See the next chapter.

Introduction

Agile is often described as iteratively building software in increments. This is a focus on the team and the mechanics of how they work. It is more effective to focus on the reason for being Agile – achieving business agility. Business agility is the ability to deliver highest business value quickly, predictably, sustainably and with high quality. Building software is not our goal, realizing business value is. Software is often a component of this, of course.

Faster “time-to-market” is a well-known mantra. The common trap is to try to achieve time-to-market simply by trying to go faster. The better approach is to focus on what will truly provide the greatest value. Instead of trying to go faster, build those chunks of business value which are most important. Go smaller and focus on those value adds that contain the most value for their efforts.

We call this the “Minimum Business Increment” (MBI). The MBI is a key to delivering value quickly by focusing on the most important business value to realize. It becomes a cornerstone concept in planning and alignment.

Frequency of delivery vs. time to deliver

All too often, organizations 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.

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: Low-Risk, High-Return Development.

Figure 1 illustrates the economics of delivery they propose. This diagram illustrates how, at the beginning of a software project, the organization loses money during the investment period. After the product is released, there is a payback period and that leads to making enough money to incur profit.

Figure 1: The Economics of Responsiveness

Consider an example. Suppose you are the CEO of a company that does product development projects for other companies. 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. Here is what the RFP stipulates.

• You cannot change any of these factors. That is, all 100 features must be delivered by the date, not earlier nor later.
• They must be of the quality specified, not better or worse.
• They must take exactly the money offered, not more nor less.
• 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? Perhaps if your company had a better track record than the competition, you could win on the basis of credibility; however, let’s suppose that is not the case. How else could you compete?

Consider the rate of delivery.

For example, suppose you commit 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. What would this look like economically? Assume delivering the first half of the features cost you half the work and delivered half the value, the investment and return graphs would look something like that shown in Figure 2. Even if these assumptions are not completely correct, let’s explore this simple model and then discuss the issues that must be dealt with to make it more realistic.

Figure 2. The economics of two releases: Release 1

While you 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). Figure 3 shows the combined cost curves in Figure 2 compared with the cost curve of the single release, the net cost of the stage release is less because the return from the first, partial release, offsets the investment required by the second partial release.

Figure 3: The economics of two releases: Releases 1 and 2

Figure 4 shows the total return that is achieved. Figure 5 compares this phased return with the return from a single release. The top line is the return from the staged releases while the line underneath it is the return from the single release. The reason the investment for the staged release is less is that while the second release is being built the first release is giving us a return.

Figure 4: Total return of the two releases

Figure 5: Staged releases Vs Single Release

While this may have been a contrived example, it illustrates the value of delivering in stages – getting value sooner. In the real world, after the first release we could take advantage of what we learned and pivot if needed. The key is to recognize that the 3 dimensions often quoted: scope, cost and time leave out the dimension of iterative delivery.

Targeted markets and increased alignment

When considering the ‘Minimum Business Increment’ to select, it is useful to look at the different scenarios in which the new capability can be used. Very often each of these scenarios will have different market segments using them. MBIs can be selected on the basis of which scenarios and which markets should be targeted for maximum value delivery.

There is a powerful side effect to doing this. By creating MBIs that represent focused business value, they can be sequenced in order of importance to the organization. That is, those MBIs that deliver the greatest value soonest can be sequenced as a higher priority than those that don’t. This alignment of what is of greatest business value can also be used to align disparate teams in building things in this same order – thereby working together more effectively.

Note that MBIs are fundamentally different from epics. First, the Business typically does not know or care what an epic is. This is with good reason; for example, you can have strong feelings about a car but never care about how fuel injection works. An epic is simply an Agile construct that represents a “big story” without connection to value. MBIs are oriented toward business stakeholders and are tied to business value. An MBI, on the other hand, is an atomic unit of value and this enables it to provide deeper agreement on if and when it should be built.

The issues of staged delivery

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

Extra cost of building phased deliveries

While this is of concern to many people, building in stages does not need to cost more. 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. There are several reasons that contribute to this. One is phased deliveries can result in not building certain function that at first appears necessary, but with the feedback from the first phase, one learns it is not as desirable as first thought. Also, the use of emergent design can actually speed up phased delivery. Emergent design is beyond the focus of this book. For more information, see Scott Bain’s excellent book, Emergent Design: The evolutionary nature of professional software development.

Extra cost of deployment

This can result in extra cost in development, it does not necessarily have to be so. Making an investment in being able to release and deploy quickly is important so as to take advantage of the extra return it affords.

Extra cost of consumption

While there are some applications which users do not want updated on a regular basis, studies have shown that most users prefer small, frequent upgrades to large, infrequent ones. The salient characteristic, of course, is the level of disruption to the user. If the consumption by the user is small enough, they won’t mind it. Most objections to upgrades are due to the effort required by the user to do the upgrade.

The potential return of staged delivery

Of course, in the real world, when you can make staged deliveries, you will not arbitrarily pick half the features and release them. Instead, you would pick those features that made the most sense to deliver. This would include looking at the factors of – where’s the greatest value and what will it cost to build, deploy and consume the release. Clearly the smallest release that is useful to the customer and worth the incremental cost of building and deploying is what you should do. We prefer to call this the “Minimum Business Increment” or MBI. Others have used the term Minimal Marketable Feature (MMF), Minimal Viable Feature (MVF), and Minimal Viable Product (MVP).

These are not just name changes. They also indicate intent of the phase. Eric Ries talks about MVPs as a way to test the market – both to see if your product is viable and to gain quick entry. While we talked about how the return curves for a phased release may not be as good as illustrated, there are some other considerations that may make them considerably better. In a highly competitive situation, for example, whoever gets into the marketplace first may capture it.

In this extreme case, gaining entry into the market three months before our competition may enable our client to own it. Coming in two months after their competition may be an effective barrier of entry. Another advantage is that customers will be able to provide greater feedback to improve the effectiveness of the subsequent phases of delivery.

Sidebar: MMF vs. MVP vs. MBI

This concept was originally called a Minimum Viable Product by Frank Robinson introduced it as a Minimal Viable Product in 2001. Denne and Cleland-Huang reintroduced the concept in 2005 but called it a Minimal Marketable Feature (MMF). Many IT groups we worked with objected to the term “product” and “marketable” saying they didn’t market products. We eventually set on the name “Minimum Business Increment” because that’s more descriptive and works for all types of organizations.

The idea of the MVP, MMF and MBI is to delivery value quickly. Let’s see why this makes sense.

Lowering risks in development

Tie biggest risk in software development has long been building the wrong thing. Or overbuilding the right thing (which basically means some of what was built was right and some of it wasn’t as useful. MBIs enable a new type of evolution of products which can dramatically lower the risk of building features of little value.

Systems evolution

Many applications are built by layer. First a framework is built and then different layers are added until it is complete. We call this “system evolution.” This is shown in Figure 6.

Figure 6: Systems Evolution

In system evolution the system is built in phases, one on top of another. These can be done in parallel as well but until all phases are done there is no value.

Business evolution

In “business evolution,” you deliver increments of value as soon as possible. This is accomplished by using MBIs. The purpose of staged deliveries is to deliver real value sooner and to stop delivering when enough value has been delivered. Business evolution delivers a series of business increments as shown in Figure 7.

Figure 7: Business Evolution

Business evolution has several advantages over system evolution:

• Value is realized sooner
• Customers get to provide feedback quickly on what they want
• The development team an take advantage of what they learned from early releases
• Releases of a new product can be delayed when enough value is achieved
• It lowers the risk of spending significant effort on work that does not produce value

The second advantage regarding customers is significant because customers often don’t know what they want until they see something. Or as someone once told me, “after they see what they don’t want.”

Lowering risk

In both types of evolution it is possible to build the wrong thing. But let’s look at what happens in each of these cases. Figure 8 shows what happens if the wrong thing is built at the end.

Figure 8: Return when building the wrong thing with systems evolution

Business evolution does not guarantee that the wrong things won’t be built. But if that happens, it will be discovered much earlier, as shown in Figure 9.

Figure 9: Return when building the wrong thing with business evolution

Comparing the risks of the two methods

Consider the risks of the two methods. The potential risk curves of both methods is shown in Figure 10. In Figure 10, both approaches start with the same risk and both end with no risk. That is, when it is finished, everything is finished and there is no more risk involved. Consider the risk curves of the two approaches. Does it start out high, stay high until the end? Or does it go down at a steady pace over time? Or does it go down quickly?

Figure 10: The possible risk curves for system and business evolution

The risk of system evolution is that you do not get good feedback from the customer until the very end. This risk is not only from building the wrong thing but either over-building the system or even building the architecture for the system incorrectly. However, with business evolution, you find out early if something is going wrong. The risk goes down significantly with the first release. See Figure 11.

Figure 11: The actual risk curves for system and business evolution

Opportunities and the need to lock across products

The focus that XP and Scrum have between the team and the customer is appropriate when teams are independent and only work in one area. In larger organizations 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.

To understand this, you need to consider different possible rate of returns one can have on projects. The ideal case is what is called the “Pareto curve.” This occurs when 80% of the value is achieved by doing 20% of the work. The challenge is that product owners are tasked with continuously building the product they are responsible for. With system evolution there’s a tendency to build all that has been asked for. But with business evolution the product owner can see if most of the gains have been achieved and that a new project should be started. For example, in Figure 6, it would likely be that another project should be worked on after the fourth release.

Although customers who are using this product may want you to continue working on this, you 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, you may want to look for other products that will give 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.

Looking forward in this way 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.

Of course, not all products give such a Pareto return. Many give fairly linear results – each release providing an amount of value pretty much in line with the effort it took to achieve it. Some product enhancements return value relatively quickly; others take a few months to build. You want to avoid long delays in realizing value simply because you did not consider the potential of incremental business delivery.

The Lean Startup movement

It is worth taking some lessons from the Lean-Start up movement here. I’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. The Lean Startup approach using Minimum Viable Products (MVPs) is a different, albeit useful, tact on incremental business value.

Both MBIs and MVPs have the same heritage of Denne and Cleland-Huang’s MMF. Having both in your arsenal of tools can be quite powerful. But it is important to know the difference. MVPs as described in Lean-Startup are designed for startups and focused around the discovery of new product value. MBIs are designed for all companies of any maturity and is focused on increasing value realized by the business. Both allow for pivoting as discovery of the true value of the product is delivered.

Using lessons from the Lean Startup

The essence of the Lean Startup is to validate what you’re doing. This not only pertains to deliveries but can also apply to getting feedback on work that is not or cannot be released. It is important therefore to always create work in small slices that can be shown the product owner and feedback received even if the work done can’t be released. This is illustrated in Figure 12.

Figure 12: The system evolution vs business evolution

If you want to learn more about FLEX you can take an online course at the Net Objectives University or take a live course in Orange County, CA May 6-8 or in Seattle in June (both led by Al Shalloway). If you want to learn about how to adopt FLEX in your organization please contact the author, Al Shalloway