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

This is a chapter from my upcoming online book Simplifying SAFe? With FLEX: An Enhanced Approach to Achieving Business Agility. FLEX is Net Objectives' Lean-Agile approach to helping organizations improve at all levels. While FLEX stands on its own, this book explains how to use it to enhance while simplifying SAFe. Feedback is requested either here on a user group I've set up for the purpose. I am also leading an online workshop starting in mid-January on FLEX that will include how to use it with SAFe. You can see more on linkedin by going to the Table of Contents.

Absorb what is useful, reject what is useless, add what is specifically your own. – Bruce Lee`

Essential SAFe is intended to take a program in a large organization and get it started with SAFe. This is definitely easier to do than starting further up the value stream with stakeholders and product managers. But easier is not necessarily better. In fact, the common adage “go for low hanging fruit first” often makes getting the real jewels at the top of the tree harder to get to.

The Risk of Using Essential SAFe at Large-Scale.

Using Essential SAFe at large scale means you are firing up programs in a large organization. This may or may not be a good first step. Definitely easier. But may not really address the issues at hand. Many large organizations’ real problems have more to do with product management, however. Starting with Essential SAFe may be a decent first step, but don’t consider it adopting SAFe.

Often the real challenge organizations face is that programs are overloaded with work because management above the program level cannot decide on how to sequence their work and demand more to be worked on than should be. Essential SAFe, however, does help create an intake process that may help improve this since the teams should only pull the amount of work that they can handle. But if the real issues isn’t addressed, at some point demands on production will likely occur. Even if they don’t, great opportunity is being lost in any event.

Starting at the program level sometimes lulls executives into thinking they are now “doing SAFe” and don’t have to change their methods. While some value has been achieved and even open doors for new improvement, it more often tends to lead to stagnation because something has been accomplished – even if it’s not the true problem.

If you’ve been around the Agile world long enough you’ve likely seen something similar to this with Scrum. Many organizations adopted Scrum by putting together a few cross-functional teams. Adopting Scrum in this way is relatively easy because we took the teams out of the normal environment and created one within which Scrum works well. And it can achieve great results. We have found that cross-functional teams working together are 3-10 times more productive than teams siloed and scattered throughout an organization.

But doing this often doesn’t address the real issues of what is to be worked on and how teams work together. A bigger view is needed.

In many ways, the adoption of Essential SAFe has a similar pattern. There are now reasonably effective programs but business stakeholders have not figured out how to feed the programs correctly. In both cases we’ve found that a driving from business value approach to work much better than the organic growth from the bottom. Be clear that driving from business value does not imply in any manner that we’re taking a top-down management approach.

The challenge of using Essential SAFe at Small to Mid-scale

Essential SAFe is focused on the programs in a large organization. That being said, there are several practices of Essential SAFe that are useful for small to mid-scale. In particular the program increment (although it usually can be shorter than 8-14 weeks), the program increment planning event, the concept of an Agile Release Train and its corresponding RTE (release train engineer), the use of Lean principles and purportedly being driven by Cost of Delay.

That being said, a program in a large organization is quite different from when a small company’s technology group is comprised of just one, or even a few, programs.

The Risk of Using Essential SAFe at Mid-Scale. The risks here are mostly in the area of lost opportunity. While large scale organizations don’t require the complexity of SAFe the value received by having any consistency in product management may be worth it. However, at midscale, it is much easier to adopt better lean portfolio and product management. This will be the topic of the Enhancing while Simplifying SAFe with Lean Product Management chapter later in this book.

The Risk of Using Essential SAFe at Small-Scale.  The risks here are two-fold. First, Essential SAFe was not designed for small-scale and is by its nature way more complicated and heavy than needed. Even if program increments are shortened to a more reasonable length (2-4 weeks), the complexity remains. On the other hand, small companies still need Lean portfolio and product management. Essential SAFe doesn’t really talk about this. If you try to bring it in by using what’s in the higher levels, you’ll increase complexity even more.

Using Essential SAFe here means you will have both more and less than you need. However, understanding how Essential SAFe ale can be used as a basis for the implementation while layering a better (small-scale) Lean portfolio and product management system on top of it is very useful.

The challenge of Essential SAFe at Any Scale

Essential SAFe is a method of trying to simplify SAFe. While that is a good intention, it doesn’t follow systems thinking which tells us to look at the system as a whole. Simplifying SAFe would require to still look at the organization as a whole but be more focused on what it is attempting to do. This is one of the reasons we suggest Looking at Your Work From a Value Stream Perspective. Even if we focus on the programs we must consider how they fit in with the rest of the organization.

Essential SAFe was designed for programs in large 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 face a different set of challenges than the ARTs that are in small to mid-scale organizations.

Essential SAFe, being designed for a program within a large organization, has the same practices regarding program increments and architecture as present in large organizations. However, these issues at small to mid-scale are different in both pace and in needing a full portfolio and product management solution. Essential SAF therefore needs to be tailored for the size of the organization adopting SAFe.

Tailoring Essential SAFe for small to mid-scale organizations

Some of SAFe’s practices need to be modified for small to mid-scale companies adopting it. This includes:

• The planning pace for SAFe is two to three months. At smaller scales, 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
• Attempting to get what’s missing in Essential SAFe from the higher levels adds to the complexity of SAFe for small to mid-scale organizations.

Essential SAFe Leaves Out Concepts Needed at Small to Mid-Scale

To best see this, take a look at SAFe’s Big Picture. Click on ‘Essential SAFe’ and familiarize yourself with it. Now click on ‘Full SAFe.’ Now go back to ‘Essential SAFe.’ You’ll notice that if you click on Enterprise, Solution, or a number of other icons on the Essential SAFe picture, the description lies in the higher levels of SAFe. These concepts still apply, but are not needed at the level of complexity they are in big organizations.

Even small companies have the issue of portfolio management, identifying the work to be done and managing their work-in-process. It just happens on a different time frame and with fewer people. SAFe’s portfolio management, designed for large organizations, is overly complex for small ones and is left out of Essential SAFe in any event. Part 5: Essential SAFe with FLEX will fill in these gaps.

Essential SAFe’s Choices for Agile portfolio management are not effective

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 later in Part 5 when we show how to overlay a simple, effective, Lean portfolio and product management method on top of Essential SAFe.

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.

Essential SAFe at a Program in Large-Scale

Many large companies are adopting Essential SAFe for their programs because they find the higher levels too complex. The challenge is that for many of these organizations, the real challenges lie at budgeting and getting agreement across programs.

Using Essential SAFe for programs at large-scale makes sense as a way to start SAFe. But one must be clear that by doing so, one is solving the problem of the program and not a problem that most larger organizations have – how do you feed programs work and how do they interact with each other.

This is not unlike when Scrum teams were started in organizations whose real challenges weren’t the teams themselves but how they could work together. Essential SAFe solves this problem one level up – but typically it is not the key problem to solve. One again needs to start higher up.

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

Don’t Fall Into the “That’s How We’ve Always Done it Trap”

You’ve probably heard the anecdote about a young woman, preparing for a family get together, asking her mom why she cut off the ends of the roast before putting it in the oven. Her mom responded – “I don’t know, my mom always did it that way so I copied her. Why don’t you ask her tonight?” So that evening the young woman asked her grandmother about it and she responded “because the roast wouldn’t fit in my pan if I didn’t do that.”

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 always take a bottom up approach, the vestiges of how it has evolved are still apparent.

Our experience is that it’s better to decide where to start by first looking at where an organization’s challenges are and looking to see what will have the best long range impact.

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.

A Word On SAFe Training at Small to Mid-Scale

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 after the class is not as attractive the materials are not focused on the needs of the organization and some of the advanced courses are not relevant – so few pertinent courses are available.

The most important aspect of a workshop should be how people work together with their associates and be oriented around:

1) the context of the people being trained

2) increasing collaboration

3) learning by doing actual work

4) needed essential skills

Training in frameworks is important. But when people are given the skills they need from the start, less knowledge of the framework is needed to move forward. This is especially true when these essential skills are learned together. Not having these essential skills leaves them unprepared & often causes resistance to the framework, which, by itself, is not helping.

Unfortunately, this type of training cannot be done with certification, since certification requires a focus on the framework. But what’s required is less framework and more how to do the work. Fortunately, there are many qualified, non-certified trainers out there who are more concerned with you getting what you need.

I will be leading an online course on FLEX beginning in mid-January. It will cover all of FLEX, including the content regarding SAFe in this book. It's the equivalent of a 4-day course for only $795. Message me if interested