While there are many practices in SAFe at its program level that are useful for small- to mid-scale organizations (<1000 in technology), Essential SAFe was designed for programs in larger organizations. Essential SAFe is often used by smaller organizations because it has many great practices that are applicable there. But taking a sub-set of a system that was design for larger scale has two overall challenges. First, Essential SAFe does not include what’s required to go from strategy to the product backlog since this is in the higher levels. Second, there are practices suggested by SAFe (e.g., Innovation and Planning Iterations, 8-12 week program increments) that may make sense at large scale but are overly burdensome at small to mid-scale.
This chapter is intended for someone who is considering SAFe® for their small- to mid-scale adoption. It will present the practices of Essential SAFe that are useful at small- to mid-scale while adding a few that are absent. We use SAFe terminology since many people have some familiarity with SAFe.
Outline of chapter
Many 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.
Essential SAFe, the smallest option 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.
Fortunately, what to add, modify or leave out can be guided using Lean-Agile principles – most of which are ironically included in Essential SAFe.
This enables those wanting to use Essential SAFe as a core to have a framework that is effective, efficient and most importantly, is the right for them.
SAFe is most easily understood when it is laid out visually along its core basic workflow path which is also known as the value stream. Value streams always start with an idea to achieve and its achievement (or abandonment). Figure 1 shows this along with the artifacts, activities, and roles of SAFe.
A simpler way to represent this using FLEX’s Agile Product Management approach is shown in Figure 2. Note the use of MBIs which we discuss later in this article.
There is a subtle, but significant difference between these two diagrams that provides the insight required for having a scalable framework. SAFe lays it’s practices and roles out in a manner that is coupled to the organization’s levels. The representation in Figure 2 is laid out in more of a value stream approach. There is no tying roles to levels. This is important because small- to mid-scale organizations have a significantly fewer number of levels than do those at large-scale. What it also means is that SAFe takes a subset of itself to work at smaller scale – the focus becomes on the program part of the value stream. FLEX, on the other hand, always attends to the full value stream, but at smaller scale this naturally becomes simpler.
In this section we’ll look at the 10 Essential Elements of Essential SAFe. We’ll look to see which apply to small- to mid-scale, which don’t, and what’s missing.
Let’s quickly go through this list:
What is the smallest chunk of business value to be realized
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 Minimum Viable Product “MVP” in the way Eric Ries does for developing products for early adopters. MVPs are useful in this situation but are not as applicable to extending existing products. In addition, MVPs call for discovery and quick pivoting which requires a quicker turnaround than the normal three months of the program increment.
A better term is the Minimum Business Increment (MBI). An MBI is the smallest piece of functionality that can be delivered that has value to the business. Here is what that means.
You want to make it the smallest we can so you can deliver it faster. But being a business increment means that it must be defined so that value to the business can be realized, usually by the customers of the business. This means that all aspects of value realization (shared services, marketing, ops, …) must be included in the definition.
The elements of the MBI are present in SAFe but tend to be spread across several concepts: epics (which have been “right-sized”), solutions, capabilities, and value streams. Even at large scale this adds complexity but at small to -mid-scale, it is also unnecessary.
Acceptance Test-Driven Development Should be taught up-front
Two 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. See Benefits of Acceptance Test-Driven Development using Behavior-Driven Development for more.
Figure 3 shows FLEX’s perspective with a few added practices and roles to represent what we’ve learned from Essential SAFe as well as what we know is also required.
We’ll go through each of these in the order they are represented in the value stream (upper left to lower right) and discuss the “Other factors” after them.
See Create Clarity on What Represents Value for the Business and Its Customers before continuing.
Lean-Agile Product Management
Often reducing batch size is all it takes to bring a system back into control. Eli Goldratt
This is where the biggest difference between FLEX and SAFe is. SAFe has grown from the bottom up. As each version has been announced it has added a new concept and/or role to try to manage Agile Product Management at scale. The truth is that a much simpler model is available and works at all scales. At small-scale, however, it is essential because small organizations can’t afford to be over-burdened with complex solutions.
Using Minimum Business Increments (MBIs)
SAFe uses the concepts of solutions, capabilities, MVPs, 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 intention revealing as well as generally useful. An MBI is the smallest piece of functionality that can be delivered that has value to the business in that it:
Obviously MBIs must contain the value proposition for the client. But since they are about realization of value, not mere deployment, they must also contain what’s 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.
(Note: if you are unfamiliar with the concept of MBIs please read the chapter on them now).
The 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. See Product Manager and Product Owner (Case Study) for more.
The role of the Business Architect is virtually missing in Agile and not mentioned in SAFe. 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.
Sequencing the work
SAFe uses solutions to ensure that what is being built will provide value. The concept of the solution is a good one. It is a way to ensure everything that is needed to truly realize value is available. Solutions were developed for providing guidance when multiple ARTs are involved, each with 50 or more people per train. This is not likely to be the case at small-scale where you do not have true trains but rather teams trying to work together.
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 on which to run Weighted Shortest Job First since all of it is required to provide value. Compare this with epics, which often contain parts that are not going to be implemented, and with features, which often do not contain enough value to be delivered.
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 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.
Intake process and Planning Events
SAFe’s Principle #6 is Visualize and limit WIP, reduce batch sizes, and manage queue lengths. The starting point for this is having a well-defined intake process. SAFe accomplishes this with a planning event for the program increment where the amount let into the increment is nor more than what can be accomplished in the increment. 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. While SAFe requires planning events they are not always needed. 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. This is SAFe’s approach. 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 2-3 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, shared backlogs across the 2-10 teams involved, along with agreements on how they need to work together may be sufficient. See Aligning Multiple Teams with Lean-Agile Thinking for more.
See Running Effective Planning Events for more.
Organizing the talent
There 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. See Cross-functional teams: Improving communication between people who work together for more.
Implementation and integration
SAFe provides little new here and their practices are essentially clear descriptions of others’ methods. The key practices are:
Release and realization
Delays 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).
The role of leadership, management and systems thinking
Leadership 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, and although not explicitly called out by SAFe, is the best model to implement SAFe’s management requirements.
Organizational 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 alignment
Having 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.
We have found an effective way to get alignment is to make some basic agreements. We call these the guardrails.
We 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 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. 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.
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.
SAFe 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.
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 truly a good choice.
Disclaimer: Net Objectives is not affiliated with Scaled Agile, Inc. None of the services mentioned here carry Scaled Agile certification or endorsement.