Executive overviewThis chapter is intended for someone considering SAFe® for their small to mid-scale adoption. Many organizations are adopting SAFe because it provides a method for multiple teams to better work together. SAFe is attractive because it provides more structure than “Scrum-of-Scrums” but can be overly complicated for technology organizations of less than 1000 people. This article will discuss:
Note: for an overview of this chapter see Adopting SAFe at small to mid-scale overview.
Why people are adopting SAFeSurveys 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:
IntroductionMany organizations with small-to mid-scale development (1,000 developers or less) face the challenge that their development teams are not as effective as they would like them to be. This includes releases taking too long, missing the mark of what’s needed, poor product quality, misunderstood requirements, and small changes that take a long time to get done. The causes for this are surprisingly common and include working on too many things, unclear requirements, teams not working well together and inconsistent methods. Most organizations have started with Scrum training. Scrum is not generally applicable to all teams of an organization so many have gone on to learn something about Kanban as well. While a Lean-Kanban approach can be used to coordinate a few teams, it does not provide many of the practices needed for Agile Product Management and does not lay out required practices that those new to coordinating multiple team requires. Many have tried to address the larger issues of scale by choosing from among the small set of choices of SAFe®, LeSS, Spotify Model, or Scrum of Scrums. LeSS and Scrum of Scrums don’t appear to provide the coordination needed while the Spotify model requires a certain organization of teams and was designed for a culture almost certainly different from yours. Hence, SAFe often appears to be the natural choice. SAFe’s program increment planning event, working in cadence with synchronization, having a role (the Release Train Engineer) to guide this and being guided by Lean principles provides a seductive solution. And they can be used as the cornerstone of small to mid-scale organizations wanting to expand the Agile adoption beyond teams. But SAFe was designed for larger organizations (or programs of such organizations) that face their own sets of dynamics and pace which are usually not present at the small to mid- scale. The challenge of Essential SAFeEssential SAFe, the smallest level of SAFe, was designed for programs within a large organization. It was not designed for an entire organization that is the size of a program. Here are examples of challenges that come with this.
The bottom line is that while SAFe provides many good practices, 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. Fortunately there is a third option – take the essence of SAFe, guide it with patterns of successful Lean-Agile adoptions, and adopt a subset of SAFe that works for your organization. Looking at SAFe from a Value Stream PerspectiveIt is useful to look at SAFe from a value stream perspective, as shown in Figure 4. From this figure 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.”
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:
You will see a similarity between figures 4 and 5. There are a few important differences, however. In Figure 5, the flow of work is not superimposed upon the hierarchy of the business. There are no levels being shown, just the workflow, roles and artifacts. You may notice that the artifacts have changed as well – these will be explained later in this article. All of the elements shown are present in all organizations regardless of size. Notice the five “phases” of work: Strategic planning, Lean-Agile Product Management, Planning, Implementation & Integration, and Release. This diagram is illustrative only. Feedback loops are present everywhere but are not shown for clarity of showing how the work flows. A Note on SAFe’s Value StreamsSAFe referred to value streams in a very non-standard manner in 4.0 but has come back close to its original, and more useful, definition.. 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 Lean-Agile at scaleIt is neither simple nor easy to get different roles in an organization working together cohesively. The principles of software development apply universally. It helps to study the patterns of successful adoption seen in many other organizations. At the same time, it helps to remember that each organization has aspects of it that are unique and must be attended to. These include culture, who is leading the Lean-Agile adoption, and the particular challenges the organization is having. 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. FLEX Provides GuidanceFLEX details what organizations must do, provides options for each step, and gives guidance on the proper order in which to implement changes. FLEX is neither a top-down nor a bottom-up approach. It recognizes that work needs to be aligned with the strategy of the organization and that teams need to be able to self-organize. This requires a different kind of management, one where middle management attends to the direction set by leadership and sets up an ecosystem where development can manifest the value desired. This is called Middle-Up-Down management (see Toward Middle-Up-Down Management: Accelerating Information Creation). Assuming the goal is business agility, let’s look at what is needed for Lean-Agile at scale by looking at the order in which work takes place.
Strategic planning
Lean-Agile Product ManagementLean-Agile Product Management is a key part of Business Agility. It is primarily focused on the agile Business Discovery of value to turn goals and objectives into appropriately defined and scoped requirements of those aspects of a system being built. These higher level, but well-scoped and defined requirements feed business delivery by providing thinly sliced segments that can be quickly developed, providing quick feedback and the ability to pivot. Product management therefore holds business owners as its primary customers and guides business delivery to meet the expectations of its customers. Lean-Agile Product Management works at all scales. It is especially important at smaller scale because small organizations can’t afford to be over-burdened with complex solutions.
A key concept missing In SAFeFor 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. Using Minimum Business Increments (MBIs)There are many overloaded terms these days: solutions, capabilities, MVPs, MMFs, epics and more to identify the smallest batch of value to work on. Unfortunately, nowhere is this named. MVPs by Eric Ries are intended to guide teams in the development of new products for early adopters – not for adding functionality to an existing system or even replacing systems. In any event, not everyone builds any kind of product and the use of the term “product” is confusing for many. We have found the term Minimum Business Increment (MBI) to be more useful and more intention-revealing. An MBI is the smallest piece of functionality that can be delivered that has value to the business.
Here are some of the aspects that define the MBI.
MBIs must contain the value proposition for the client. But since they are about realization of value, not merely about deployment, they must also contain what is needed for full-value delivery. This includes what would be required for ops, marketing, support and anything else needed. In addition, any adverse affect an MBI may have on existing functionality must be incorporated into the MBI about to be built and not thrown over the fence to those who built the affected code. The importance of MBIs cannot be overstated. The most effective way to lower cost of delay is to manifest value in small chunks. This also increases the efficiency of the development group. Consider the case where a team has three enhancements, each taking the same amount of time and each having the same importance. The quickest way to achieve value is if they work on one enhancement at a time, complete it, and then go on to the next. But they will very often be forced to start on all three. Figure 6 compares two scenarios of when work is done and when value is realized.
The interesting thing is that even if the Product Owners for A, B and C know that A is more important than C, it is likely they won’t have the team do them in the optimal order. But let’s say A, B and C can be sub-divided into MBIs. This enables the team to work on smaller enhancements and increase value manifestation even more. It also makes it easier to get the Product Owners to agree to the work being done serially. This is shown in Figure 7.
Figure 9 illustrates how MBIs fit into the value stream from strategies to stories.
What happened to Epics, MVPs, and MMFs?Notice 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 as shown in figure 8. 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. Why this is importantThis 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. Sequencing the workWork must be sequenced, not prioritized. Everything can be important but to resolve disagreements on importance when the work hits the teams and there is a conflict people at all levels need to understand which MBI is more important than the other. Don Reinertsen suggests, “If you quantify one thing quantify cost of delay.” His weighted shortest job first (WSJF) can be used to sequence work in a manner that will maximize the return. While WSJF can be used before MBIs are well-formed, the portfolio backlog should be on MBIs. Doing WSJF on epics means you’ll be sequencing based on epics that contain some work that is not essential to more important work. You don’t want the most important part of an epic for which value can be realize early to hold up for lesser important aspects of the epic. The best way to achieve this is to use Acceptance Test-Driven Development using Behavioral-Driven Development. 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.
New rolesThe role of the Product Manager has been around for over a decade. It is not always needed, however. Product managers are usually needed when multiple stakeholders are present and most have to use multiple teams driven by different Product Owners.
The role of the Business Architect is virtually missing in Agile. But even at small-scale the role is critical. A business architect is a practitioner of business architecture, a discipline concerned with developing and maintaining business capabilities of the enterprise in line with the corporate strategy as well as contributing to the business strategy and plans. In FLEX the business architect has the critical role of determining if one MBI will affect existing capabilities. Have a well-defined intake process and Planning EventsHaving a well defined intake process is essential. Otherwise people will be interrupted by requests for work that was not evaluated compared to other work, but mostly on the whim of management. A well-defined intake process also requires a method for starting new work. This can be done via a pull mechanism as teams are available. This would be similar to Scrum but having the team of teams that is needed to get the work done pulling from the product backlog. Most often, however, it is more effective (at least at the beginning of the adoption) to have a planning event where work is pulled and planned as a group. This is not unlike planning a sprint, but at a larger scale. And it has somewhat the same effect – it limits WIP at a high-level but can be improved by attending to lower levels as well. A way to manage WIP at the team level is to attend to dependencies and how teams collaborate. Focus on managing how many MBIs, Features and stories are active at the team level. Planning events can be useful for this because they are really about collaboration and dependency management more than creating the plan itself. There are three common patterns we’ve seen. They are correlated more with how the talent is organized than the size of the organization. Regularly scheduled Planning Events. At the end or a program increment have a planning event with all the trains involved. At small to mid-scale, however, these may not be necessary. This is especially true when most of the work is contained within a team or within groups of two or three teams. Planning Event to kick things off and then manage dependencies at the synchronization points. When teams are mostly independent this can work pretty well. Have an initial planning event to get all dependencies mapped and an agreement on how to collaboration. But moving forward, just manage dependencies with a flow model. This approach can work up to 30-50 teams even when some of the teams create platforms for the others. No Planning Event. At small-scale Planning events may not be needed. Instead, it may be sufficient to use shared backlogs across two to ten teams as long as there are agreements on how they need to work together.
Implementation and integrationTeams must work together on a common cadence – starting and stopping at the same time. This enables teams to integrate, if not continuously, at least at the end of each iteration or cadence. DevOps must also be used to ensure smooth delivery. Organizing the talentThere are many ways to organize your talent. Cross-functional teams are best, but often can’t or are too costly to be achieved. It is important to understand why cross-functional teams are so effective even if you can’t achieve them.
DevOps
Release and realizationDelays waiting for software to be deployed and or realized are just as bad as delays anywhere else. It is important to not have missing pieces for realization to be discovered at the end. While DevOps attends to this, one of the uses of MBIs is that they include anything needed in order to actually realize value (e.g., marketing, support). Other FactorsThe role of leadership, management and systems thinkingLeadership and management play an important role at all scales. While being a servant leader is important, it is also important to hold the big view of the organization. In essence the purpose of leadership is to create the direction the organization is moving in The purpose of management is create an organization in which the development/IT organization can autonomously implement this vision. This respects the ability of workers to self-direct and self-organize while creating an effective eco-system within which they can work. This is called Middle-Up-Down Management.
Improving your company’s cultureOrganizational culture eats strategy for breakfast and dinner. Peter Drucker Agile and culture Agile is intended to create a new culture. Many agilists talk about being Agile instead of doing Agile. The challenge is that it is difficult to change one’s being. While trust and respect is a key value of Agile, it should be a key value for every approach. The question isn’t if trust and respect is a good idea, it’s a question of how do you create it if the culture isn’t already demonstrating it. Collaboration and alignmentHaving agreements on how people throughout the organization is critical. In all too man organizations these agreements are tantamount to “let’s follow SAFe” (or substitute your favorite framework). This takes our eyes off the real target (the quick realization of value predictably, sustainably and with high quality) while increasing the occurrence of dogma. Consider the differences between SAFe’s big picture figure 5. Imagine that you were a person 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. By tying each sub-component in the hierarchy back to its parent, it is possible for everyone to see what MBI each sub-component is tied to. This provides critical information when a conflict of capacity occurs. This also creates alignment.
Although SAFe describes roles and there are many agreements between the roles, agreements based on “follow SAFe” leads to dogma. We have found an effective way to get alignment is to make some basic agreements. We call these the guardrails. The GuardrailsWe agree to:
The first one around focusing on business value is critical. We have found that the best way to align is around the purpose of the organization and focusing directly on the goal of achieving business agility When one thinks about it, that is virtually the only thing on which you can align. People can be at a company for any number of reasons. It may be a short-time gig for experience, they need the money, their significant other is there, who knows. But if they aren’t working in alignment with the purpose of the company they shouldn’t be there. It really is as simple as that. Collaboration and Dependency ManagementHow teams at small-scale collaborate depends upon what the teams are responsible for. There are several situations at small-scale that require different solutions. No matter how 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.
Starting a Lean-Agile Adoption at small to mid-scaleStarting an adoption of Lean-Agile should almost always start as early in the value stream as possible. The reason for this is that actions taken upstream have a direct impact on downstream activities. For example, having business stakeholders request smaller batches of work be done will make it easier to build things quickly and stay out of chaos. Eli Goldratt (the creator of Theory of Constraints, the concepts of which are embedded in most Agile methods) once remarked- “Often reducing batch size is all it takes to bring a system back into control. DevOps is another example – developers working with ops helps operations. While no two approaches are exactly they same, most follow this general outline:
All of this can be accomplished with four days of small workshops for leadership, management, Product Owners, RTEs and Scrum Masters and Scrum/Kanban with Agile Requirements: Achieving Sustainable Agility. The later course should be attended by product owners, RTEs, Scrum Masters and the development team (including testers) and can accommodate up to 75 people. Learning together is the best way to start working together. Acceptance Test-Driven Development should be taught up-frontTwo of the ubiquitous challenges facing software development organizations (product or IT) are:
Acceptance Test-Driven Development (ATDD) is specifically designed to solve both of these challenges. ATDD is the process of product owners, developers and testers discussing requirements together prior to writing any code. There are three phases to this: discovery, specification and automation. Learning the first two phases of ATDD only takes 2-3 days. It helps clarify requirements as well as improving the design of the code.
Deciding what to doIt 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-scaleIf 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-scaleAt mid-scale there are more options:
Not using SAFeAt 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 ManagementIf 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 ManagementIf 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. Starting the adoption of SAFe at small to mid-scaleSAFe training is designed for companies that have 50 or more people in technology. Even up to a company with several hundred people in technology, most people adopting SAFe use the Essential SAFe level. The challenge with taking Implementing SAFe (the four-day SPC class) is that half of it is geared for larger organizations. And what is relevant is covered within the context of a larger organization. Not to mention that as SAFe as gotten more complex many things useful to small companies (e.g., Agile Architecture, Kanban at shared services) are no longer discussed. Also, to get your certification requires hours and hours of study on materials that are not relevant to you or your company. Leading SAFe is shorter but covers the same material. Because the practices previously described are designed for small to mid-scale, it is fairly straightforward to implement at least all of those under the “strategic planning” level. Adopting this approach would require:
All of this can be accomplished with four days of small workshops for leadership, management, Product Owners, RTEs and Scrum Masters and one of the following courses:
Either course should be attended by product owners, RTEs, Scrum Masters and the development team (including testers) and can accommodate up to 75 people. Learning together is the best way to start working together. It is highly recommended that the ATDD course with SAFe be taken since ATDD is an invaluable skill. Summary
Absorb what is useful, reject what is useless, add what is specifically your own. – Bruce Lee Using Essential SAFe for small to mid-scale at first appears attractive. However, as you realize what’s not in it that’s needed and how much of it is for the context of a program in a large organization, not a “program” that represents the entire company, it becomes clear it’s not always a good choice. Building off of proven patterns of success and challenge enable your organization to use existing methods that are tailored to your needs. By using a “framework” that provides guidance on how to make decisions you can move more quickly than trying to follow a framework that was designed for everyone. 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 much of this presentation go here. |
Please read 
Watch a recording of Al Shalloway’s Agile 2018 presentation 
