Why We Need More Than MVPs

Transcription

1 w h i t e p a p e r Why We Need More Than MVPs by Al Shalloway INTRODUCTION 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: Creating new products in new markets for early adopters Enhancing existing products either to improve functionality or expand markets Creating new products for existing customers whose needs are reasonably known Replacing existing software Maintenance issues (such as bug fixes) 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. THINKING INCREMENTALLY Two challenges when using SAFe are sequencing work to be done and correctly defining the minimum increment to be realized. When it comes to sequencing work, SAFe recommends a version of the Weighted Shortest Job First (WSJF) which uses a single number for business value. The problem with this is that business stakeholders often need to express business value using several metrics. They have a more nuanced and realistic view of what creates business value. The next chapter offers a better approach for WSJF that accommodates these needs. 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. The Minimum Business Increment was introduced in the previous chapter. The MBI is perhaps the single most important concept in Lean Portfolio and Product Management. We started calling it the Minimum Business Increment (MBI) since it is not tied to whether it is a product or a service. The idea for the MBI evolved from the concept of the Minimum Viable Product (MVP). Let s look at the MVP first and then move to the MBI and then conclude with a quick sketch of the MVR. Minimum Viable Product (MVP) Although Eric Ries did not 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. Used for developing products for early adopters by focusing on learning what they want Geared toward startups Designed for the first time a product/service is released Usually built by a small team that can already pivot This is very useful; however, MVPs are not universally applicable. The question is, what do you do in these situations: You are an established company. You are building enhancements to an existing product/service. The teams required to build it are not aligned and don t work together well. CONTACT US info@netobjectives.com LEAN-244 ( ) LEARN MORE portal.netobjectives.com Copyright Net Objectives, Inc. All rights reserved.

2 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) The Minimum Business Increment (MBI) is like an MVP but has an intense focus on the realization of business value quickly. Minimum does not mean delivering less; it means delivering 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. Adds value for the customers of the business Provides valuable feedback that the right functionality is being built Provides valuable feedback that the functionality is being built the right way Provides functionality that can be verified as an increment that can be delivered Enhances the ability of the organization to deliver value in the future 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. Of course, 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. 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. Set up the plan Modify the enterprise database as needed Improve the application's workflow Automate the straight-through processing of the enrollment 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 per cent of the value. So, you turn back to IT to ask them what it would take for info@netobjectives.com LEAN244 ( )

3 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 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. Provide an early descoping to high value. By doing this the organization can focus on manifesting the most important value. Smaller pieces are easier to manage. It is as Eli Goldratt, the creator of the Theory of Constraints, once said, Often reducing batch size is all it takes to bring a system back into control. Smaller pieces can be delivered more quickly. And, by focusing on the high-value pieces first, descoping early helps you avoid spending time on items of lesser value. Ensure completeness to realize value. MBIs contain all the work that is required to realize value. The scope of the MBI includes non-development aspects of value realization such as user documentation, market support, ops and others. MBIs create the visibility throughout the entire value stream and provide clarity for DevOps as well. Enable the ability to sequence the list of work to be done while attending to shared services that are likely constraints. This also enables avoiding starting work until you have the capacity to complete it. Provide clarity of what to align around. All parts of the organization should be working towards defining, implementing, deploying and allowing for the realization of the most value as defined by the business stakeholders. MBIs assure that at all levels, scope is always constrained by a focus on faster realization of value. Of course, when MBIs are initially defined, they represent the minimum chunks of business value that can be realized. But then, as the MBIs are decomposed into features and stories, the scopes of the features and stories are limited to that of the MBI. And this means building only build is needed to realize value. This contrasts markedly with most Agile methods of decomposition which start with epics and then pull the most important features out of the epics. While this does limit scope, the features are often built fully scoped instead of limiting them to a more focused target audience or purpose. MBIs help to manage WIP. WIP is often thought of as the amount of work actually being worked on. But if a feature is started, then that entire feature is work in process. Same for an epic. MBIs have an influence on the amount of WIP because teams know they need to focus on finishing all of the stories in a feature and all of the features in an MBI. Plus, the features and stories are smaller since they are just implementing the part of the feature needed for the MBI. MBIs therefore minimize WIP by being smaller to begin with, having smaller pieces be decomposed from them (features and stories) and providing a higher view of what to finish. 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. The Minimum Viable Replacement (MVR) 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. info@netobjectives.com LEAN244 ( )

4 Figure 1. How MVP, MBI, and MVR relate 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 (see Figure 2). 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. COMPARING MVP, MBI, AND MVR Although there are many similarities to MVPs and MBIs, it is worth noting their differences. In the customer market, MVP: you are creating a new product for early adopters MBI: you are extending an existing product to a new market segment or extending the product to an existing market segment MVR: you are not expanding the market at all. you might even be dropping some markets where the cost of maintaining certain functionality is not worth the investment Looking at the impact to existing offerings, MVP: since it is new is should not impact any existing products MBI: almost certainly likely to impact existing products MVR: attempting to lay the base for new offerings Looking at risk, MVP: product not desirable to new market MBI: upsetting existing codebase and thereby other offerings MVR: upsetting existing codebase dependent upon existing system and not recognizing dependencies when being replaced 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. By definition, an MVP should be funded for the value of discovery. After it is built the decision to continue, pivot or stop should be made. It is also possible that an MVP is not intended for a full release but to a limited audience to determine its viability. MBIs need to be fully funded. Remember that an MBI is the minimum business increment so this may not be much funding. MVRs are funded based on the existing customer base you want to continue to support. Figure 2. Vertical slices are important to achieve quick feedback and value info@netobjectives.com LEAN244 ( )

5 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 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. The original definition of an MMF is the same as an MBI, but since SAFe has altered its meaning it is perhaps better not to use the term at all. In any event, regardless of terms, all artifacts should always be built by taking vertical slices and building them in sequence so to get feedback and value quickly as shown in Figure 2. Figure 3. Working on items in a serial or parallel manner. Figure 4: Illustrating Serial and Parallel work with MBIs 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 ABOUT EPICS AND MMFS? Notice that business increments, MBI, and MVPs have taken Al Shalloway is the founder and CEO of Net Objectives. With over 40 years of experience, Alan is an industry thought leader in Lean, Kanban, product portfolio management, Scrum and agile design. He helps companies transition to Lean and Agile methods enterprise-wide as well teaches courses in these areas. Alan has developed training and coaching methods for Lean-Agile that have helped Net Objectives clients achieve long-term, sustainable productivity gains. He is a popular speaker at prestigious conferences worldwide. He is the primary author of. Alan has worked in literally dozens of industries over his career. He is a co-founder and board member for the Lean Software and Systems Consortium. He has a Masters in Computer Science from M.I.T. and a Masters in Mathematics from Emory University. Follow Al on alshalloway info@netobjectives.com LEAN244 ( )

6 WHY THIS IS IMPORTANT The use of MBIs allows for avoiding the redefinition and overloading of terms. What we can now do is have a refinement of our initiatives into business increments and then into MBIs and then into features and so on. This is important not just because it is simpler and clearer. Both are important reasons but because the concepts in the Lean- Agile model are not tied to any organizational structure. This mean you can use what is needed regardless of the size of your organization. This also enables greater clarity on Lean Portfolio Management, a serious concern at virtually all sizes of an organization. By having the initiatives create business increments from which we can define MBIs, we can more easily run weighted shortest job first (WSJF) on real items of value. Note that epics contain parts that will not be delivered, and features don t always have value in and of themselves. MORE RESOURCES Visit the Net Objectives Portal at to see these related articles: Net Objectives approach to SAFe The Business Case for Agility Clarity is essential because it enhances and understanding. This increases alignment, and this increases the ability to have more autonomy. Figure 5. A hierarchy o fartifacts NET OBJECTIVES We are committed to delivering the principles, practices, and perspectives that businesses must know in order to maximize their return on their technology solution and software development efforts. We combine our experience and a time proven approach based on lean thinking to continuously extend the capability of what is possible in creating effective technology delivery organizations (IT or product). We provide these learned methods to our clients to assist them in achieving their goals and in assisting them in making their organizations more successful. A full set of papers and articles may be found at FLEX Enterprise Transformation Lean Agile Team Agility Patterns TDD ATDD Assessments Consulting Training Coaching

7 Drive from Business Value BUSINESS-DRIVEN SOFTWARE DEVELOPMENT Business-Driven Software Development is Net Objectives proprietary integration of Lean-Thinking with Agile methods across the business, management and development teams to maximize the value delivered from a software development organization. This approach has a consistent track record of delivering higher quality products faster and with lower cost than other methods. Business-Driven Software Development goes beyond the first generation of Agile methods such as Scrum and XP by viewing the entire value stream of development. Lean-Thinking enables product portfolio management, release planning and critical metrics to create a top-down vision while still promoting a bottom-up implementation. Our approach integrates business, management and teams. Popular Agile methods, such as Scrum, tend to isolate teams from the business side and seem to have forgotten management s role altogether. These are critical aspects of all successful organizations. Here are some key elements: Business provides the vision and direction; properly selecting, sizing and prioritizing those products and enhancements that will maximize your investment. Teams self-organize and do the work; consistently delivering value quickly while reducing the risk of developing what is not needed. Management bridges the two; providing the right environment for successful development by creating an organizational structure that removes impediments to the production of value. This increases productivity, lowers cost and improves quality. BECOME A LEAN-AGILE ENTERPRISE Involve all levels. All levels of your organization will experience impacts and require change management. We help prepare executive, mid-management and the front-line with the competencies required to successfully change the culture to a Lean-Agile enterprise. Prioritization is only half the problem. Learn how to both prioritize and size your initiatives to enable your teams to implement them quickly. Learn to come from business need not just system capability. There is a disconnect between the business side and development side in many organizations. Learn how BDSD can bridge this gap by providing the practices for managing the flow of work. WHY NET OBJECTIVES While many organizations are having success with Agile methods, many more are not. Much of this is due to organizations either starting in the wrong place, such as focusing on the team when that is not the main problem, or using the wrong method, such as using Scrum or kanban because they are popular. Net Objectives is experienced in all of the Agile team methods (Scrum, XP, Kanban) and integrates business, management and teams. This lets us help you select the right method for you. info@netobjectives.com LEAN-244 ( )

8 LEARN TO DRIVE DEVELOPMENT FROM THE DELIVERY OF BUSINESS VALUE What really matters to any organization? The delivery of value to customers. Most development organizations, both large and small, are not organized to optimize the delivery of value. By focusing the system within which your people are working and by aligning your people by giving them clear visibility into the value they are creating, any development organization can deliver far more value, lower friction, and do it with fewer acts of self-destructive heroism on the part of the teams. THE NET OBJECTIVES TRANSFORMATION MODEL Our approach is to start where you are and then set out a roadmap to get you to where you want to be, with concrete actionable steps to make immediate progress at a rate your people and organization can absorb. We do this by guiding executive leadership, middle management, and the teams at the working surface. The coordination of all three is required to make change that will stick. OUR EXPERTS Net Objectives consultants are actually a team. Some are well known thought leaders. Most of them are authors. All of them are contributors to our approach. Al Shalloway Scott Bain Luniel de Beer SELECTED COURSES Executive Leadership and Management Lean-Agile Executive Briefing Preparing Leadership for a Lean-Agile Transformation Product Manager and Product Owner Lean-Agile Product Management Lean-Agile at the Team Acceptance Test-Driven Development Implementing Team Agility Team Agility Coaching Certification Lean-Agile Story Writing with Tests DevOps DevOps for Leaders and Managers Train the Trainer Online Coaching Academy Becoming a Team Agility Trainer Technical Agility Advanced Software Design Design Patterns Lab Effective Object-Oriented Analysis and Design Emergent Design Foundations of Sustainable Design Sustainable Test-Driven Development SAFe -Related Leading SAFe 4.0 Using ATDD/BDD in the Agile Release Train (workshop) Architecting in a SAFe Environment Implement the Built-in Quality of SAFe Taking Agile at Scale to the Next Level OUR BOOKS AND RESOURCES CONTACT US info@netobjectives.com LEAN-244 ( ) LEARN MORE portal.netobjectives.com Copyright Net Objectives, Inc.