Using FLEX to Enhance SAFe


Net Objectives has been a promoter of SAFe for several years. When it was announced we were attracted to it because it had many similarities to our own approach that we've been building since 2005. We were early adopters of and contributors to SAFe because of this. One of SAFe's advantages is that it provides a well defined definition of what people should do.
Depending upon culture and size SAFe can be used in different ways. For medium sized organizations that consist of development groups of 75 people or less, SAFe provides some useful practices (most notably the planning event) that can be adapted to the organization. For Agile at true scale (large companies with development groups in the hundreds) SAFe can be used in one of two ways. First, as a solid framework where everyone does it as it is described in the certification courses. Second, as a foundation for what works best for the organization adopting it. Which route you take depends upon your culture and the level of experience your transformation team has. We help companies that want to take the second route. 
For over a decade we have used Lean-Agile methods to help our clients achieve business agility - the quick realization of business value predictably, sustainably and with high quality. We have used an operating model that we call FLow for Enterprise Transformation (FLEX). FLEX enables us to use frameworks as tools to get the best of what's needed. We don't believe any framework can be a "one-size fits all."
FLEX is not a competing framework to SAFe but provides concepts that can improve the effectiveness of any organization regardless of their degree of SAFe adoption.  SAFe has many elements to it and not all of those are needed in every situation. We also have a simpler, more effective, Agile Product Management approach than that used in SAFe.

The following describes how we've found SAFe can be made more effective:

  1. Managing for flow of value. Improve portfolio management by making it clear the sequence the work should take. This helps with comparing alternatives, committing to starting MBIs only when there is the capacity to fully implement them, straightforward tracking of flow, and shepherding value.
  2. See potential adverse affects of a new feature. Understand the impact on the offerings outside the area of the new feature.
  3. Allocate capacity to your most important work. Focus on completing releasable work, not features.
  4. Planning events. Planning Events with increased collaboration and dependency management.
  5. ATDD to focus collaboration, focusing on value realization and using test-frist methods.  Effective product management requires an effective method of achieving clear requirements. Acceptance Test Driven Development is essential to start with, not start late in the game. Teams collaborating with Product Owners brings quicker value realization. And ATDD ramps up initial team training in a cost-effective way.
  6. Right sized trains A way to have small trains or to have big teams work within a train.
  7. Consistency across teams while enabling self-organization by teams to better fit their context
  8. A scorecard to see your progress that can also be used as a roadmap in your transformation
  9. Initial Team training with ATDD.  ATDD is essential to start with not to incorporate later in the game. FLEX offers a cost-effective approach to integrate this right in initial team training.

Our History With SAFe®

Net Objectives is not only one of the longest-practicing SAFe partners, many of its consultants and associates influenced the formation of SAFe itself (see BMC -the SAFe case study). We also led the Northwestern Mutual SAFe adoption (see here for our perspective which includes a little about how we modified SAFe going in to be more effective). Net Objectives was the primary contributor to the SAFe technical practices (emergent design, ATDD) and influenced SAFe's use of Kanban at the program and team levels. The ATDD book in the Net Objectives book series is required reading for SPCT candidates.

If you're using SAFe or considering it, talk to us. We have more experience with SAFe than anyone else outside of SAI (our CEO was the first non-SAI SPCT). 

Here is what Chet Hendrickson (Agile and XP Guru) has to say about our SAFe practices, “I don’t do SAFe training. The only person in that space I trust is Alan Shalloway at Net Objectives.”

SAFe Resources

For more information see:


I. Manage for Flow of Value

Sequencing Work

Portfolio management is a critical step in allocating your capacity so that the greatest amount of value is realized in the shortest possible time. This requires that different work items can be compared to each other. Business value, however, is not a one-dimensional value. The organization makes different types of investments that it hopes to manifest with strategies and initiatives. Being able to compare these investments and compute a potential value for the business is key. 

FLEX emphasizes the use of Minimum Business Increments (MBIs) for portfolio management for comparing alternative investments. 

  • Comparisons are only valid when comparing the next possible release of each initiative. This is because not all of one initiative is more important than all of the initiative. 
  • Since an MBI focuses on everything that is needed to realize value, it helps you think about everything in the release (both technical and non-technical). This allows more accurate comparisons.
  • It assures like-for-like comparisons.  MBIs are the appropriate size for doing Weighted Shortest-Job First (WSJF). Epics are too big and features are often too small.

Read: Why WSJF should be done on MBIs and not features. This includes a video.

Committing to starting MBIs only when there is the capacity to fully implement them

When capacity is limited and conflicts arise between the MBIs, teams can decide which MBI to support based on the overall understanding the impact to overall Cost of Delay of their decisions.

One of the biggest wastes in software development is getting something partially done and then stopping the work for one reason or another. If the work is abandoned it’s all waste. If it’s picked up, there is wasted time in getting back the lost knowledge of how it was built. Other things may have changed as well, so even more time is required. This “unplanned” work of picking it back up tends to have a ripple effect on other projects. 

Watch How delays cause waste: A main tenet of Lean.

Read Looking at time is critical.

Straightforward tracking of flow

FLEX brings visibility to this flow so you get more value out of your SAFe implementation.  As SAFe has matured over the years it has added more concepts. While useful, these have added to SAFe’s complexity. The use of MVPs, strategic themes, epics, MMFs, features, stories and more has had the effect of losing the forest for the trees. FLEX’s use of the MBI enables SAFe’s intention in a more effective, simpler manner.

FLEX’s use of the MBI enables SAFe’s intention in a more effective, simpler manner. 

Shepherding value

Although this tracking of flow will assist all roles, it highlights the need for a role to shepherd value from the business stakeholders to release.  SAFe uses a combination of several roles working together in attempts to achieve this. Unfortunately, the collaboration and hand-offs required usually make the intent of the combined roles both complex and ineffective. 

FLEX suggests a role that was identified by Net Objectives a decade ago, the Technology Delivery Manager (TDM). This role has been used with great success in many situations and sizes of organization. Essentially, the TDM’s role is to focus on managing the delivery of the technology solution of a business increment and the flow and continual delivery of the program or value stream producing it in the shortest cycle time.

II. See potential adverse affects of a new feature.

It is almost a certainty that a release will affect prior releases, often adversely. Part of this is caused by thinking of a new feature as just that: new. We focus on the new functionality rather than the potential impact on the rest of the organization. 

FLEX brings an intentional focus on understanding of offerings (what we provide) and capabilities (what we are currently capable of providing). MBIs are useful in that they must contain any work to avoid negative side effects.

In a previous lesson, you watched a video on business value realization and capabilities and offerings. You may want to review it again.

III. Allocate capacity to your most important work

One of the biggest wastes in software development is getting something partially done and then stopping the work for one reason or another. If the work is abandoned it’s all waste. If it’s picked up, there is wasted time in getting back the lost knowledge of how it was built. Other things may have changed as well, so even more time is required. This “unplanned” work of picking it back up tends to have a ripple effect on other projects. See short video How Delays Cause Waste: A Main Tenet of Lean or read Looking at Time Is Critical for more.

IV. Planning events

For many organizations, the Planning Event has become to “scale” what the Daily Scrum is to Scrum. Whether or not you are doing SAFe®, the Planning Event is often a great way to increase collaboration while coordinating the work of your teams.

One of the key values of the Agile Manifesto is “Responding to change over following a plan.” Unfortunately, because of the number of dependencies in a Release Train and the lack of the concept of the MBI, it is difficult to change the plan. 

The way out of this problem is to focus on improved collaboration and dependency management. Collaboration and dependency management go hand in hand as teams enter into agreements on when a dependency will be met. All too often the dependent team just tells another team, “We need this by when” instead of having a true agreement. The dependency is held informally. This makes it difficult to visualize the dependencies or to make changes to them. It results in a brittle plan.  By shifting “dependencies” to be a set of agreements, teams collaborate better and required changes are more easily accommodated.

Having Planning Events that are oriented around MBIs helps to manifest potential value sooner. Features are not always releasable. By focusing on those features that are part of the most import MBIs (and only on that part of the feature that is needed for the MBI the feature is in) MBIs will be completed faster. This also reduces the risk of having features completed but nothing of potential value to release.

Advantages of a Planning Event

The advantages of the Planning Event lie more in collaboration and dependency management than in the actual plan that results from the planning. This reflects the fact that if there weren’t dependencies between the teams, the event wouldn’t even be necessary. Here are some of the benefits of the Planning Event.

  • Creating clarity on what value will be realized over the planning period.
  • Creating clarity on what will be worked on during the time-frame covered by the planning period.
  • Discovering dependencies between teams and make agreements as to when they will be fulfilled.
  • Planning the work to be done in one or two week iterations to implicitly limit Work-in-Process.
  • Identifying risks and working on them.
  • Creating a sense of camaraderie among the participants.
  • Providing visibility to management of how the technology teams interact and creating an opportunity for them to create a better environment for their teams.
  • Providing visibility on how teams will move forward after the event.

Read Running Effective Planning Events.

V. Teams collaborating with product owners with both focused on value realization and using test-first methods

The heart of Agile is “Customer Collaboration over contract negotiation.” Achieving clear requirements is a challenge for a team, but as scale increases so does the challenge. Although most every consultancy suggests doing “test-first” they don’t recommend it at the start. We have found that integrating how developers, testers and product owners work together to get testable specifications is critical to create both accurate requirements and to ensure systems continue to meet them. With the proper training methods of integrating principles, practices and hands on work, doing this can be achieved for less money up front with increased ongoing value. This collaboration should be driven by MBIs for which the features and stories being worked on are part of. This creates a line-of-sight to business value for everyone – as mentioned above. This enables people to make better decisions at a local level that supports the overall goals of the organization. Learn how here.

VI. Right-sized Trains: When to use small trains or have big teams work within a train

Many companies using SAFe have “trains” that are only 3-5 teams. SAFe is meant for organizations with larger trains. Shared backlogs can be used in this situation instead of SAFe. This is a lighter weight, more effective approach than using SAFe Essentials which focuses on only part of the value stream.

This practice can also be used when large teams (24-40) are part of a train. This collection of teams can be worked with as an uber-team within the bigger train. 

To see a case stuf of how to do this, read Aligning multiple teams with Lean-Agile Thinking.

VII. Consistency across teams while enabling self-organization by teams to better fit their context

The context for team work often varies from team to team. As a result, the practices they need to use must be allowed to vary to fit the context. You want to allow this. 

One way to do this is to define consistent objectives for teams and allow them to define practices to meet those objectives. This enables teams to use a combination of Scrum and Kanban to work the way that best works for them while enabling consistency across the organization. 

Read Using Consistent Objectives to Enable Self-Organization of Teams Across an Enterprise.

VIII. Scorecards for Transformation

Metrics about how an organization is improving is useful. However, using them as a road map for improvement is even more useful. FLEX uses an Enterprise/Team Agility Scorecard which evaluates how Agile an organization is at the business, management, team agility and technical agility areas (the last two are on a team by team basis).

Flow Scorecard: A scorecard to guide and track progress in your transformation

Each row in the Flow Scorecard represents a particular practice or skill. The columns from left to right designate different levels of the skill from not very good to excellent. The columns on the right with the numbers represent where the company was at the start, where they are now, and what their target goal is. The colors make it easier to see where the organization is when viewed as a whole.

Here is an example. The start was a level 1 (shown in pink) with the organization now being a 3 (green) and the target being a 4 (blue)

    1 Low agility 2 3 4 5 - High Agility      
3 Steering Effectiveness No steering committee or activities exist. Teams driven by multiple stakeholders Steering committee meets annually to create funding for annual projects. 18-month leadtime is normal. Annual Planning is broken up into Quarterly plans that are re-evaluated each Quarter Work is steered to dedicated teams. Funding is used to procure story points. Funding stakeholders negotiate priorities with each other to balance capacity and demand Bi-weekly steering by all funding stakeholders. Small steady flows of work are sequenced and matched to measured capacity on a bi-weekly basis 1 3 4

This puts the current situation in the context of where the organization started and where it is headed.

Team Agility Scorecard: A scorecard to help decide which changes to your approach will be most helpful

The Team Agility Scorecard is similar. It gives detail at the team level and covers the roles, artifacts, rules and events that teams need to do is also available.

Here is an example of one factor.

      1- Low agility 2 3 4 5 - High Agility     ZZ
15 Enable other teams to see both what will be required of them as well as when what they are depending upon is being developed Visibility of work (sprint backlog) Work is not visible. There is no organized list of work to be done A sprint backlog exists, but the state of the work is not shown other than "in process" and "done" All work regarding the team is visible, including stories added to the sprint after it started for whatever reason, side effect of interruptions, any blockages present Visibility in the prior column exists as well as any dependences on other groups, dependencies that people have on us including work upon Kaizen activities - continuous improvements Visibility in the prior column exists as well as work of different types such as customer focused on systems focused 2 3 5

IX. Initial Team Training With ATDD

Everyone agrees that Acceptance Test-Driven Development is a key to successful Agile. Without ATDD there is rarely sufficient clarity of requirements. The best way to achieve this clarity is through the use of ATDD and writing stories in the form of testable acceptance specifications.

While teams can start with the formula

As a < type of user >, I want < some goal > so that < some reason >

this type of specification is not easily testable. It also doesn’t enable writing small stories. Integrating ATDD with Behavior Driven Development’s

Given when then < this behavior is required>.

which both greatly increases the necessary collaboration mentioned and the ability to writ small stories.

Teaching ATDD up-front with initial team training and for large groups without overloading them has not been possible. With the FLEX mindset Net Objectives has developed a way of integrating team-level training with the initial phases of ATDD. A serendipitous result is that when taught properly, it can be less expensive to teach Scrum/ATDD than Scrum alone.

To learn more about Scrum integrated with ATDD see Scrum/ATDD.
We provide onsite training of the standard SAFe courses as well as technical and ATDD training for SAFe®.