Why Essential SAFe is Both More and Less Than You Need at Small to Mid-Scale

Adopting SAFe® at the Small to Mid-Scale (online book)

Sections
  1. Introduction
  2. Understanding Our Problems Before Looking for Solutions
    • The Attraction of SAFe
    • Why Essential SAFe is Both More and Less Than You Need at Small to Mid-Scale
    • The Inherent Problems at Scale
    • Looking at Our Work Through a Value Stream Perspective
  3. Understanding the Essence of SAFe Essentials
  4. Adopting Essential SAFe With FLEX
  5. Starting a Lean-Agile Adoption of Essential SAFe
  6. Appendix
Provide Feedback

The 4 Levels of SAFe

  • Full SAFe represents the most comprehensive configuration. It supports building large, integrated solutions that typically require hundreds of people or more to develop and maintain.
  • Portfolio SAFe provides portfolio strategy and investment funding, Agile portfolio operations, and Lean governance
  • Large Solution SAFe is for enterprises that are building large and complex solutions, which do not require the constructs of the portfolio level
  • Essential SAFe is the most basic configuration of the framework and it provides the minimal elements necessary to be successful with SAFe.

The “catch-22” of Essential SAFe for both small and mid-scale organizations

Essential SAFe, the smallest level of SAFe, was designed for programs within a large organization. This is what might first be considered “mid-scale.”  The challenge is that programs within large organizations are actually just a subset of a the people at a larger scale.

In other words, consider Figure 2.2E and contrast it with 2.3A. While the organization of a program in a large-scale organization at first appears to be what we are calling a “mid-scale” organization, you’ll notice that there are other aspect in 2.2E not present in 2.3A

<<< show shared services across programs …

 

Essential SAFe is usually used for starting a SAFe adoption in a large organization at a program level. While SAFe can be used at the program level alone (basically what Essential SAFe is) it doesn’t address the bigger concerns of how programs interact with each other. There are a different set of issues when it is used at small to mid-scale for programs that are self-standing.

Essential SAFe at a Program in Large-Scale

The history of Agile adoption has a kind of bottom up approach. This is not surprising for two reasons. First, the Agile Manifesto on which most Agile adoptions are based focuses on the team. The second is that SAFe started at the program level because finding people who could work with higher levels of management are difficult to find. While SAFe has grown to no longer take a bottom up approach, the vestiges of how it has evolved are still apparent. And it is important to note that SAFe adoptions challenges are, in some ways, paralleling the challenges that Scrum adopters have had, but at a different scale.

Early adopters of Agile were almost always concentrated at the team. In many of their situations they were able to solve their team challenges. But in just as many organizations, the real challenge present was not at the team. Ironically, team level solutions often left the true challenges of the organizations adopting them with greater difficulties before they started Agile. In particular, this occurred when an organizations true problem was too many projects and siloed skill sets. We saw many companies adopt Agile by creating one off Scrum teams as a way to experiment with Agile. For these companies these were the first time true cross-functional teams existed. We have found that merely creating cross-functional teams will improve productivity by 3 times. If they also adopted Scrum another 3 times improvement could be made. And if they incorporated eXtreme Programming practices even another 3 times performance could be achieved. It is no wonder that Scrum became very popular.

But the problem is in many large organizations, while creating a handful of cross-functional Scrum teams is possible, at some point you can’t continue creating them. Some expertise is needed across more than one team – very often subject matter expertise. This leave those parts of the organization that have adopted Agile to be incredibly productive at the team while the rest of the organization is actually worse off. What’s worse, the ability to actually deliver value doesn’t always go up because the team’s software solution is only part of the overall solution.

Companies adopting Essential SAFe are experiencing a similar set of challenges. While getting programs improved, in large organizations more than one program’s involvement is required. Even when that’s not the case, there are often shared service groups (e.g., business intelligence or component layers) that need to support multiple programs. Without implementing the portfolio layer, these groups can’t know which program has the greater priority. This is especially true when vertical applications drive horizontal platforms as shown in Figure 2.2A

<<< show verticals driving horizontals >>>

Thus, while Essential SAFe is an attractive place to start, it must be recognized that it doesn’t always get at the problem.

Essential SAFe at true Mid-Scale

After reading the prior section it may occur to the reader that then Essential SAFe would be perfect for smaller organizations where the program and the organization are essentially the same. Unfortunately, another set of challenges rears its head in this situation.

Essential SAFe is bigger than needed at mid-scale

Essential SAFe 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 types of organizations often require different methods of planning. The SAFe Program Increment Planning Event is only one of many
  • 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.
  • Essential SAFe does not include what’s required to go from strategy to the product backlog since this is in the higher levels.
  • Taking a sub-set of a system that was designed for larger scale has Essential SAFe miss some concepts described at other levels
  • To get those would be too much 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.

Essential SAFe either ignores Agile portfolio management or is much bigger than is needed.

Essential SAFe has a couple of buttons to imply portfolio and solution management are important at the program level. And, in fact, they are. But Essential SAFe’s guidance here is based on the full SAFe level. These higher levels have grown over time by adding more and more concepts that may be needed at higher levels but are seriously more complex than they need to be at small to mid-scale. Instead of requiring several concepts that comprise overloaded and redefined terms, a simpler Agile product management system is required. This will be discussed in Section 4 of this book.

 

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.

A Word On SAFe Training

All of SAFe’s training is designed around full SAFe. To become a SAFe Program Consultant or SAFe Agilist, one must pass an exam that covers scope well beyond what it needed by small to mid-scale organizations. This means that not all of the time taken for training is useful and takes away from other things that are needed. More importantly, the ability to train with SAFe’s materials is not as attractive there are both fewer trainings needed and the materials are not focused on the needs of the organization.

In Summary

Essential SAFe definitely provides a lot of goodness and is worth both investigating and implementing. But it’s worth noting that Essential SAFe will just provide a backbone for an Agile adoption at both small and mid-scale. There will be practices that need to be adjusted, some discarded and some added.