Adopting the Scaled Agile Framework (SAFe) is not for everyone. There are several reasons to do so and several reasons to avoid it. And, of course, there is a middle ground. This chapter takes the concepts of FLEX and uses them to help people:
Many people are adopting SAFe because it provides a structure for organizing multiple teams to better work together. Scrum’s “Scrum-of-Scrums” approach has not succeeded very well in mid to large scale organizations because it does not provide either enough structure for the teams to work together or enough guidance on what value to create.
While SAFe provides these necessary ingredients, it is defined in such a way that small to mid-scale organizations are left with the choice of 1) adopting only part of SAFe to keep things simple while missing some key concepts or 2) adopting all of SAFe and having it be more complicated than what is needed.
This article presents a way to combine the essence of Lean-Agile Product Management with a few key SAFe practices to provide a full solution for the small to mid-scale without being more than what’s needed.
If you are reading this as a standalone article, it is strongly suggested that when you come to a link in this document, you take it to ensure you understand topics that are referred to earlier in the book.
Why People Are Going to SAFe
Surveys have estimated that over 40% of development groups are now using SAFe. This number grows every year. Yet, for all of its popularity, it has many detractors with many claiming its success is mostly due to great marketing. As with any controversial subject there is truth on both sides. SAFe does provide insights that are vital. And its appeal also comes from the fact that it’s designed to provide a clear path to adoption. In particular, the training paths afforded by a person in a company taking a 4-day course that now qualifies them (assuming they pass the tests) to teach many needed courses.
The reality is that companies go to SAFe for three reasons:
What SAFe Provides to Small to Mid-Scale Organizations
Most companies that have not successful achieved Agile at scale have the following challenges:
SAFe discusses much of what will work on these issues:
These are all good things. Unfortunately, SAFe provides principles and practices to cover these by defining them at different levels in the organization. These levels are the enterprise, portfolio, solution, program and teams. SAFe presents different configurations ranging from Essential to Full with each configuration covering more levels than the one before. The challenge is that the concepts at each level have value for all but the smallest of organizations. Small to mid-scale organizations are therefore left with a choice of taking the Essential Configuration that only covers some needed principles or the Full configuration which was designed for much larger companies.
A better way to define what is needed is by looking at work from a value stream perspective. Consider the two diagrams below:
On the left we have a representation of a common company hierarchy. People report to managers who are responsible for the work done by their teams. On the right we illustrate the value stream – that is, the flow of work across the organization (the up and down arrows represent management approvals). This sets up a challenge depicted in the following figure:
Figure 3: Managing people top down Vs Managing Work
The reality is that we manage our people with management hierarchies while our work goes across the organization. This is not effective for two main reasons. First, it has us manage people instead of supporting them to make good decisions. Second, it tends to have us try to get people to be working hard all of the time. This takes our focus off what we really want – quick delivery of business value. As Figure 3 asks “who is managing the value?” In most companies it’s a combination of people with this responsibility.
Since looking at our work from a value stream perspective, Figure 4 shows SAFe flow of work in a more value looking manner. From this it is readily apparent that when doing Essential SAFe (the program and team level) much of the value stream is not represented. This sets up the dilemma mentioned earlier – “1) adopting only part of SAFe to keep things simple but leaving some key concepts out or 2) adopting all of SAFe and having it be more complicated than it needs to be.”
Figure 4. SAFe represented as a value stream across the levels of the organization.
Of course, not every organization has these levels and many have even more. It’s actually more useful to represent the work being done in SAFe without being defined to be on levels as shown in Figure 5:
Figure 5: SAFe’s roles, backlogs and activities shown as a value stream.
Figures 4 and 5 are identical except for the layout of their components. This enables us to understand SAFe from a true value stream perspective. Note that regardless of the size of the organization one needs to do all of the above activities, with more or less the same associated backlogs.
SAFe refers to value streams in a non-standard manner. Lean considers value streams to be work actually flows across the organization. From the SAFe site:
It is important to realize you don’t define your value streams as much as you map them. The intent of SAFe’s comments on value streams is that you should fund stable and effective value streams. This requires a combination of managing the work that goes to the people in the value stream, organizing the talent so they can better work together and removing delays in workflow, feedback and realization of value.
Value streams exist from start to finish (“concept to consumption”) not just at the portfolio level as it appears to be in the SAFe big picture.
What Needs to be Done for Agile at Scale
When looking at SAFe from a value stream perspective, a simpler method of doing Agile Product Management at all scales presents itself. What we need to attend to and how they are in SAFe:
Business strategies are the firm’s working plan for achieving its vision, prioritizing objectives, competing successfully, and optimizing financial performance with its business model. These are called the strategic themes in SAFe. SAFe’s strategic themes are differentiating business objectives that connect a portfolio to the strategy of the Enterprise. They provide business context for decision-making and serve as inputs to the vision, budget, and backlogs for the Portfolio, Large Solution, and Program Levels. The primary purpose of strategic themes is to drive portfolio innovation and differentiation.
Have a backlog that contains all the work for all of the programs to pull from. This is called the portfolio backlog in SAFe. It provides a holding area for upcoming business and enables Epics intended to create a comprehensive set of Solutions, which provides the competitive differentiation and operational improvements needed to address the Strategic Themes and facilitate business success.
Containers for initiatives that manifest our strategies. SAFe defines epics as containers for a Solution development initiative large enough to require analysis, the definition of a Minimum Viable Product (MVP), and financial approval prior to implementation. Implementation occurs over multiple Program Increments (PIs) and follows the Lean startup ‘build-measure-learn’ cycle.
When starting to work on a business increment the first part of the work should be a slice of functionality that will validate the value of what is being worked on. This is basic Agile development. SAFe has labeled this the Minimum Viable Product, which is, unfortunately a re-definition of the term as used by Eric Ries in The Lean Startup. MVPs are intended to be used as a product or service with just enough features to satisfy early customers and to provide feedback for future product/service development. It is intended when creating something for early adopters. MVPs, as defined by Ries are useful at scale but only when you can in fact pivot.
Our work must center around providing value to the customer by providing them solutions, not merely functionality. These solutions must incorporate all that is needed for customers to realize value. SAFe calls these solutions.
Sequencing work by cost of delay divided by time. One method is defined as weighted-shortest job-first and has been somewhat redefined by SAFe to use normalized values.
Enablers are activities not directly tied to features or stories that provide value to customers but that are required to enable features or stories that provide value to customers. SAFe limits these to activities that extend the Architectural Runway but it should be broader.
Capability is a higher-level solution behavior that typically spans multiple ARTs. SAFe has capabilities that are sized and split into multiple features to facilitate their implementation in a single PI.
The smallest feature that can be reviewed by customers to validate what is being implemented is of value.
New Possibilities for Better Agile Product Management Emerge
A Key Concept Missing In SAFe
For all that SAFe provides it is missing one key concept – this is the notion of the smallest chunk of business value that can be realized by the customer. This was the original notion of the Minimum Viable Product, but SAFe uses term MVP in way Eric Ries does for developing products for early adopters. MVPs in this sense are useful but can’t be used well in 3 month planning increments. Ironically, the Minimum Marketable Feature of Denne and Cleland-Huang’s Software By Numbers could also have represented this missing concept. But it too was redefined to be used as “the minimum functionality that the teams can build to learn whether the benefit hypothesis is valid or not.” This “is evaluated by real users, whose feedback is then incorporated into the next benefit hypothesis cycle.”
One can, of course, bring this missing concept into SAFe, and we highly suggest that. This concept is the minimum business increment (MBI) for which value can be realized. We make it the smallest we can, so we can deliver it faster. But being a business increment means that it must be defined so value to the business can be realized – this is usually by the customers of the business realizing value. This means that all aspects of value realization (shared services, marketing, ops, …) must be included in the definition.
This is, of course, consistent with SAFe and one could argue that epics that have been right-sized can represent an MBI. This is true, but then we are overloading the term “epic” to mean more than one thing and this causes a different set of confusion. In any event, SAFe uses solutions, capabilities and value streams to include the concept of the MBI being sufficient for realization. All the pieces are there but they are difficult to grasp.
The notion of the MBI can also take us further than often done in SAFe. Consider Figure 6 which shows when value is delivered serially or in parallel.
Figure 6: Working on items in a serial or parallel manner.
Let’s say the chunks of work (A, B, C) represented business increments that resulted from our initiatives. If they weren’t minimum business increments, we could further divide them. Figure 7 shows what we can achieve when these increments are sub-divided into minimum business increments.
Figure 7: Illustrating Serial and Parallel work with MBIs
These results are even better than before. But perhaps more importantly, the use of MBIs allow 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 illustrated in Figure 8.
Using these concepts we can redo the value stream of SAFe using MBIs. This is shown in Figure 9 above the previous representation of SAFe as a value stream.
Figure 9: Using a Lean Agile Product Management model on top of SAFe.
Consider the differences between figure 5 and the top part of figure 9. Imagine that you were a perrson anywhere involved in the development of some work. Which flow makes it easier to see which item is most important to be worked on? With epics, solutions, capabilities, … it can be a little confusing. While there are several roles helping you decide what your responsibility is, when MBIs are used, it is a lot easier for everyone to see what is more important as determined by cost of delay. This can allow for a natural alignment of efforts which naturally allows for greater autonomy. That is, allowing decisions to be pushed down closer to the work itself.
Figure 10: Alignment leads to autonomy
What Happened to Epics, MVPs, and MMFs?
Noticed that business increments and MBIs have taken the place of epics. The notion of an MVP is a poor fit for when building enhancement to new products. If you have trains that are creating new products for early adopters, then by all means use MVPs. But it is unlikely that you should be using SAFe in those situations. 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. This is illustrated in figure 10 below.
Figure 11: Contrasting horizontal slicing Vs vertical slicing.
What Happened to the RTE and what are the TDM and ADM?
The Release Train Engineer role is a critical one. But we think it needs a little more. The Technology Delivery Manager can be thought of as an RTE with the added responsibility of ensuring all of the pieces for realizing value are present. This requires going beyond the Scrum teams and including shared services, DevOps, marketing, etc. All that an MBI would need to be manifested. The Application Delivery Manager role is often served by a system architect. Their role is to ensure that all of the pieces needed are present in what is being built.
Why This Is Important
This is important not just because it’s simpler and clearer, both important reasons, but because the concepts in the Lean-Agile model are not tied to any organizational structure. This mean you can use what’s 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 won’t be delivered, and features don’t always have value in and of themselves. See Why WSJF Should Be Done on MBIs and Not Features for more on this.
Clarity is essential because it enhances and understanding. This increases alignment, and this increases the ability to have more autonomy.
Deciding what to do
It is more effective to look at what works for you than to limit your choices by pre-set solutions. What will work for you has a lot to do with what size your group is. SAFe is designed for teams of 50 people or more working in the same product area. We’ll discuss options first for small scale development groups and then for mid-scale groups. For more on scale see Scale: What It Is, Why It Is Important.
What to do at small-scale
If your development group is smaller than that, you are actually too small for SAFe. Even SAFe essentials will bog you down while missing some of the key points of the value stream mentioned earlier. Instead, you should look at what practices SAFe provides and attend to them. These include:
Minimum business increments should be added to these core practices. If this adoption is being led by the development group and they can’t get their product managers to work with them on getting MBIs they should do your best attempt. It is also important to start your initial training with ATDD (see Benefits of Acceptance Test-Driven Development using Behavior-Driven Development).
While using SAFe at small scale may not be advisable, adopting many of its terms (ART, RTE, program increment planning event, …) often is since many people have experience with them.
What to do at mid-scale
At mid-scale there are more options:
Not using SAFe
At small to mid-scale SAFe is not necessary. As described in this book FLEX will work better. Figure 12 is the picture we prefer for FLEX:
Figure 12: Depiction of FLEX’s flow.
Taking Some of SAFe’s Practices and Using Lean-Agile Product Management
If you would like to adopt a SAFe lite approach, the following practices of SAFe can be quite helpful:
Using Lean-Agile Product Management as shown on the top part of Figure 9 will get the job done. The key is to focus on the deciding what to work on by creating a series of MBIs that are in line with your strategies, organizing the talent to work on it, to have an intake process to ensure the most important work is being done without overloading teams, have the teams work in cadence with each other, strive for continuous integration and do DevOps.
SAFe with Lean-Agile Product Management
If your company is adopting SAFe but you don’t want your group to use it, it may be advisable to use SAFe as a foundation while using Lean-Agile Product Management to define your artifacts and backlogs. This enables you to be mostly consistent with the rest of the organization. You can even define MBIs to be “right-sized epics” if you need to be totally consistent with SAFe.
For frameworks to be effective they should help you understand the problems you’re facing and the solutions available to you. While one can think of epics in the right way, it’s much better to have the concept built into the framework. This gets everyone on the same page.
Note: To see a slide deck of most of this presentation go here.