A note on how the term value stream is used in this book.
SAFe is partially based on the philosophy that you need good Agile teams to be able to scale Agile across an organization. It suggests starting with Essential SAFe to get your teams working together and then adding other levels to include product, portfolio and solution management. This has SAFe be somewhat of a bottom up approach that spreads across the organization by getting different parts of an organization working together.
For organizations that are siloed and are experiencing difficulty having their teams working together, this can be a great start to get collaboration. This is why SAFe often achieves value when it is first implemented. But there are three inherent challenges that doom many SAFe adoptions unless the lead consultant recognizes them.
- Many challenges in an organization are being caused at the upper levels of SAFe and they cannot be solved by a bottom up approach.
- SAFe is organized around levels of the organization that relate to different parts of the value stream (using the Lean term here). This creates a “damned if you do, damned if you don’t” situation. Essential SAFe does not include many of the practices in portfolio and product management that virtually all companies need. But starting at the higher levels involves much greater complexity than most organizations would be able to start with, not to mention, most don’t need such complex solutions.
- After getting teams working together the real problem with Agile Release Trains, the real problem is to get the ARTs decomposed into dedicated product teams that can be semi-autonomous, working together in a network. SAFe’s techniques of combining and coordinating the pieces of an enterprise provide little guidance on how to decompose trains into what’s needed to disentangle the value streams within an ART.
How FLEX can overcome these challenges and can provide continued success with SAFe
FLEX overcomes these challenges in a two-step process. First, it shows how to think of SAFe in terms of value streams. When viewed from this perspective, it becomes clear that the problem is not to get different value streams to work together, it’s to disentangle the ones that overlap with each other causing serious multi-tasking and delays. Agile at scale may first require a combination of teams to achieve some level of coordination, but decoupling value streams is the next order of business. The second step is manifesting this decoupling. While many improvements are available, FLEX for SAFe focuses on the following 6:
- Attending to the entire value stream
- Improving product management
- Decomposing ARTs into product focused teams and teams of teams
- Presenting alternatives to big room, big batch planning, big time planning.
- Enabling continuous improvement with kaizen.
- Basic Lean Management.
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:
- 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.
- What is flow? FLEX is based on achieving flow, it is important to understand what it is.
- Lean Product Management. FLEX’s Lean Product Management is one thing that sets it far apart from SAFe.
- 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.
It is unfortunate that SAFe has somewhat redefined and repurposed the term “value stream.” For decades, Lean has defined the term “value stream” to mean “the set of actions that take place to add value to a customer from the initial request through realization of value by the customer. The value stream begins with the initial concept, moves through various stages for one or more development teams (where Agile methods begin), and on through final delivery and support.”
You don’t define them, they represent what is. You can, of course, define what you’d like them to be and to take actions to improve them. It’s important to refer to value streams as “what is” and “ideal” or “what we want” value streams as something we want to create. Then we can see what steps we need to take to improve our value streams.
One last point. In an article on value streams, SAFe claimed:
“By their very nature, value streams are long-lived and generally independent of each other”
This is not correct. The major cause of multi-tasking is that value streams overlap with each other (not independent). And project thinking has them be short-lived.