MVPs are used to discover when a product is useful. MBIs are used to define the smallest increment of value that can be built and released that realizes value for the business. Although both of these are about doing a small amount of work and releasing it, they are quite different in both intent and method.
An MVP is intended to create a new product without an existing customer base. It is built by taking the smallest step possible to determine if it is viable. An MBI is for building the smallest enhancement to an existing product. Continue reading “Minimum Viable Products (MVPs) are very different from Minimum Business Increments (MBIs)”
This is an excerpt from Introducing FLEX – FLow for Enterprise Transformation: Going Beyond Lean and Agile (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. S
If you want to learn more about FLEX you can watch a webinar on FLEX, 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
The concept of the minimum business increment (MBI) is key to Agile software development because it provides us with a container for all of the items required to realize value for a business increment. Its focus on being “minimal” provides us with the smallest batches possible, a practice proven to be effective. This alone would make them worthwhile. But they have another value, they tie strategies to the intake process, facilitate the use of ATDD and assist in planning. This chapter discusses both how and why this is so important.
Tying Strategies to the Intake Process
Business stakeholders and product managers provide the development group what to work on. Very often this is with the development group as they may be the originators of what to work on. By using MBIs, the development group gets smaller batches than they would otherwise. This is one of the best ways to manage work in process – have smaller chunks of work come in. The content of the MBI, that is, all of the tasks required to realize value, also provides the development group insights on who they will have to work with to get the software out the door and realize value.
Using MBIs to feed ATDD
ATDD is our recommended way to decompose and refine requirements. MBIs are containers of all of the features and stories that will be developed. By peeling off vertical slices from the MBI using ATDD, the MBI can be used to see what’s left to decompose while ensuring all necessary components of it are defined. By decomposing MBIs into features and then stories, teams also avoid features and stories that are bigger than needed. Without the MBI, team often work on an entire feature even though only part of it is needed for the first MBI.
Planning with MBIs
Big room planning in SAFe has people focus on getting features completed. However, features by themselves may not be releasable where they will provide value on their own. It is therefore possible to schedule features to be completed but not have something to release until the end of the program increment. It is better to schedule the completion of the MBIs, not the features. This manages work in process in a natural manner.
Lean portfolio management is an important aspect of enterprise Agility. Organizations always have more options than capacity. One therefore needs to be able to understand what is the most important value to deliver. But what is value to one company may be waste to another. The first step in Lean Portfolio Management therefore, is determining what’s of value to the organization.
This, of course, is typically oriented around value to customers. or example, a financial company might focus on: Continue reading “The first step in Lean Portfolio Management”
Planning events should be more about collaboration & dependency management than just creating a plan. Teams commit to the plan with the understanding that any teams they are dependent upon will work with them as needed.
During the event this requires both teams to agree to the date a dependency will be built. This is supposed to happen before the stickies & yarn go on the board. But it sometimes doesn’t happen. This must be tracked. This is done easily enough by putting red dots on both stickies involved. This does not always draw these uncommitted to dependencies to enough attention.
Continue reading “Big Room Planning Event tip: Make sure commitments are made for all dependencies”
At Net Objectives we’ve been leading with Agile Product Management for 13-14 years. Borrowing from Denne and Cleland-Huang’s Minimum Marketable Feature we created the term Minimum Business Increment which is the smallest chunk of value that can be realized that makes business sense. It is not about delivering less, but delivering sooner. Continue reading “Why you need to lead with Product Management regardless of your Agile approach”