Disciplined Agile

How Using MBIs Ties Strategies, the Intake Process, ATDD, and Planning Together

Note: If you just jumped to this chapter and haven’t read The Goal Is Business Agility: What’s in Your Way? earlier in the book, I advise that you read that now.

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.

How using MBIs helps

Takes too long to get anything done
Putting smaller work items into your workflow speeds things up considerably.

Working on too many things

Smaller items get done faster meaning fewer will be being worked on.

No line of sight to strategies and OKRs

MBIs are a direct result of the business increments that have been generated from initiatives which gives line of sight from the MBI (and anything that derives from it) and the strategies which ultimately spawned them.

Don’t have Product Focused Teams

When an organization creates business increments and implements them with MBIs, they are being product focused. This helps them see that this is a behavior they want to maintain.

Ineffective budgetary process

Getting to a product focused organization makes improving the budgetary process much easier.

Chunks of work too big

MBIs by definition will get items into the intake process as small as they can be.

Poor intake process

One of the biggest challenges with an intake process is when items are larger than they need to be. Then people start going around the intake process.

Work items not properly prioritized

It is hard to properly prioritize anything that is not an MBI. Epics contain value that does not need to be released prior to the rest of the epic being done. Prioritizing items that have both high and low priority items is challenging because the high priority part of one may be greater than the low priority of the other while being less than the high priority of the other.

Unclear requirements

Getting requirements on smaller, well-scoped items is much easier than on over-large items.

Lack of visibility of workflows

It is easier to see the workflows of items deriving from an MBI than items that come from many MBIs. An MBI focus makes seeing workflows easier.

Insufficient collaboration

MBIs improve collaboration across teams significantly. Team can now focus on true value delivered and not just their work items. Also, an MBI contains what’s needed for security, marketing and ops. The visibility of the MBI as a container of all of these items makes it easier for people to plan and work together.

Limited skills / experience

Using MBIs won’t help increase your people’s skill level, but it will enable you to manage it better.

Ops blindsided and pulled in many directions

While MBIs won’t solve ops from being pulled in different directions they help ops in two major ways. First, clearer sequencing of MBIs makes it easier for ops to see what has priority when decisions need to be made. Second, by attending tot he intake process, ops can readily see what’s coming their way since MBIs describe the work ops needs to do to release the MBI.

Integration errors

Integration errors are really teams getting out of sync and discovering this during integration. MBIs enable better collaboration and focus, enabling teams to discover when they are out of sync sooner.

Problems discovered late

Man problems that are discovered late could have been discovered sooner, but were just not attended to. By speculating on what it takes to get an MBI to value realization, many of these items can be seen ahead of time.

Marketing needs left out

What it takes to realize value, which of course includes marketing, is included in all MBIs and is therefore considered early on.