This is a chapter from Al Shalloway's upcoming book Achieving Business Agility at All Scales: Transforming Your Organization with Lean Thinking and Lean-Agile Patterns
Many companies at small scale (100 people or less in all of development) have the challenge that their development teams are not as effective as they’d like. This includes releases taking too long, often missing the mark of what’s needed, poor product quality, misunderstood requirements, and small changes taking a long time to get done. A cursory investigation reveals several causes: working on too may things, unclear requirements, teams not working well together, and inconsistency of methods.
Most have started with Scrum training and then learned something about Kanban when Scrum didn’t seem to diminish these challenges. Since the issue seems to be organizational, many look for a solution by going to scale. The choices to improve seem few: SAFe, LeSS, Spotify Model, Scrum of Scrums or a customized Lean-Agile approach. SAFe often appears to be the best choice to many even though it was not designed for small scale.
SAFe’s best known for its program increment, planning event and Release Train Engineer (RTE). Each of these promise something sorely needed by the organizations in trouble: regular releases, a way to plan for them and someone to oversee their development, respectively. These are good objectives and a way to achieve them is good. SAFe has some other advantages – an holistic approach and the use of Lean-Agile Principles.
These are good things. But systems are not just a collection of what comprises them. Systems are more about the relationships between the components. Components that were designed for large companies are often not the same as what would be best used in smaller companies. SAFe was designed for companies larger than small scale. In fact, Essential SAFe, SAFe’s smallest option, is designed for programs within a large organization, not for a program that is the entire development group.
There are actually two different challenges when using Essential SAFe for entire organizations. First, although small companies don’t need all of the levels SAFe provides, each of the levels above Essential SAFe provide concepts that small scale organizations need. The other is that Essential SAFe was designed for programs within an organization, it is set up for a different pace and set of dynamics when it is being adopted by a small organization.
This is not to say that Essential SAFe can’t be a workable core for a small scale Agile adoption. It does, however, mean that, first, it must be guided by including some of the concepts in SAFe’s higher levels but in a simpler manner that is appropriate for small organizations. And second, it must be recognized that the pace and collaboration methods of small scale are different from large the large organizations SAFe was designed for.
Who this Chapter Is For
This chapter is for someone who is considering SAFe for their small-scale adoption. Common challenges these people are often looking to improve poor requirements, inconsistent Agile results across the organization, too many things being worked on and teams not working well together. SAFe’s program increment planning event and role of the Release Train Engineer can provide a foundation for solving several of these challenges and provides the impetus for considering SAFe’s adoption. SAFe can very well provide some needed structure at small scale but doing so comes with it’s own challenges. This chapter will both explain them and how to overcome them.
Fortunately these can be readily handled with Lean-Agile methods. This enables getting the benefits of SAFe Essentials (common understanding of terms and certain core practices) without the inherent disadvantages that would come with an out of the box adoption.
A Visual Perspective of SAFe
SAFe is more easily understood when it is laid out visually along its core basic workflow path – also known as the value stream (if you are not sure what a value stream is, please read this before continuing). Value streams always start with an idea to achieve and it’s achievement (or abandonment). SAFe’s artifacts, activities, and roles are also illustrated:
Figure 1: SAFe depicted as a value stream
Figures 2 & 3 depict what happens when a company adopts only Essential SAFe by splitting figure 1 up into two parts – Essential SAFe and the levels above it. Figure 2 is shows what is basically Essential SAFe while Figure 3 is what’s left out of Essential SAFe.
Figure 2: The program level
Figure 3: The layers not part of the program level.
SAFe has many artifacts and concepts described only for the top levels. These include strategies, epics, solutions, MVP and others. Figure 2 shows what is left out while Figure 3 shows what’s in Essential SAFe. It is important that we realize that the concepts in these top layers that have a role at the program and at small scale. For example, small companies have strategies, how are we implementing them while seeing the why to the business that they were chosen? Also, note that some of your company’s roles are now in both segments.
Essential SAFe was defined for Agile Release Trains that are mostly independent and are sized at 50-125 people. At small scale, however, there is not a direct connection in SAFe to bridge the gap between business and the teams. In addition, its method of focusing on value with epics, solutions, capabilities, MVPs, MMFs, … may appear too complicated to companies that just have product owners
The pictures above illustrate a dilemma adopting SAFe presents. On one hand, we can see value in SAFe but clearly don’t need to adopt it all. On the other hand, adopting only part of it as laid out in Essential SAFe has us leave out some necessary concepts. Fortunately, there is a straightforward way out of this dilemma.
The first step to this is to recognize, that for all that SAFe provides, it has not made specific the notion of the smallest chunk of business value that can be realized by the customer. SAFe uses the term MVP in a way Eric Ries does for developing products for early adopters. MVPs are useful in this situation, but aren’t applicable to extending existing products. In addition, if you are using 3 month planning increments an MVP for discovery and quick pivoting doesn’t quite fit. If you are using shorter increments you still need a term that fits for both new and established business increments.
Ironically, the Minimum Marketable Feature of Denne and Cleland-Huang’s Software By Numbers could have represented this 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.”
We have found renaming Denne and Cleland-Huang’s MMF to minimum business increment (MBI) works quite well. An MBI is the smallest piece of functionality that can be delivered that has value to the business in it that:
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 4 which shows when value is delivered serially or in parallel.
Figure 4: 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 5 shows what we can achieve when these increments are sub-divided into minimum business increments.
Figure 5: Illustrating Serial and Parallel work with MBIs
What Is Required at Small Scale
Small scale essentially just requires:
Let’s go through each of these.
Sequencing Your Work
SAFe uses solutions to ensure that what is being built will actually provide value. If you look at the Essential Level on the SAFe big picture you will see a solution button. But when you click it, it takes you to a page that describes Solutions for the “large solution level.” This is because solutions were developed for providing guidance when multiple ARTs are involved. ARTs are designed to be 50 or more people, at small scale it is likely that you have no true trains, but mostly teams trying to work together.
The concept of the solution is a good one. It means to provide all that is necessary to truly realize value. The concept of the solution combined with the driver for delivering in small increments is another way to think of the Minimum Business Increment (MBI). That is, the smallest increment of value to the customer, but driven by business needs, that can be delivered. The intention is not to deliver less, but to deliver sooner by delivering a series of MBIs to manifest the initiative driving development.
The MBI is a perfect artifact to run Weighted Shortest Job First on – since all of it is required to provide value (epics often contain parts that are not going to be implemented and features often do not contain enough value to be delivered).
An Intake process
The easiest and most effective way of avoiding overloading teams is to control their intake process. An effective way of doing this is to have team(s) pull work from an input queue when they are ready. It also requires not allowing people to impose work on the team.
Getting from MBIs to clear, well-defined stories with acceptance criteria
This is a critical step in any Agile process. In many, even most, cases it is the biggest constraint. Not having small stories often makes it difficult to have work completed at the end of a sprint, or if using a flow model, they take longer than they should. Not having clear acceptance tests (even when if not automated) often causes rework when clarity is achieved. The best way to achieve this is usually Acceptance Test-Driven Development using Behavioral Driven Developments Given When Then. This does not require full automation of the tests but can achieve great value when only the discovery and specification stages of it are done.
Collaboration and Dependency Management
How teams at small scale collaborate depends upon what the teams are responsible for. There are several situations at small scale that require different solutions. However it is done, remember that shorter planning cycles are better than longer ones. Most Agile adoptions at small-scale do not need three month planning cycles, or even planning events. There are many ways to accomplish planning at small scale but the following are the most common. Other than the “flow or iteration” variation, each option is presented in what usually achieves more effective/efficient deliveries. There are several ways to accomplish this. They are presented on Dependency Management, Collaboration and Planning at Small Scale which you should read before continuing.
DevOps is a special case of two different responsibilities working together. In some ways it is no different from the communications between business-product managers, product managers-product owners, and product-owners to development teams. The challenge in the communications of development and operations is two-fold. The first is that Agile’s focus on teams sometimes has developers think that when the code is built (including testing) it is done. While it is not the intent of the Agile Manifesto to do this, its 7th principle “Working software is the primary measure of progress” sometimes has teams forget real value comes from when the customer realizes the value.
One of the first and most effective steps in DevOps is for the development teams to merely make what they are doing and what they will need ops to do visible.
What Was Changed From Essential SAFe and Why
Only two significant changes need to be made to Essential SAFe to make it much more effective. MBIs essentially encapsulate the concepts of epics, solutions, MVPs, and capabilities. This can readily be seen if we first look at SAFe’s big picture from a value stream perspective as shown in Figure 6 then update the artifacts used as shown in figure 7.
Figure 6: SAFe as viewed as a value stream.
Figure 7: SAFe and FLEX viewed together as value streams.
Many organizations often don’t get the buy-in from the business people to define the MBIs. In this case, product management must attend to what is coming in and refine it as best they can. If business stakeholders later disagree they should be reminded that their participation in selecting and refining items for work is requested.
The second addition is the business architect (shown in figure 7) The business architect attends to the relationship between new offerings and existing capabilities. In particular, if a new offering affects an existing capabilities, the new development of the new offering must not adversely affect any existing capabilities or offerings. The roles SAFe uses for solutions are not present at the Essential SAFe level and are accomplished by the product manager when MBIs are used. Remember an MBI includes the solution and any costs required to implement it (including not adversely affecting other capabilities or offerings).
Starting the Adoption of SAFe at Small Scale
Using the backbone of Essential SAFe (RTE, planning event, everyone developing and synchronizing in cadence) SAFe can provide some guidance to small development groups. It is definitely an easier problem than large scale, so it is important not to adopt too much of SAFe while not leaving out the concepts that SAFe does not cover at small scale.
When deciding on your adoption approach, when looking at training to take, it is important to get as much hands on training and coaching as possible. A focus on the framework often leaves teams wondering what to do. We suggest the following for a development group of about 75 people:
Note: It is suggested you do not take SAFe training as it will focus on a larger implementation than needed. Better to have your people spend more time on the work they will actually need to do.
Using SAFe for small scale can have several advantages. But it is important that Essential SAFe out of the box is not usually a good solution for development teams less than 100 people. Adding a few Lean-Agile methods to it, however, can greatly improve the adoption.
Disclaimer: Net Objectives is not affiliated with Scaled Agile except for being a bronze partner. None of the services mentioned here carry Scaled Agile certification or endorsement.