Part VI: Resources on the Net Objectives Portal
A critical aspect of the focus on achieving business agility includes identifying what is of value to build and then manifesting it in an efficient manner. Minimum Viable Products (MVPs) are a hot topic in the Lean Startup community. They have a different purpose than most of the work done by established companies. Even mid-size companies must attend to enhancing existing products that have an established marketplace. As companies mature, they usually spend a significant amount of effort rewriting software.
In general, there are five different types of work to be done:https://portal.netobjectives.com/wp-admin/admin.php?page=gf_edit_forms
Each of these types of work is done in a different fashion; therefore, it is important to pay attention what type it is.
This chapter defines two types of artifacts to be built. The Minimum Business Increment (MBI) is used when developing an enhancement to a new product or a new product to an existing customer market. The Minimum Viable Replacement (MVR) can be used for updating existing systems in increments.
This chapter looks at the challenge of correctly defining the increments to be realized. There are three concepts to help address this: The Minimum Viable Product for new products, the Minimum Business Increment for enhancing existing products and the Minimum Viable Replacement for replacing existing systems in increments.
Minimum Viable Product (MVP)
Although Eric Ries didn’t originate the term in his book Lean Startup, its meaning is now generally taken to mean Eric’s use of it. A Minimum Viable Product is a development technique in which a new product or website is developed with enough features to satisfy early adopters. The final, complete set of features is only designed and developed after considering feedback from the product’s initial users. Here is how MVPs are described in Lean Startup.
This is very useful; however, MVPs are not universally applicable.
The question is, what do you do in these situations:
Of course, in most cases, the details of functionality are rarely known well in advance. But what about the value of a product or service? In times of innovation and new products, value is not yet known. It is not clear if the product or service is even viable in the marketplace. This is where the techniques of the MVP are most helpful.
But in more established companies, there should already be a good idea about the viability of the product or service and the value of an advance. You do not need the experimental approach of the MVP. This is what the Minimum Business Increment (MBI) addresses.
Minimum Business Increment (MBI)
In the situations where the value of an enhancement or new product/service is reasonably known, the concept of an Minimum Business Increment (MBI) is more useful. It focuses on the realization of business value quickly. It is not a reason to deliver less; it is a reason to deliver sooner.
An MBI is the smallest piece of functionality that can be delivered that has value to the business in that it. Here are some features of the MBI.
MBIs are created by first determining who your target audience is. This target audience may be external or internal. Then, decide on the scenarios for this market for the business objective in question. Focus on the minimum business increment for the scenarios in question – and that becomes your MBI.
Very often you will commit to a series of MBIs as the desired functional implementation you want to do for an epic. By building and delivering them incrementally you get both value and feedback more quickly which offers you the opportunity to pivot.
This business value should be based on what represents value for the business and its customers.
Value for the business may involve paying down technical debt, achieving steps in a Lean-Agile Transformations, improving platforms for a product or anything else that the business considers to be of value. It is up to the business to identify value.
Since MBIs are focused on the realization of value and not merely on deploying a feature, they must also describe all that is needed for full value delivery. This includes what would be required for ops, marketing, support and anything else.
Finally, any adverse effect an MBI may have on existing functionality must be incorporated into the MBI about to be built and not thrown over the fence to those who built the affected code. Determining how one MBI affects another is usually the responsibility of the business architect.
An example: The MBI gets value sooner
When creating an MBI, the question to ask is, “What can I deliver soonest to get the most value?” This question has many aspects to it. It is not “smallest,” but it is “soonest.” The focus is not on the end picture when everything has been finished; rather it is, “What is the next step for value realization?”
Another focus is, “Who is the customer?” For whom are we building the next increment of value? This is especially important in those cases where there are multiple customer bases. And not all customers are the same; some are dearer to us than others. This is as true for an IT shop as it is for a product shop. Some internal clients are more important than others. The definition of MBIs is driven by looking at the market segment we want to go after.
Consider the example of defining MBIs for an internal IT support project. A financial company has had difficulty managing its help desk. A client might start the process of signing up for a new investment service and encounter one of the 22 challenges that consumed a large part of the help desk’s time. Millions are being spent on support due to these challenges.
Let’s take an example of how to define MBIs for an internal IT support project. A financial company had difficulty managing a help desk. Clients would start the process and one of the 22 challenges would come up that took the help desk’s time. Millions were being spent on support due to difficulty of clients signing up for a new investment service.
You call a meeting with the business stakeholders to find out the business value of the different options available. You wisely understand that choosing which of these many options to pursue is really a business decision and not a technology decision.
Too often in these situations, the IT shop will want to pursue technology solutions so it might be nice if they did not even come to the meeting! But of course, they showed up. Here is how they described their four-phase approach to improving the system.
This is a classic example of “system evolution.” Asked them how long it would take, they said about nine months.
You might expect the business had a different perspective. Asked if there was some subset of functionality that they would give them value they said that, indeed, addressing the first 16 challenges would give them 80 percent of the value.
So, you turn back to IT to ask them what it would take for them to build the software. just for the first 16 items. Their response? They couldn’t do that. This is very interesting because it is a smaller problem: only 16 items. Pressed on this, they admitted that while they could do it, they didn’t want to. Why not? Because there was a risk that after building a system to address the first 16 challenges, addressing the remaining six would require much more time later. They speculated that building a system to address all 22 at one time would take nine months but addressing the first 16 and then the last six would take 10 months.
They were adamant. The all-at-once approach would save an entire month! And you can appreciate their feelings. They were overloaded already and now saw the work they were going to have to do would expand on them.
What do you think? What would you do?
The real decision is whether to get all the value in nine months or to get 80% of it in six months and then get the remainder four months later. Is this a technology decision? Or a business decision?
If the goal is business agility, it is clearly a business decision. The business must decide if getting 80% of the value three months sooner is worth the cost of an extra month of development. The business answer was clearly, “Yes!”
And that’s exactly what they did. In fact, they never did address last six issues. The business decided that the return wasn’t worth it. They had other things for IT to do instead.
The purposes of MBIs
Here are some of the purposes of an MBI.
Finally, MBIs can be for internal clients, not just customers. They can focus on improving internal processes and/or tools in the organization. In all cases, the idea of validating and delivering value as quickly as makes sense from a business perspective should be followed.
We have already discussed using MVPs for new products and MBIs for enhancing existing products. Kevin Mireles has suggested another concept that is very helpful: The Minimum Viable Replacement, the “MVR.” This covers the situation faced by many large companies who spend a significant amount of their time replacing existing software. MVRs are for the increments used to replace an existing system in segments.
This does seem like a lot of terms. But it is important to avoid overloaded or ambiguous concepts. In a nutshell, MVPs focus on early adopters, MBIs focus on new functionality to a market that already exists or is somewhat known, and MVRs focus on how to control what is released. This is shown in Figure 1.
Kevin, who coined the term “MVR,” suggests another use of the MVR. If you are using a framework such as SAFe® that uses the MVP concept as the term for the smallest chunk of value to build and you do not want to adopt the “MBI” term, you can use “MVR” as a container for MVPs when doing a replacement.
Comparing MVPs, MBIs, and MVRs
Although there are many similarities to MVPs and MBIs, it is worth noting their differences.
In the customer market,
Looking at the impact to existing offerings,
Looking at risk,
An important aspect inherent in MVPs, MBIs and MVRs
Even though MBIs are intended to be used when there is something already known about the market, it does not mean that you can assume what you are attempting to build with them is known up-front. It is still important to validate the MBI by working in small vertical slices. Consider Figure 2.
System evolution refers to when the software is being built from the system perspective, typically a layer at a time. Business evolution refers to when the software is being driven from the business perspective, that is, slices of demonstrable value. If you are going to use MVPs and MBIs, you are somewhat forced to write thin vertical slices of functionality. T his is a good thing. The difference is in how we go about deciding what functionality to write. With MVPs, you are more likely in a discovery mode, whereas with MBIs, the focus is more about value realized.
Using MVPs, MBIs and MVRs together
Here is what to do. Use MVPs when you are trying to discover if something is of value. MVPs are therefore used for innovation type products. MBIs are increments of value to be realized. You should have a good sense of what this value is before even starting the MBI. If you don’t, start with an MVP and then move to MBIs. MVRs are intended when you are replacing an existing system.
Note how the distinction of MVP and MBI brings clarity by avoiding overloading the terms. In some frameworks, MVP can sometimes mean the first one is for discovery and then after that, “MVP” is no longer for discovery. This is confusing. Starting with MVP and then going to MBI is much clearer.
The method of development will necessarily be different for these three types of increments. MVPs require short cycles and, probably, small teams. MBIs can work well at all scales. MVRs can work in a manner like MBIs but are driven by an existing customer market.
There is a difference in how these are funded.
The importance of MBIs
The importance of MBIs cannot be overstated. The most effective way to lower cost of delay is to manifest value in small chunks. This also increases the efficiency of the development group. Consider the case where a team has three enhancements, each taking the same amount of time and each having the same importance. The quickest way to achieve value is if they work on one enhancement at a time, complete it, and then go on to the next. But they will very often be forced to start on all three. Figure 3 compares two scenarios of when work is done and when value is realized.
The interesting thing is that even if the Product Owners for A, B, and C know that A is more important than C, it is likely they won’t have the team do them in the optimal order. But let’s say A, B, and C can be sub-divided into MBIs. This enables the team to work on smaller enhancements and increase value manifestation even more. It also makes it easier to get the Product Owners to agree to the work being done serially. This is shown in Figure 4.
These results are even better than before. Of course, the decomposition into MBIs is insufficient. They need to be built by taking vertical, end-to-end slices in order to achieve quick feedback as described earlier.
Figure 5 illustrates how MBIs fit into the value stream from strategies to stories.
What happened to Epics?
Notice that business increments, MBI, and MVPs have taken the place of epics. Epics are not useful because they are such vague containers, and as mentioned in an earlier chapter, are not good candidates to use WSJF on. MVPs are included because they should be used when new products are being developed.
See the chapter Why Epics Are Not Used In FLEX for more information.