Adopting SAFe at Small- or Medium- Scale

This is a chapter from Al Shalloway's upcoming book Achieving Business Agility at Small to Mid-Scale: A Guide to Enterprise Effectiveness with Lean-Thinking and Lean-Agile Patterns

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.

• Introduction
• The challenge of Essential SAFe
• A visual perspective of SAFe
• Overcoming the SAFe dilemma at small- to mid-scale
• What’s missing
• What’s needed at small- to mid-scale
• Starting the adoption of SAFe at small- to mid-scale
• Conclusion

Introduction

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.

The challenge of Essential SAFe

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.

• The planning pace for SAFe is two to three months. At the small-scale, it is more reasonable and Agile to plan one to two months ahead.
• Different type of organizations often require different methods of planning
• Having an innovation and planning iteration should not be required at small- to mid-scale (not to mention that the cost of it would be proportionately long given the shorter planning increments.
• Many concepts needed at small- to mid-scale are not in Essential SAFe (in particular, how to go from strategy to the product backlog)

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.

A visual perspective of SAFe

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.

Figure 1: SAFe depicted as a value stream

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.

Figure 2: FLEX’s depiction of the value stream

There is a, subtle, but significant difference between these two diagrams that is significant. . 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.

Overcoming the SAFe dilemma at small scale

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.

The 10 Essential Elements of SAFe:

1. Lean-Agile Principles
2. Real Agile Teams and Trains
3. Cadence and Synchronization
4. PI Planning
5. DevOps and Releasability
6. System Demo
7. Inspect and Adapt
8. IP Iteration
9. Architectural Runway
10. Lean-Agile Leadership

Let’s quickly go through this list:

Lean-Agile Principles. About 80% of SAFe’s Lean principles are taken from, and mostly consistent with Don Reinertsen’s Principles of Product Development Flow. A significant exception is Set-Based Concurrent Engineering which Mr Reinertsen discusses in principle E19: The Insurance Principle: Don’t pay more for insurance than the expected loss.

Real Agile Teams and Trains. (modification most likely required). Having real teams is always a great idea. Sometimes, even in small- to mid-scale organizations, achieving them is neither possible or even ideal. This is why Kanban is so useful when true teams cannot be created. Trains at small-scale make sense at times and not others. SAFe says the purpose of an Agile Release Train is to “align teams to a common business and technology mission. Each is a virtual organization (typically 50 – 125 people) that plans, commits, develops and deploys together.” While teams in small-scale may work together they mostly just have dependencies on each other while working on their own backlogs.

Cadence and Synchronization. Having teams work together in a common cadence while synchronizing on a regular basis is a requirement for having related teams be able to collaborate well.

PI Planning. (modification required).  The obvious difference is the planning time frame for small- to mid-scale organizations should be 2-6 weeks not 2-3 months. But in addition to that, program increment planning in small- to mid-size organizations can be done in different ways depending upon the way the teams work together.

DevOps and Releasability. DevOps is a critical part of business agility since the goal is realization of business value, not mere deployment.

System Demo. When more than one team is developing something, what is being built across all of the teams should be demoed on a frequent basis.

Inspect and Adapt. A cornerstone of Lean and Agile is continuously improvement. SAFe’s I&A approach is very effective for groups working together to make adjustments. While

Innovation & Planning Iteration (not needed). While an IP may be useful at large-scale there are several reasons they are not advisable at small- to mid-scale. First, if program increments are 6 weeks in length a 2 week IP would be too costly to have. Second, they should not be required in small companies where innovation should be able to be done on a more continual basis. And finally, the reason they are often, albeit aren’t supposed to be, used is as a kind of buffer. At smaller scale it is easier to see where people are and adjust most quickly.

Architectural Runway (more needed). Attending to architecture in an Agile environment is very important. But SAFe’s Architectural Runway has never been fully explored and actually is incomplete even for small- to mid-scale.

Lean-Agile Leadership (more needed).  Although alluded to in SAFe, little actual guidance is provided. 

What’s Missing

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.

• It adds value for the customers of the business.
• It provides valuable feedback that the right functionality is being built.
• It provides valuable feedback that the functionality is being built the right way.
• It provides functionality that can be verified as an increment that can be delivered.
• It enhances the ability of the organization to deliver value in the future.

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:

• unclear requirements
• keeping developers and testers working together

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.

What’s needed at small- to mid-scale

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.

Figure 3: What’s needed at small- to mid-scale

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.

Strategic Planning

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, no where 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:

• adds value for the customers of the business
• provides valuable feedback that the right functionality is being built
• provides valuable feedback that the functionality is being built the right way
• provides functionality that can be verified as an increment that can be delivered
• enhances the ability of the organization to deliver value in the future

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).

New Roles

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 togetherfor more.

Implementation and Integration

SAFe provides little new here and their practices are essentially clear descriptions of others’ methods. The key practices are:

• teams work on the same cadence in a synchronized manner
• system demos are done on a frequent basis
• DevOps is used to ensure smooth delivery

DevOps

• 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.
• There are two challenges in the communications between development and operations. The first is that the intense focus of Agile 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 seventh principle, “Working software is the primary measure of progress,” sometimes has teams forget that 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.

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.

See Leadership and Management for more or watch a recording of Al Shalloway’s Agile 2018 presentation Lean Leadership and Systems Thinking.

Improving Your Company’s Culture

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.

The Guardrails

We agree to:

• Work on items that will realize the greatest amount of Business valueacross the enterprise.
• Collaboratewith each other in order to maximize the realization of Business value across the enterprise.
• Ensure that all work will be made
• Take the necessary steps to sustain or increase predictability.
• Keep the work throughout the value stream within capacity.
• Encourage everyone to strive for continuous improvement.

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.

Starting the adoption of SAFe at small- to mid-scale

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:

1. Leadership and management take a short workshop to learn the basics of SAFe at small-scale.
2. Their Product Owners learn Agile Product Management.
3. Their one or two Release Train Engineers(RTEs) get up to speed.
4. Their teams learn Essential SAFe.
5. Their teams learn Scrum if they do not already know Scrum.

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:

• Acceptance Test-Driven Development course with SAFe(3.5 days if don’t need Scrum, 4.5 days if you do)
• SAFe For Agile Release Trains (2 days) (not affiliated with SAI).

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.

Conclusion

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., except for being a bronze partner. None of the services mentioned here carry Scaled Agile certification or endorsement.