Minimum Viable Products (MVPs) are very different from Minimum Business Increments (MBIs)

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)”

How MVPs are Limiting you if You’re Using SAFe

MVPs were defined by Eric Ries to mean “that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.”

If you are an established company, especially if you are using SAFe, the chances are excellent that you area not creating a new product but enhancing an existing one. You already have a customer base, know a considerable amount about your product and you have competitors you are trying to either keep ahead of or catch up to. This is a considerably different situation than creating a new product that you hope will create a new market.

In this situation, product development starts with initiatives to build. he question isn’t so much how do you discover if there is a product, as is it “what is of the most value that we can deliver sooner.” This requires a different tact. This is what a Minimum Business Increment is for. MBIs are that smallest part of an initiative that will realize the most value when delivered. This is a far cry from the MVP where we start small and extend.

While both MVPs and MBIs are conceptually about value sooner, they are considerably different in implementation. If you’ve been having trouble using MVPs, now you know why.

How Using MBIs Ties Strategies, the intake process, ATDD, and planning together

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.

A Simple Solution to Agile at Small-Scale

I keep running across organizations with 4-10 dev teams struggling with Agile. They look to the two most popular frameworks out there for a solution (Scrum & SAFe) to solve their problems. On one hand they see something that can work at the team but doesn’t help them with their product management. On the other they see something much bigger than they need. They’ve fallen into a trap–looking for a solution instead of solving their problem

What are their problems? Most have trouble Identifying what has the greatest value to deliver, breaking it down into the right size business increments to give to the teams, coordinating their teams’ work, teams not being able to decompose the business increments they’re given into small stories, and building, validating and releasing the code quickly. These abilities should be their focus

When Agile Product Management provides guidance in what’s important, coordinating teams is straightforward. It’s easier to pull a rope than it is to push it. 2-3 days working on prod management, ATDD, a little Scrum and a little Lean is all you need. Invest here, it returns more value. And it’s less expensive. Proper training &coaching methods can get your product folks, 6 teams & their coaches working with Agile methods for less than $40k

The missing piece of Lean Portfolio Management

I am often asked how to do Lean Portfolio Management. Let’s consider what’s needed to do this effectively. The real issue is when different programs require the same limited capabilities. How do you decide which one is more important? Weighted Shortest Job First (WSJF) is commonly used. But ‘business value’, a  key component of WSJF, means different things to different groups.

How can we decide what the business value is when people in different divisions have different views? Continue reading “The missing piece of Lean Portfolio Management”

A missing piece in SAFe product management

Lean suggests that we work with small batches, be able to deliver value quickly and to drive from a business perspective (typically through delivering value to the customer). ‘Deliver value’ means not just to deploy something but to ensure that value can be realized by the intended customer. In other words, we need a definition for the smallest increment of value that delivers value from a business perspective. In other words, it can’t be too small (we may not want to be delivering all the time) but it has to be sufficient (have all the components (e.g., marketing) required to realize value. In other words, minimum yet sufficient. It also must have measurable value from a business perspective. Continue reading “A missing piece in SAFe product management”

The first step in Lean Portfolio Management

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”

Big Room Planning Event tip: Make sure commitments are made for all dependencies

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”

Pay for your Agile adoption with the waste you eliminate by focusing on Agile Product Management (APM)

The intent of APM is to identify the most valuable work to be done, focus on just that work, prepare it for the teams to work on &guide them in building the functionality needed in thin slices. This creates quick feedback, the ability to pivot & faster value realization.  The goal is business agility–the quick realization of value predictably, sustainable &w/high quality. Product management creates clarity on what is most valuable for the organization to build while providing teams guidance in its implementation. By discovering & removing unnecessary scope and providing this slices of work, teams become focused on true value delivery while becoming more efficient. This enables dramatically shorter times from start to initial value delivery.

Continue reading “Pay for your Agile adoption with the waste you eliminate by focusing on Agile Product Management (APM)”

Why your Agile adoption should pay for itself within the first Program Increment

This blog is written specifically written for those whose technology groups can readily be thought of as being composed of groups that are 40-75 in size, regardless of the current or anticipated level of SAFe adoption.

Overview

By learning Agile Product Management before shifting to a SAFe-like program increment planning event, groups can shorten the program increment being planned to 2-4 sprints instead of the normal 5-7. This results in savings from not having to refine 2-3 sprints. It also results in quicker realization of value by having a shorter release horizon. This more than makes up for the investment required to do this. Just as important, the additional focus enables easier management of proper work-in-process levels and results in teams being more efficient. If you are just learning to adopt SAFe, this is a great way to start. If you are already using SAFe, this can be a method of shortening the program increment and getting to be both more effective and efficient. If you  don’t want to use SAFe, product management with some Lean-Agile coaching can be used instead.

Taglines

Focus on the work, not the framework

Learning Agile Product Management will encourage people to adopt a supportive framework. It doesn’t always work the other way around.

The goal is to speed up the delivery date of your first release and continue improving after it. 

Agile Product Management – The Key to Effective Agile

The intent of Agile Product Management is to identify the most valuable work to be done, focus on just that work, prepare it for the teams to work on and guide them in building the functionality needed in thin slices. This creates quick feedback, the ability to pivot & faster value realization. The goal is business agility–the quick realization of value predictably, sustainable &w/high quality. Product management creates clarity on what is most valuable for the organization to build while providing teams guidance in its implementation. By discovering & removing unnecessary scope & provding this slices of work, teams become focused on true value delivery while becoming more efficient. This enables dramatically shorter times from start to initial value delivery.

Many people are looking to improve their ability to deliver value by becoming Agile. When considering such an adoption, it is useful to consider the following current and additional costs.

  1. Dollar cost of new training/coaching
  2. People cost (their lost time) due to this training/coaching takes
  3. Added cost of delay of value realization that this training/coaching costs
  4. Resistance (if any) that people have to this training/coaching

Obviously, these costs must be offset by gains. In our view, these gains should be met before the end of the next program increment.

The trick to getting a return requires focusing on the actual Agile work required, not the framework that surrounds it:

  1. focusing on quick business value realization by identifying those scenarios that will result in the quickest return for the greatest value
  2. shortening the program increment length in order to return value more quickly
  3. training and coaching product managers and product owners how to identify, sequence and thinly slice the most valuable work to be done
  4. creating small slices of functionality with clear scope, requirements and acceptance criteria
  5. having teams align around manifesting business value quickly

The key is the focus on business agility – the quick realization of business value predictably, sustainably and with high quality. This can be readily done by guiding work through the use of minimum business increments (MBIs) to create a focus on the smallest pieces of work that will realize the greatest value. Having smaller pieces enables shorter program increments. Smaller is also easier to manage as reflected in Eli Goldratt’s (creater of Theory of Constraints) observation – “Often reducing batch size is all it takes to bring a system back into control.”

Using smaller batches and shortening the length of the increment has several advantages. First, it reduces the amount of planning required. Second, it enables the group to pivot based on the feedback learned in the shorter increment. But perhaps most importantly, it focuses the group on delivering quickly. While SAFe suggests to “develop on cadence and release on demand” most planning events tend to define releases. By focusing on the implementation of minimum business increments (MBIs), even if a release is held to the end of the program increment, it is more likely more value will be created even if unexpected delays occur. See more here.

Of course, an investment in training and coaching must be made. But it should not take more than a few days. The core skills are to:

  • know what to focus on so as to avoid overworking the development team
  • only have teams work on things of real importance
  • only refine the backlog for those things about to be built
  • communicate what is needed to the development team in a way that creates clear scope, clarity and acceptance criteria for what the customers really need

The two key elements here are the use of MBIs and Acceptance Test-Driven Development (ATDD). ATDD is mostly a collaborative method for product owners, developers and testers to define scope and clear requirements. Automation does not need to be included in ATDD although it can be a first step towards that. Unless you have an unlimited budget of time and money, it is best to focus on actual Agile skills. Midisze companies are usually better off improving their skills and creating or modifying a framework that suits their work instead of investing in a framework and then trying to figure out how to do Agile.

Running a Planning Event effectively

A planning event is about collaboration and dependency management in order to maximize the teams to work together to maximize business value. A focus on finishing MBIs, not merely getting everything done by the end of the increment must be manifested by all teams.

  1. having teams align around the business value of what is being planned
  2. focusing the planning event on realizing value, not merely getting the work done in the increment

See Running Effective Planning Events for more.

In Summary

Learning how to do Agile Product Management with ATDD improves both what you are working on and how you are working on it. By mixing ATDD into the blend, teams get great clarity on scope and acceptance criteria setting up further gains by enabling automating testing.  I am not claiming that Net Objectives does anything magical here. Anyone who can effectively train and coach in product management, ATDD and team-agility can do what we do. Just make sure that’s who you engage with. The trick is in getting training and coaching before the planning. You can get more details about a framework (if you are using one) while you are doing the work.