The idea of value streams intuitively appeals to most business, product, and engineering leaders I talk to. It speaks directly to the manner in which they think of how their businesses serve their customers. Most can identify the value streams serving the company mission without prompting. 

The concept of value streams is also key in DevOps [1] and modern design approaches for engineering organizations like Team Topologies. 

However, “Value Stream Management” seems to be a relatively new and unfamiliar concept.

The typical questions I get are: what does it mean to do “Value Stream Management”?  How is this different from what we call Product Development or Engineering today? How are value streams relevant to building products and structuring our organizations?

In this post, I’ll give my perspective on these questions and discuss value stream management and how it relates to much more familiar approaches to improvement in software development 

Value Stream Management vs Mapping

Before jumping into Value Stream Management, let’s quickly look at Value Stream Mapping, its more famous cousin with which it shares an acronym. 

In her seminal book on Value Stream Mapping, Karen Martin defines a value stream as the “sequence of activities required to design, produce, and deliver a good or service to a customer, including the dual flows of information and materials.”.  

Creating a value stream map - a visual representation of the flow of work - is an essential first step in value stream management because it brings visibility into the end-to-end delivery system. 

By contrast, Value Stream Management is concerned with improving this system by analyzing workflows represented by one or more value streams and identifying opportunities to improve the efficiency and efficacy of the delivery system. 

In the industrial production and service industries, where these techniques were originally developed and refined, value stream mapping and using value stream maps to drive operational improvements to the flow of work in a delivery system has a long track record of success. These techniques fall under the Lean umbrella and are simply core parts of the Kaizen practices integral to this way of working.

These ideas are equally applicable to software development. However, software development differs significantly from industrial production and general service delivery in some critical ways. In particular, techniques from industrial production that improve the efficiency within a value stream do not automatically improve the efficacy of the value stream. 

So, we must take a more nuanced approach when adapting these ideas in the software development context. In what follows, I will use the acronym VSM to mean Value Stream Management, and it is implied that Value Stream Mapping is an integral part of this. 

Value Stream Management 

Since VSM is concerned with improving a delivery system, let’s look at how software companies typically approach this problem today. 

In the last decade, we’ve seen remarkable advancements in software companies' ability to increase visibility into and improve software development systems using hard data. 

However, software companies' dominant approaches to system improvements are still very functionally oriented. We have separate frameworks to improve each of the functional silos involved in creating and supporting software products, each focusing on its own imperatives, as shown below.

While these frameworks are crucial building blocks telling us what to measure in the software domain, there are three challenges. 

1. Companies start focusing on performance improvement along the functional silos, and the focus shifts to standardizing processes, performance expectations, and comparative measurements of the performance of teams within those functional silos. If done poorly, the negative impacts of these efforts can often outweigh the benefits. 
2. The improvement efforts are oblivious to the impact of friction in the delivery system across functional silos. In most companies of any size, this is the dominant source of inefficiency in the delivery system, so the net impact on customer experiences of functional improvement may be small if these are not accounted for. 
3. When you focus on improving “Developer Productivity,” “Product Effectiveness,” etc., in silos, the overall scope of improvement efforts becomes larger than it needs to be.  In the end, this approach often does not deliver outcomes commensurate with the investment needed to make those improvements globally within a given silo [2]. 

These can all be addressed by taking the value stream perspective to system improvement.

In this model, instead of focusing on global improvements along a functional silo, we focus improvement on a specific (set of)  customer experiences and the end-to-end flow of work across all functional silos involved in fulfilling it. This aligns with the classic definition of a value stream above, and this 

The key difference is that in a typical software development environment, this analysis is much more useful when done at a finer granularity than a “product” or “service.”  Even simple software products or services need to be broken down into a granular level to analyze the “flow of work” since it is rarely uniform when viewed at the product or service level.

Focusing on a single value proposition and customer experience and improving the flow of work needed to fulfill it gives us a narrower perspective to understand improvements that will improve the efficacy of the delivery system and then determine what “efficiencies” are needed in the flow of work to do so. 

Value stream improvement involves bringing together existing tools and techniques for functional improvement in product management, engineering etc, with well-understood techniques for improving the flow of work across functional boundaries, and it is this synthesis that makes VSM different. 

If you have a self-contained cross-functional team that can autonomously meet all the customer needs in a value stream ( ie, a “stream-aligned” team, in Team Topologies terms), you have the simplest possible type of value stream improvement problem.

 But in many cases, a value stream intersects the functional boundaries of an organization in more complex ways, and value stream improvement will uncover many more sources of delivery friction that need to be untangled. 

In either scenario, the very attempt to make these types of cross-functional changes across a value stream exposes how a given organization will respond to an attempt to change, and in many cases, understanding where these barriers to cross-functional change are the first and most important learning that comes out of an attempt at value stream improvement.

Focusing improvement on value streams is also an excellent strategy for changing complex socio-technical systems. At any stage in the process, we make small changes to specific functional areas within a value stream and use a sense-and-respond approach to understand how to make any subsequent change. 

How a complex system responds to any given change is not always clear. So, value stream improvements are not linear, predictable changes that you can execute on the basis of a pre-determined plan.

Summary

The defining feature of value stream improvement is localizing changes within a contained context of a value stream while focusing on the global impact of the changes. This is what differentiates it from other approaches to organizational change. 

Value Stream Management is the umbrella practice of managing improvement programs across a software company's myriad value streams.  The practice aligns the improvement strategy with overall company objectives and strategy. It is concerned with identifying and prioritizing improvement opportunities across value streams to maximize the impact on company outcomes. 

Given that organizational change management is such a complex and fraught undertaking, value stream improvements are a lower-cost, lower-risk approach that yields measurable, incremental improvements in customer experience on much shorter timeframes than your typical process of organizational “transformation.”

In the next post in the series, we will look at the factors that help lead to a successful value stream management program within a company and typical impediments that we’ve seen in the field in introducing these ideas and practices in companies. 

Notes: 

[1] DevOps and Value Stream Management have very similar goals, and many practitioners consider them to be the same concept. However, DevOps/DevSecOps is largely perceived as a technical discipline focused on improvements in engineering delivery by the industry. There is comparatively less focus on integrating upstream processes from engineering (the so-called fuzzy front end) in what is currently considered DevOps. 

Value Stream Management, as defined in this post, includes the entire scope of DevSecOps. By integrating the fuzzy front end of product management into the improvement process, VSM closes the loop on product development, giving us the tools to reason about holistically improving delivery efficiency and product efficacy. 

[2] A good example of this approach is the focus on “developer productivity.” Most engineering leaders consider this a critical priority and will devote significant resources to measuring and improving this in 2024. In my opinion. viewing developer productivity as one of the improvement dimensions in the context of a value stream improvement program is a much more effective strategy than trying to improve developer productivity across the engineering organization, and it avoids many of the negative side effects of trying to measure and improve this in a silo.