This is part of our Tuning SAFe webinar series.  A recording of the webinar on this topic is available here. 

The Goal is to Realize Value Quickly

The Scaled Agile Framework® (SAFe) makes very clear the importance of building incrementally and prioritizing according to value (using WSJF, the “weighted shortest job first” formula). The goal is to realize the greatest value over the shortest period of time. This is one of the primary objectives in Lean-Thinking and it requires careful thought. It begins with right-sizing the “epics” in the portfolio.

While SAFe describes how this should be done, the importance of this is often overlooked in many implementations.  In particular, it’s not enough to compare which epics are most important, it’s critical to discover which parts of an epic should be built, deferring the rest for later.  SAFe describes this in their ‘Splitting epics’ section on their Epics Abstract page.  Unfortunately, the need and approach to this is often misunderstood. 

A common approach to splitting epics involves identifying the most important features. However, this feature-driven approach has some subtle implications that make alignment across programs difficult. It quickly leads to conversations about “how do we implement this feature?” instead of “what will give us the most business value?” A better approach begins with looking at business value, asking “what part of the epic will enable us to realize business value quicker?” The goal is always the fast realization of business value predictably, sustainably, and with high quality. All teams must align around this perspective.

Split Epics to Discover Highest Value

To illustrate this, consider “Market Segment / Customer / Class of User” mentioned in the Epics Abstract article. This approach considers which market segments or customer bases we are adding value to. By considering this first, we create a filter through which to look at the features of the epics.  Not only are some features not needed, but we’ll discover that many parts of required features can be deferred until future market segments are attended to. This is an important distinction that is too often overlooked. It means that we not only look to see which features are most important, but which parts of a feature are needed for the business value we’re trying to build. This gives us not only smaller epics but smaller features to implement.

The point of splitting epics into smaller epics is not to deliver less but rather to deliver something earlier. It is to identify the most important, highest value part of the epic and deliver that as soon as possible. And then to deliver the next most important part of the epic and deliver that. And so on as long as there is value to be realized relative to other opportunities.

Align to Complete Right-Sized Epics

Let’s take this one step further. By recognizing this “right-sized epic” as the first part of the epic to be built, all teams and trains should align to complete these right-sized epics in the order in which they are on the portfolio backlog. This is important to mention because trains do not always think about the sequence of completing work by value. More often, their selections are informed first by dependency requirements with other trains. But this poses several challenges. One challenge is that it delays feedback on whether the epic was completed properly, even if it is not going to be released right away.

Decompose epics into “right-sized epics” based on business value and then align everyone on completing those right-sized epics before going on to the next. This leads to greater feedback and greater value realization.  This goes beyond managing dependencies and encourages teams (and even trains) to work together on parts of an epic as they are being built.

Start and Adjust

SAFe is a great starting point. If you are experiencing any of the following challenges, it can often be solved by focusing on building right-sized epics.

• Teams working on multiple epics simultaneously
• Epics being larger than they need to be resulting in features being larger than they need to be
• Too many epics being started due to the pressure of getting an epic started before completion of a more important one
• Non-optimal train formulation because the epics running through them are not as focused as they could be
• Dependencies are managed but teams do not collaborate as much as they should, resulting in high integration costs
• Important items not related to development that are not attended to as quickly as they should be

The reason for this is the right-sized epic becomes something that everyone focuses on. One of the key benefits of SAFe over other approaches at scale is that it takes a holistic approach. In other words, SAFe does not lead to a mere collection of teams working together. Rather, they are guided with the intention of working as a whole. In the same way people in a team should align with the goals of the team, and teams need to align with the goals of the train, all of the teams and trains working on an epic need to align with delivering the most important epic as quickly as possible.

The smaller the epic, the more alignment can be achieved. Eli Goldratt, the creator of “The Theory of Constraints,” once said that “Often reducing batch size is all it takes to bring a system back into control.” Using right-sized epics is one way of achieving these smaller batches.

They also enable business stakeholders to more easily align across portfolios. This is because when large epics are involved, it is often difficult to get true agreement upon which epic is most important because some parts of each epic are more important than some parts of the other epic. By decomposing the epics and then doing WSJF on the smaller pieces, a better ordering of work to be done can be achieved. 

In Summary

There are four main reasons to do right-sized epics:

• define and work on high-value items (avoid working on things of less imortance)
• achieves quicker realization of business value
• implementation is more efficient
• teams are better able to align

Minimum Business Increments

we actually use the term minimum business increment instead of right sized epics when we are not working with a client doing SAFe that wants to use SAFe terminology.  There are advantage to this.  Look at Minimum Business Increments for more and The Business Case For Agility for even more detail.

As always, if you can relate to this blog and are looking for assistance, please contact me at alshall@netobjectives.com

Al Shalloway
CEO, Net Objectives