SAFe’s definition of the value stream is “Value Streams represent the series of steps that an organization uses to build Solutions that provide a continuous flow of value to a Customer. SAFe value streams are used to define and realize Portfolio-level business objectives and organize Agile Release Trains (ARTs) to deliver value more rapidly.” This is a subtle difference from the long-standing definition of a value stream – “A value stream represents the series of steps undertaken from beginning to end for a specific product or service in order to provide business value.” In other words, value streams are about our current state and not what we want it to be. We don’t define a value stream as much as we refine one. Value stream mapping is a way to see what is working and what isn’t. It focuses on the delays in delivering value.
SAFe’s use of the term just needs a slight clarification. While value streams are technically about one product or service, SAFe is trying to underscore that we want stable value streams. That is, improvements to a product or service would be best served by each having the value streams for different extensions to be very similar to each other. While that’s not quite the classic definition of a value stream it enables one to think about the desired stability of Agile Release Trains (ARTs) if we had that. This distinction between the current value stream for a particular product or service and the idealized value stream for the series of related value streams can be used to help improve our processes and organization of our talent.
Value streams are particularly useful when they cut across multiple parts (e.g., programs) of the organization. One purpose of the value stream is to make this visible. One of the most popular books on DevOps, The Phoenix Project, is really a book on Lean, using DevOps to illustrate lean principles and how to create visibility.
Looking at value streams is important as illustrated by Alan Ward’s observation that “projects and practices fail when they optimize one part of the value stream at the expense of others or when the parts just don’t fit.”
There are several related definitions of what a value stream is. The reason for this is that value stream mapping started in manufacturing, moved into physical world product development and has now expanded into software product and IT development. A good classic definition of the value stream comes from Karen Martin’s Value Stream Mapping: How to visualize work and align leadership for organizational transformation – A value stream is a sequence of activities that an organization undertakes to deliver on a customer request”
A more pertinent one for software development comes from Patrick Anderson – “A value stream encompasses all activities undertaken from beginning to end for a specific product or service in order to provide business value.”
While value stream definitions have slightly varied over time, there has been one constant – they are end to end – beginning with a request and not ending until value is realized. Another way of saying this is “concept to realization.”
Realizing that the value stream is an end to end construct, enables us to recognize that when we attend to only one level we are leaving part of the value stream out – something that has consequences. This is especially important when starting off adopting SAFe with Safe Essentials because although you may adopt SAFe at the program level, there are implications of attending to only part of the value stream.
SAFe’s Value Stream Illustrated
This is a modified diagram from our Viewing SAFe from a Value Stream Perspective webinar (recording and PDF available with registration). The ‘flower’ on the left are 6 objectives required for Agile at scale discussed in the talk.
The ‘related articles’ section on this page points to some additional information you will find useful. In particular, look at:
For an example of how value stream mapping can sometimes create fantastic results, see page 18 from the chapter An Agile Developer’s Guide to Lean Software Development in our Lean-Agile Software Development: Achieving Enterprise Agility book.