Part XII: Using FLEX to both enhance and simplify SAFe

<< Why Agile Coaches Need to Know Both Scrum and Kanban      ToC     Why Essential SAFe is Both More and Less Than What’s Needed at Small to Mid-Scale >>.

SAFe was originally developed to coordinate teams working together on projects. It is popular because it has provided a way for very large companies that could barely deliver in a year to deliver on a quarterly basis.  This is a major improvement. But even for these companies it is far from what is possible. For companies under 500 people in the development group it is overkill and rarely Agile.

Most companies using SAFe with the Essential Configuration, that is, at the program level. At this level SAFe is a combination of well known practices:

  1. having a well defined intake process making use of big room planning
  2. coordinating teams with a common cadence and integration points
  3. having shared services
  4. using DevOps

However, as SAFe has grown, it has tacked on other concepts by changing or even redefining their original intent. This has resulted in the higher levels being complicated, ineffective and rarely implemented. Getting teams working together is an improvement but does not result in an organization being Agile.

How FLEX Can Enhance and Simplify SAFe at the Same Time

SAFe’s design flaws have made it more complicated than necessary. By viewing SAFe from a value stream perspective and by adding critical concepts not in SAFe (while removing their redefined, overloaded and confusing terms) results in more effectiveness while making things simpler.

Reading this part of the book

This part first shows why SAFe’s design inherently makes it more complicated than it should be. It then shows how to view SAFe as a value stream – making it easier to understand. Finally it shows how to combine FLEX with SAFe to make a more effective framework than SAFe alone.

For those that want to do “SAFe by the book” I include a small section on how you can use some of FLEX’s concepts totally within the SAFe framework. This will enable standard SAFe training, getting some immediately improvement while setting the stage up for more improvement later.

Please read these chapters if you haven’t read them already as concepts in them will be referred to repeatedly in this part:

  1. The Business Case For Agility. This chapter introduces the Minimum Business Increment (MBI) an essential concept different from an MVP and not explicitly in SAFe.
  2. What is flow? FLEX is based on achieving flow, it is important to understand what it is.
  3. Lean Product Management. FLEX’s Lean Product Management is one thing that sets it far apart from SAFe.
  4. How Epics Are Used in FLEX. What epics are is overloaded in SAFe because there is no explicit definition to hold the concept of the minimum business increment for which value can be realized.  This chapter discusses why MBIs are a better container from which to create features.

This part of the book first presents Why Essential SAFe is Both More and Less Than What’s Needed at Small to Mid-Scale.  Then it describes SAFe from a Value Stream Perspective, which is a better way to understand what SAFe does. The last chapter will be about Putting it together: FLEX and SAFe where I talk about the options you have in using FLEX to both enhance and simplify SAFe.

<< Why Agile Coaches Need to Know Both Scrum and Kanban      ToC     Why Essential SAFe is Both More and Less Than What’s Needed at Small to Mid-Scale >>.