< SAFe From a Value Stream Perspective ToC Part XI: Additional Resources on the Net Objectives Portal >

SAFe is essentially a waterfall planning with a semi-Agile implementation. This doesn’t mean you have to abandon it. Most companies using SAFe have achieved significant improvements from it.

These include:

a well-defined intake process
a business perspective
an holistic, albeit not true systems-thinking, perspective
a method of coordinating teams
implementation or awareness of DevOps
a blend of Scrum and Kanban as needed

This chapter discusses how to make SAFe Agile. It presents two approaches. The first is to use FLEX to warp SAFe. Doing this essentially puts FLEX’s front end onto SAFe’s Essential Configuration and enables SAFe to be Agile by having 1-2 sprint program increments. The second presents small changes you can make while still doing SAFe by the book. It will immediately improve your SAFe adoption by filling in some of its gaps. This also sets the stage for future improvements.

Wrapping SAFe with FLEX

In working with clients, I have seen most of them can take 6 steps that greatly improve their ability to deliver value quickly. These are:

agree to follow the guardrails
FLEX’s Lean Portfolio and Product Management approach to manage the value stream before the work hits the program (i.e., combine it with Essential SAFe). This has us use MBIs instead of MVP/Solutions/Epics (epics can be the term used for business increments if you like) and use. MBIs are one of the most significant concepts in Business Agility but is not explicitly in SAFe.
adopt ATDD up front, not in the second tier of training (not with SAFe’s ASE course but one with Product Owners, developers and testers learning by doing it on their own backlogs together
adjust trains to fit the required flow which enables taking a project to product view
add the role of business architect
take quarterly planning up to a high level (focus on what will be released but do not do story breakdown) while doing detailed planning only 2-4 weeks in advance

We’ll expand on each of these here.

1. Use The Guardrails to create a basis for working together

Without agreements such as the Guardrails, the best you can do is to agree to doing SAFe. But having people work together to “implement SAFe” is a trap for several reasons. First of all it takes your eyes off of your real goal – achieving business Agility. It also makes SAFe a box for your thinking. It’s hard to go outside SAFe when you’ve all agreed to implement it.

2. Use FLEX’s Lean Portfolio and Product Management Approach

Most people who are having success with SAFe are mostly using SAFe at the program level. This part of SAFe can work reasonably well although it still has longer range planning than needed. But, if you are having success with it, there is no reason to change it out. Let’s look at FLEX and SAFe and see how they parallel each other. Figure 1 shows both FLEx and SAFe in an inset.

Essential SAFe and FLEX’s part of the value stream from Planning through Realization of Value are conceptually similar, although FLEX has more flexibility. The suggestion is to take FLEX’s simpler, yet more effective part of the value stream from Strategies to the product backlog and put this in front of SAFe’s Essential configuration as shown in Figure 2 below.

FLEX’s use of a combination of MBIs, MVPs and MVRs provides the concepts that SAFe attempts to achieve with its blend of Epics, MVPs, MMFs and Solutions. However, since FLEX is based on the value stream its concepts apply equally well regardless of scale. SAFe’s portfolio and product management model requires additional roles and concepts as scale increasing.

Essentially we replace SAFe’s levels above the program level with FLEX’s Strategic Planning and Lean Portfolio Management and with FLEX’s Lean Product Management. Using MBIs (and when appropriate MVPs and MVRs) greatly simplifies the entire process of identifying, sizing and sequencing the work to be achieved. And it creates greater visibility on why its important which helps create greater alignment.

3. Adopt ATDD up front

SAFe suggests using ATDD but has two significant problems in its suggestion. First of all, it provides ATDD training to mostly the developers and testers instead of including product owners as a requirement. It also provides too little ATDD is in SAFe’s Agile Software Engineering class in any event.

But the main challenge is that it doesn’t offer ATDD in the first round of team training. SAFe follows in Scrum’s footsteps of spending more time on the framework than needed while not offering enough of what really is – how to do the work in the framework. Make sure that you have your teams get ATDD training in their initial round of training. You won’t be able to get certification for this, but you’ll get the start you need. Without this many teams struggle with the adoption and will often resist it. By the time you realize what’s happened the damage will be done. See How Using MBIs Ties Strategies, the intake process, ATDD, and planning together for more information.

4. Adjust trains to fit the required flow

SAFe’s train formation is overly simplified and one of the reasons planning increments need to be so long. When trains are properly formed and workflows between the teams in the value stream are made clear, efficiencies and feedback cycles can be greatly improved.

5. Add the role of the business architect

Most companies tacitly have a role for the business architect. But it is important to make it explicit. Adverse side effects of modifying offerings and capabilities must be attended to. SAFe does not make this responsibility explicit enough.

6. Have quarterly planning event for releases, have program increments be 2-4 weeks.

High level planning for a quarter is likely necessary for most organizations. But detailed planning takes us back into waterfall. Do release planning quarterly but do iteration planning for just 2-4 weeks.

Plain and simple, 3 month planning events are not Agile. For companies that couldn’t get anything done in a year and are now getting things done in 3 months, SAFe is great. But don’t consider it Agile.

Quarterly planning presumes more certainty than we have. It’s waterfall thinking. Going from 12 to 3 months is an improvement. But don’t stop there.

If you are a development group of less than 300 people you probably could be doing 2 week plannings or even flow. Every now & then you can do a big room planning for the social benefits that provides, but it’s not needed for planning.

Long planning periods:

require reworking requirements in last couple of sprints
loses focus on realizing value
makes it more likely that features will be bigger than needed
loses focus by teams on releasable value
results in more work being injected into already planned work
has the refinement of any stories pushed out of the PI due to new work be waste
makes it harder to pivot
causes a loss in a sense of urgency
requires more refinement up front without advantage of feedback e
establishes a baseline of “not good but good enough” so improvement stops

It’s fine to do high level quarterly planning but then work in a flow model to implement it.

Improvements to make while still doing “SAFe by the book”

There are at least five improvements you can make while still doing SAFe by the book. These are

1. Find an SPCT that is not dogmatic about SAFe

Most experienced SPCTs know that SAFe is a framework, not a jail cell. Following it by the book still allows for some flexibility – after all, it is a framework. Some SPCTs don’t have enough experience with Agile methods to enable them to be flexible within the framework. Make sure yours is.

2. Make it clear what an MVP is

One of the ironies of adopting SAFe is that the motivation is to have clarity on teams and actions. Unfortunately, SAFe’s using MVPs as the driver for what to build has the opposite effect. People know that they are not always working on a new product. They are not in an start-up mode. So the MVP starts meaning the smallest thing that can be done. This is not its intention and its meaning becomes varied.

Simple define what the MVP means to your company. Reading the section on Thinking Incrementally and you should be able to do this fairly easily. Make sure your SPCT is good with this.

3. If you have platform teams, ensure you set up your trains accordingly

Having one or more platforms in a medium size development organization is fairly common. This is not incompatible with SAFe, but SAFe provides little guidance here. See Attending to Flow Through the Development Group for ideas on how to do this. You will also find value in reading Northwestern Mutual Case Study: A SAFe Implementation Retrospection. While SAI wrote their own case study, it was written from the perspective of a standard SAFe implementation, which isn’t really what happened. Once the trains are set up your SAFe consultant to take it from there.

4. Take ATDD up front

I was encouraged when SAI decided to offer ATDD. Unfortunately, they did it by bundling it into the Agile Software Engineering course and relegating it to second tier training. The problem with this is twofold. First, ATDD must be taught with product owners, developers and testers, or it isn’t really ATDD. Secondly, this should be in the first round of training so that developers and testers are actually helped at the beginning. Otherwise SAFe often appears to be just another round of meetings to attend. ATDD integrated with Scrum/Kanban training is the best way to learn it.

5. Work towards removing dependencies across teams

For organizations that have siloed teams, a three month program increment makes sense. But if you remove dependencies between the teams you can get much more efficient and faster releases of value.

Improvements to SAFe Practices as Well as Places to Go Deeper

SAFe has modified a few standard practices that should be returned more to their original state. These include:

Weighted Shortest Job First. Besides redefining WSJF to a way that’s easier, but can provide incorrect results, it’s being used on Epics (which are too big) and on features (which don’t always provide value on their own. See Improving WSJF which discusses why WSJF should be done on MBIs and not features.
Revert to the original Lean-UX “run an experiment” instead of using Minimal Marketable Feature (MMF) which means something completely different
SAFe discusses leadership but more can be found at The Role of Leadership and Management and architecture.