Author: Jurgen Appelo

Value Streams, Historically

A value stream is a way of describing the work we do to delight our customers. The concept of value streams was embraced decades ago by Toyota with their groundbreaking Toyota Production System (TPS). Since then, value stream mapping has become a foundational practice in Lean literature, and the term is now also used in the Agile community worldwide.

I came across several definitions of value streams but they all come down to the same thing:

A value stream is the set of actions needed to fulfill a value proposition from a request (order) to realization (delivery). A value stream always begins and ends with a customer. The goal is to improve time to value by optimizing the whole value stream.

No definition is perfect, and there are always people eager to debate the nitty-gritty details of terminology. Still, I'm confident that this definition is the one embraced by most Lean and Agile thinkers and practitioners.

Value stream mapping has greatly influenced Scrum, Kanban, SAFe, and other agile methods and frameworks. The standard interpretation has always been, "A customer makes a feature request, and we need to develop and deliver that feature as quickly as we can," which perfectly fits the software factory metaphor. But I'm not satisfied with historical definitions. We need to move forward.

The original context of the term value stream was manufacturing. The idea of "value stream mapping" was used in factories to describe how value was created for customers who ordered a known product and wanted that product to be delivered fast. The value stream mapping practice was very successful, but the manufacturing context comes with several assumptions that don't hold in other environments.

Let’s make a few changes.

Before we can deliver value, we first need to discover value.

Customers won't make requests if they don't even know there is a problem or opportunity. The definition of value streams assumes that the customer is aware of (or has expectations about) what they want. For the idea of value streams to be more broadly applicable, we need to combine product discovery with product delivery. We need to include all lifecycle stages of a value stream from Stage 1: Initiation to Stage 10: Termination.

I've always been skeptical about the bias in agile software development toward value delivery. Many agile coaches and consultants assume that customers make requests, and then it's up to their agile teams to deliver. But there's a reason why Lean Startup, Design Thinking, Lean UX, Jobs-to-Be-Done, and Service Design have all emerged in parallel to Lean and Agile thinking. Continuous innovation requires exploration and execution working in harmony.

We should update the value stream definition to include discovery and delivery.

Value streams exist to satisfy high-level and low-level jobs.

Is a family visit to Disneyworld one large value stream? Or can we count each ride in the park as a separate value stream? Is my monthly Netflix subscription one enduring value stream? Or is each separate TV show episode that I watch a small value stream by itself? I found nothing in Lean literature that suggests either one or the other. Both interpretations seem to be okay. Value streams can be large, high-level products and small, low-level services.

I think the Jobs-to-Be-Done community has done a great job (pun not intended) helping us to understand what our customers truly need and desire. Each value stream exists to get a job done (usually in terms of convenience or pleasure). There can be high-level jobs and low-level jobs. Small jobs can be part of large jobs (like individual joyful rides being part of the entire Disneyworld experience), and thus minor value streams (small jobs-to-be-done) can be part of major value streams (for large jobs-to-be-done).

We should update the value stream definition to be compatible with jobs-to-be-done.

Instead of waiting for requests, we could wait for signals.

Is there a good reason to simply wait for customers to finally place an order and then to deliver only what they have ordered, exactly as promised? Why not use the element of surprise and give something for free to people who least expect it (and who then might turn into actual customers)? Why not detect when a customer might be interested in something and then offer it to them (at a price) before they even realize that they have a problem? Wouldn't that be a much better value proposition?

Customer experience means more than just customers making requests and suppliers acting on that as fast as they can. This is not how Tesla handles customer service after cars have been bought and paid for. This is not how savvy SaaS vendors improve their conversion and retention rates. This is not how Denis Villeneuve makes the Dune movies. Innovation in the 21st century means acting on signals, not only on requests.

We should update the value stream definition to rely on signals and requests.

Improve the experience for users, not only customers.

I often use the company Haier in my examples of business agility at scale. One of the mantras at Haier is the goal of “zero distance,” which (at Haier) is often interpreted as workers trying to know all about the needs and desires of the users of their products. And very often, users are not customers.

When you sell fridges or cars, your customers might be parents or caretakers, but the users are the entire family. When you sell an agile scaling framework, the customer could be just the CEO, but the users are the whole product organization. And when you sell diapers, the users are most likely not the customers. It's our job to improve the user experience and the customer experience (two different things). In most cases, happier users means more loyal customers.

We should update the value stream definition to include users and customers.

Value Streams, Updated Definition

By making a few minor changes to the earlier definition of value streams, I think I can make it better applicable across a more comprehensive range of organizations and industries. And if some purists in the Lean community object to this heresy, they can make my day. 😁

A value stream is the set of actions needed to discover or deliver on a job-to-be-done / value proposition from a signal to an experience. A value stream always begins and ends with a user or customer. The goal is to improve the experience by optimizing the whole value stream.

In the unFIX model, the first responsibility of Value Stream Crews is to take responsibility for one or more low-level value streams (small jobs-to-be-done) and ensure that their users and customers are happy. The Governance Crew can combine multiple value streams inside one Base to form one business unit with a clear purpose and sense of belonging.

Scaling up to the next level, multiple Bases could form a Cluster, ensuring that all the minor value streams aggregate into major value streams. A large product, therefore, serves a large job-to-be-done which is broken down into many smaller jobs-to-be-done, spread over several Bases.

SAFe Unfixed

And then … a word about the Scaled Agile Framework (SAFe). SAFe has the following text on its website:

"A SAFe portfolio contains one or more value streams, each of which is dedicated to build and support a set of solutions ... Agile Release Trains (ART) within each value stream develop the business solutions."

It appears that SAFe equates a value stream to a large product (a high-level job-to-be-done). The framework even says that multiple Agile Release Trains (which are somewhat comparable to Turfs or Bases) operate within one value stream. That's a LOT of people working on one thing! SAFe has no notion of high-level vs. low-level value streams (major jobs-to-be-done vs. minor jobs-to-be-done), which can make it much harder for individual teams to feel "zero distance" between their work and a specific experience to be achieved with their particular users or customers.

Remember, there is no notion of scale in any definition of value streams. The only thing that matters is that value streams start with a request (or signal) and end with value (or experience). This says nothing about the size of the work or the number of people involved. A value stream can be as large as launching satellites into orbit and as small as selling popsicles on a beach. By stating that a value stream is dedicated to building "a set of solutions with multiple ARTs", the Scaled Agile Framework is biased toward large value over small value. I think that's not agile.

You can unfix SAFe by ignoring their peculiar definition of value streams. Instead, assume that each ART contains low-level value streams serving minor jobs-to-be-done. Ensure that each team knows which value streams they manage and what jobs-to-be-done they serve. Don't scale up before they can answer these questions. There can be no large without small.