Overview of Essential SAFe

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.

The 4 Levels of SAFe

There are four levels of the Scaled Agile Framework. Each one builds on the next and is intended for different scales. It is important to understand how different scales are different from each other, how each SAFe level helps adapting SAFe but also creates a new set of challenges.

SAFe is intended for large organizations. The levels are provided so that a subset of an organization can use SAFe as appropriate.

From the Scaled Agile Framework big picture:

• Essential SAFe is most basic configuration of the framework and it provides the minimal elements necessary to be successful with SAFe.
• Large Solution SAFe is for enterprises that are building large and complex solutions, which do not require the constructs of the portfolio level.
• Portfolio Portfolio SAFe provides portfolio strategy and investment funding, Agile portfolio operations, and Lean governance.
• 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.

Since the reader presumably has an interest in using SAFe, we will use Essential SAFe as the backbone of our approach for the small to mid-scale. It is therefore important to understand the essential elements of Essential SAFe. Click here to go to SAFe's own article on these elements.

Essential SAFe is designed to be used at the program level for one or more Agile Release Trains in a large organization. In a nutshell, it provides us a way to have teams in an ART plan and work together. This is good. The core practices we want to adopt from Essential SAFe is:

• an awareness of Lean principles
• new roles required for scale
• the program increment planning event
• working in cadence with synchronization
• DevOps
• working with shared services

This core is a useful one to build on. But we'll see that Essential SAFe is both too much and not enough at the same time.

Looking at Essential SAFe from the Value Stream Perspective

The figure below shows our representation of what's needed to attend to in virtually any value stream.

Let's go through each of these and see how Essential SAFe provides many of those on the bottom level.

Strategic Planning and Lean Portfolio Management

This is not part of Essential SAFe even though it is required in all companies. In large organizations Essential SAFe is used to kick off programs without having to work at this level. However, small and mid-size organizations can solve their challenges here with a much easier solution than what SAFe provides. We'll learn how to do this in part 6 of this book: Starting and Continuing a Lean-Agile Adoption of Essential SAFe With FLEX as a Guide.

Lean Product Management

This is where our initiatives get turned into work that is provided the development teams to plan and implement. It has four key aspects:

• refining the product backlog
• use Acceptance Test-Driven Development to get clear requirements
• have a well-defined product backlog that can be used to control the intake process

Refining the Product Backlog

The purpose of backlog refinement is to decompose our business initiatives into smaller pieces that have clear requirements. This has three main aspects to it:

1. what are you starting with?
2. how do you do the decomposition?
3. what do you end up with?

SAFe has us start with MVPs. I'll discuss later that this is not always useful. But for now it is sufficient to realize that what we need to do is go from a something large to something more focused

There are several different methods of doing decomposition. As we decompose our chunks of work to be done we need to attend to:

• which parts are actually needed (we may not need to build all of it)
• making the requirements clear
• validating that we're planning to build the right thing

We have found that a lightweight method of Acceptance Test-Driven Development is essential for this. We don't need to automate the tests (although we highly recommend that you do so). But at least we must do the discovery and specification stages of ATDD.

What we want to end up with is not just features and stories, but just those parts of features and stories that we need to build for the business value we're trying to implement. For example we will have features we need to build for an MVP. But, given the scope of the MVP is limited, we must ensure we only build that part of the feature needed to validate the MVP.

Planning

One should consider the SAFe planning event as a means of establishing what's going to be worked on over a set period of time, what the relative priority of these items are and how the teams will work together. 

SAFe's planning event is brilliant, but not the only way to accomplish this. I'll provide other methods in the Planning, Collaboration, and Dependency Management chapter. 

Implementation and Integration

SAFe's implementation and integration method is based building across teams in program increments. This is comparable to a Scrum team's sprint. And, in the same way a flow model via Kanban can be used at the team, Lean methods can be provided that create greater agility at the program level. 

Release

SAFe suggests that we build on cadence and release on demand. This requires DevOps as well as integrating any non-software components into the release plan. These include marketing, support, maintenance and a few more. 

[/multi-column]