The DA FLEX Playbook for SAFe is a set of essential concepts and required actions that will improve your SAFe adoption. Much of the playbook is in this video.  Pdf for talk

The DA FLEX Playbook for SAFe

SAFe is the leading approach to achieve Agile at scale. Few achieve true agility with SAFe. Most would argue that three month planning events are, by definition, not Agile. But many organizations do achieve  some improvement using SAFe. Unfortunately, depending upon who you talk to, many, if not most, find these improvements short-lived. It is not uncommon to hear stories about organizations attempting to implement SAFe several times, over several years.

But dismissing SAFe is a mistake. Clearly companies are finding value in it. Asking these questions is useful:

• what does SAFe do that provides improvement?
• what does SAFe not do that is needed for improvement?
• what can we add to or remove from SAFe to improve an organization’s results with it (this will be presented as the FLEX SAFe playbook).

What Does SAFe Provide?

The Agile Manifesto is very team centric and doesn’t mention management even once. Agile at scale must fill this void, whatever approach it takes.  Take a quick look at figure 1.

Here’s a summary of what’s listed in the figure.

• The product manager role is essential when products are competing for capacity or require shared services.
• The RTE is needed to provide the larger perspective of the team, not merely the team. Coordinating teams as a Scrum of Scrum has a history of challenge.
• An intake process is required to control what gets onto the program backlog.  This facilitates working on items of higher value.
• A program backlog is needed to coordinate the work of the teams
• Lean is required at scale
• Effective leadership is essential
• Quality technical practices, such as ATDD, which are even more important at scale.
• DevOps is an essential part of Lean-Agile delivery
• Shared services can be managed effectively with kanban.
• Teams working in a common cadence with frequent synchronization can coordinate and unblock them.
• A delivery pipeline focused on value to the customer across the teams of the train is essential
• Effective teams are needed so they can coordinate their work efficiently.

Most of these concepts are not provided in Scrum. This has provided a natural path for those doing Scrum to move to SAFe. All of what they are trying to achieve is important. While there are better ways to achieve these, especially if the development group is less than 400 people, not dealing with them at all is problematic.

Still problematic

While SAFe may unblock organizations that can’t get teams to collaborate well, the focus is mostly on managing dependencies. SAFe also uses old-school thinking on product management while redefining terms to make it look cutting edge.  These include:

1. The MVP which was intended for discovering the viability of new products by a team, not enhancing existing ones. And was certainly never intended to be used in a 3 month program increment.
2. The MMF (Software by Numbers) which was about organizing functionality into releasable chunks. UX is not discussed in Software by Numbers and MMFs are mentioned in Lean-UX, but somehow that inference is made in SAFe.

What’s needed is an artifact that can be used to define slices of functionality at scale.  The minimum business increment, developed by Net Objectives and now incorporated into Disciplined Agile, provides the insights needed here.

A mechanism to go beyond managing dependencies is needed. Agile Release Trains of more than fifty are usually anything but Agile.

These, and other concepts will be introduced in the playbook section.

What Does SAFe Not Provide?

Organizations adopting SAFe often experience a plateau and even falling back of progress. This is not due to them as much as concepts missing from SAFe or people not adopting SAFe’s higher levels due to their complexity. The bottom line, SAFe is missing concepts and actions required for sustainability.

Consider what’s available at the higher levels circled in Figure 2. Without these concepts portfolio management can’t be done. The adoption of SAFe for most organizations is merely a way to get a collection of teams to manage their dependencies. What’s needed is a focus on value and a better way of organizing the teams to work effectively together.

The Specifics of SAFe Stagnation

A little understanding of Lean provides deep insights into why SAFe stagnate.  Lean suggests that when people are over-worked, their efficiency goes down while the amount of rework required goes up.   See Why Looking at Delays in the Value Stream Is So Important for more.

Two factors are the primary reason SAFe provides benefits to organizations. The first is that SAFe uses a pull mechanism in their program increment planning event. “Pull” means that teams decide how much work they can accomplish. That is, product managers and product owners don’t get to push work onto the teams. This alone would result in increased productivity. By combining it with a planning event to identify and manage dependencies, a lot of workload in the form of rework goes away. More useful things get done by teams that are not over-burdened.

Companies adopting SAFe are usually pretty good about allowing teams to pull the work for the first couple of program increments. But after that, one of two things tends to happen.  The first is the loss of using pull as a planning method. Fort he first couple of program increments product managers tend to be on their best behavior. They don’t truly understand the need for pull (teams deciding how much work they are going to do) but they understand they are not supposed to tel the teams how much to do. So they abide by the rules while the organization “adopts SAFe.” But after a couple of program increments, their patience often wears out. The thought process is that the organization has adopted SAFe and that the teams need to do more. The program increment planning event becomes somewhat as much of a push method as before. While coordination is still better, overloading teams results in significant rework and slows things down. This merely adds to the push.

A second reason is that management changes and the new leader does not appreciate why program increments are important.  S/he just wants more.

The DA FLEX Playbook for SAFe

The DA FLEX Playbook for SAFe is designed for those who have started with SAFe and want to improve and accelerate their gains or get out of the stagnation many fall into. The playbook walks participants through a step-by-step process of improving any SAFe implementation. It builds off the progress that has been made while providing concepts missing in SAFe that are essential at scale. These concepts are then used in ‘plays’ to improve your implementation.

These plays enable an Essential SAFe implementation to expand to the portfolio without having to resort to SAFe’s complicate portfolio level. A more effective yet simpler way to cover the entire value stream.

The FLEX Playbook is designed to be implemented in 4 overlapping phases.  This enables you to control your rate of change while tailoring it for your needs. The result is a simpler, more effective approach. The playbook’s effectiveness has been demonstrated by a several SAFe consultants who have taken these ideas from Net Objectives or Lean and applied them on their own.

The playbook has four stages which can be done sequentially or overlapped for faster adoption.

1. Improve in place
2. Restructure teams within the program and shorten the time of the increment planned for
3. Align teams to business stakeholders and implement agile budgeting
4. Lean management and guided continuous improvement

The interrelatedness of the phases

Each phase sets up the next. However, an organization does not need to finish one phase before going on to the next. Usually the next phase can be started before the current phase is completed.

Phase 1: Improve in place

Use new FLEX concepts and a few plays to improve SAFe’s core practices.

1. The FLEX Playbook Approach. The playbook provides an overview of how to apply plays to an existing SAFe implementation to improve it.
2. Understanding Our Inherent Problem. We typically manage in a hierarchical structure but our work flows across the organization. All Agile at scale approaches must deal with this challenge. It sets the stage for how the business organization and development/service organization must have different structures.
3. View SAFe from a value stream perspective.  In this topic, we present SAFe from the perspective of the value stream. It enables one  to see the delays, handoffs, handbacks and poor process present. This perspective enables better decisions on how to improve the workflow. This includes attending to the inherent problem of hierarchy vs value stream. Note: The term ‘value stream’ here used Lean’s definition which has a value stream refer to the workflow.  SAFe’s “long lived value streams” refers to stable teams working on related value streams. To avoid confusion I refer to value streams with stable teams working on them as “value streams with long lived teams.”
4. Showing the what and why of the DA FLEX Plays on the SAFe Value Stream coming.
5. The Minimum Business Increments (MBI). MBIs are the smallest increment of business/customer value that can be created and delivered to customers for which they can realize value. MBIs are a critical artifact in that can be used to define releases. They can be used to simplify portfolio and product development.
6. Play: Use MBIs in product management. MBIs contain all the information required to build a new capability that requires multiple teams or ARTs.  It can act as a coordinating artifact.
7. How to map your value stream and why it’s so important to do so.  Value streams mapping can be used to identify most of the challenges you face.  See Value stream mapping  and Why Looking at Delays in the Value Stream Is So Important.
8. Play: Adopt true ATDD / BDD.  If you haven’t adopted ATDD or BDD yet, now is the time. If you have, make sure you have learned how product owners, developers and testers do it together. SAFe’s training does not require the involvement of product owners, which diminishes its value.
9. Play: Improve the program increment planning event using MBIs and focusing on dependencies.  Also, look for improving the allocation of people to the workflows. See Running Effective Planning Events
10. Play: Have shared services work as a professional service provider. Many times the best way for shared services to support teams is to loan people to them for the duration of a value stream.
11. Play: Improve cross-functionality of teams. After a planning event, the combination of dependency identification, MBIs and what makes for better teams enables improving the cross-functionality of existing teams even if focused solution teams are not workable yet. See
    Focused Solutions Team below.

Phase 2: Restructure teams within the program and shorten the time of the increment planned for

Use Lean thinking and deep understanding of workflows to decompose ARTs into Focused Solution Teams.

1. The goal is not coordinating teams but the decoupling of teams.
2. The Focused Solution Team. A focused solution team is a group of people organized in sub-teams that have the capability of creating an MBI for a product and are dedicated to working just on the MBI
3. Play: Use focused solution teams to go beyond the initial gains of SAFe. FSTs enable reducing dependencies between teams, shorter planning cycles and an alignment of people to products. This and the earlier step of adopting ATDD/BDD often go well together.
4. Play: Have Shared Services and Enterprise Architecture be provided as Professional Service Providers. Make the development teams be as cross-functional as possible.
5. Play: Shorten Program Increments Over Time. As teams become more decoupled from each other it is possible to have smaller, shorter planning events with fewer teams in each.

Phase 3: Align teams to business stakeholders and implement agile budgeting

1. Play: Use strategies, initiatives and MBIs to implement the higher levels of SAFe in a simpler more effective manner. Many organizations start and stop with Essential SAFe because the higher levels are too complicated to adopt. But the concepts and actions at these higher levels are essential (pun intended) for most organizations, even small ones.  MBIs provide an opportunity to implement the entire value stream, even for smaller organizations,
2. Play Set: Create a network of semi-autonomous, cross-functional team or groups of teams using focused solution teams.
3. Play: Align network to business stakeholders. This implements John Kotter’s dual operating system that SAFe suggests.  To achieve this you need to decompose your ARTs into focused solution teams.  This also allows for Agile budgeting.

Phase 4: Lean Management and Guided Continuous Improvement

Disciplined Agile and FLEX provide guidance via Lean, Flow, Theory of Constraints and other principles that enable adopters of SAFe to refine their implementation. SAFe’s canned solutions regarding train and the formation of who works on value streams is useful as a start but provides less guidance than available to continue improvement.

1. Play: Implement the Disciplined Agile promises. These 7 promises are to be made by all roles in the organization and lay out how people are to work together.
2. The role of management from a Lean perspective. It’s not enough to tell managers they need to support their people, they need to know how to do this in an Agile environment.
3. Play: Guided Continuous Improvement. A quick introduction on how the Disciplined Agile Toolkit can guide organizations further in their journey.

Background / Parallel Learning

The workshop covers the most essential materials concepts needed. However, it can’t cover everything. Fortunately, conveying much of this information can be done via articles and short videos.  See DAVSC Background and Parallel Learning for more useful information to go deeper into the material covered in this workshop.

If You Haven’t Started a SAFe Adoption But Are Considering It

You can jump straight to a Disciplined Agile approach without SAFe, or use SAFe as a backbone while adding many of the concepts and plays / play sets here right from the beginning.  Most important, however, is to recognize that one size does not fit all.   Also, while SAFe typically starts with the teams and then adds levels to them, it’s usually better to start with full value streams.  You can often start with FLEX’s simpler portfolio and product management approach as well. Also, make sure you start with Acceptance Test-Driven Development with product owners, developers and testers collaborating.

If you want to see and share challenges companies are having with SAFe, go to this Dynamics Impediments Board.