FLEX and SAFe®

SAFe® is designed for large organizations.  We have seen it be effective when organizations must follow a set, pre-defined method. This is sometimes true when an organization is very large and no other method will do.  However, in the case where organizations do not require such a set approach, FLEX can be more effective.

Many mid-size organizations are looking at SAFe because, until FLEX, there was no well-defined approach that wasn’t based on Scrum-of-Scrums. However, FLEX takes a different approach to mid-scale (50-1000 people in the technology side).  Companies of this size should be able to follow an approach tailored for them and not require a pre-set approach that may or may not address their needs.

While SAFe suggests working at the program with SAFe Essentials, FLEX suggests still starting with identifying what is the greatest value that can be realized.

FLEX includes the intentions of the ten essential elements of Essential SAFe.  However, these are sometimes achieved with different practices.  FLEX also has an additional four elements we consider to be key:

Here are the ten SAFe Essential’s and how FLEX implements them:

Lean-Agile Principles.  FLEX’s core is Lean-Agile. It takes a fully systems-thinking approach, looking at the realization of business value as a whole.  FLEX is truly flow based while SAFe is essentially large batches (3 month planning cycles) with Lean attempting to speed it up.

  • Cross Functional Teams and Trains. These are always good, but what if you can’t achieve them? FLEX includes methods for improving trains when these can’t be achieved. Some of these methods were used in the Northwestern Mutual SAFe adoption led by Net Objectives.
  • Cadence and Synchronization. This is an essential part of any Agile endeavor involving more than one team.  FLEX and SAFe are very similar here.
  • Program Increment Planning. While often required for large scale, a flow based planning model done every two weeks is sufficient for most mid-scale organizations. The intention is to manage dependencies and create visibility and agreements across teams. This does not need to be the 2-3 months SAFe suggests when at mid-scale.
  • DevOps and Release-ability. DevOps is a critical part of efficient deployment and realization of value. FLEX’s focus on visibility of work, workflow, and workload facilitates devops considerably.
  • System Demo. The program increment planning event ensures dependencies are tracked.  But FLEX’s flow based planning model results in faster coordination than at the time of release.  This enables quicker demoing of full features.
  • Inspect and Adapt. This is useful to improve current methods.  Double-loop learning takes this to another level by challenging your core assumptions.  This is essential to make any course corrections in approach.
  • Innovation and Planning Iteration. Taking time out for innovation makes sense when there is no other way to achieve it. But being able to innovate in a somewhat continuous manner is usually better. At mid-scale a separate innovation iteration is typically not necessary.
  • Architectural Runway. Both the architectural runway and intentional architecture of SAFe are built on emergent design and can be enhanced with Design Patterns Thinking.  Net Objectives has been a leader in the field of design patterns, Acceptance Test-Driven Development, Sustainable Test-Driven Development and more.  In fact, Net Objectives was the contributor to the technical agility methods of SAFe.
  • Lean-Agile Leadership is an essential part of any organization.  FLEX lays out several leadership and management roles to improve the eco-system of the organization while making it clear what strategic initiatives are required to manifest the mission of the company.

Using FLEX to extend SAFe®

FLEX is designed to work as a standalone approach. However, because it is based on the approach of improving what you do by providing solutions to your challenges, it can also be used to improve an existing SAFe® implementation or be used to prepare for one.

FLEX provides those implementing, or about to implement SAFe the following:

  • An understanding of what the SAFe practices are trying to accomplish
  • Alternative practices that can be substituted when needed
  • A deeper understanding how the components of SAFe work together
  • A more effective way of doing Agile Product Management
  • A tool box of ideas for improving the formation of trains
  • Greater clarity on the role of management in creating eco-systems for the teams
  • A consistent, but tailor able, method for team process (Team Agility)
  • A method to do shorter program planning increment events than SAFe prescribes or to have SAFe follow a flow model instead of its batch model
  • More insights on the use of shared-services
  • A better WSJF
  • Alternatives to planning poker (team-estimation by Steve Bockman)

Using SAFe as a starting framework

FLEX and SAFe at mid-scale

SAFe provides the following guidance that is useful at mid-scale:

  • Have a single backlog for initiating ideas
  • Create the role of product manager to align the business side with technology
  • Have teams work in a common cadence
  • Do planning events with everybody present.  Note that his event does not need to be for 8-14 weeks out.  In fact, it should be for as short a period as the organization can manage effectively.  Otherwise the organization will be working on larger batches than necessary.
  • Attend to technical practices and quality of design and code

While these are consistent with FLEX they are more batch oriented instead of flow oriented. This enables the adopter of SAFe to either start with SAFe as is or to recognize the adjustments to SAFe that FLEX suggests to be more flow-oriented.

Even when using SAFe as a guide, it is important to use Agile product management methods with  Minimum Business Increments unless any change to the SAFe framework will cause adverse affects.

FLEX and SAFe at large-scale

At large scale, SAFe is often the only way to start an organization’s change because any discussion about how to stray from an out-of-the box implementation may cause more delay and harm than just getting started. As challenges arise after a SAFe implementation is underway, however, FLEX provide insights into how to adjust SAFe for your context.  By providing a more flexible model (pun intended) FLEX also helps eliminate the tendency to view SAFe dogmatically.  The biggest adjustment however, is that after SAFe has been implemented, the concept of Minimum Business Increments (MBIs) can be implemented in SAFe by using right-sized epics. While we prefer the term MBIs, right-sized epics is completely consistent with SAFe’s terminology and follows one of SAFe’s suggested methods of decomposing epics.

When to Use SAFe® essentials at the Mid-Scale

SAFe Essentials® may be an effective way to start a full-blown, large-scale (1000+) Agile transformation.  Sometimes this is due to only being able to start at the program level.  More often, it’s because the only way to start is with an off the shelf solution.

In smaller transformations, however, it is often possible to get the business involved.  In doing so, the use of Minimum Business Increments (MBIs) can greatly increase both alignment and assist in avoiding the overloading of teams.

By leaving out systems thinking, Portfolio management with Minimum Business Increments (MBIs), Double-loop learning, and full visibility (workflow, workload, work agreements), many opportunities for quick wins are lost.


All resources in FLEX and SAFe

The Interesting Parallel Between SAFe and the Kanban Method (Article)
Understanding the Pull of SAFe (Article)
Using MBIs in SAFe (Article)
Weighted Shortest Job First (Article)