This post will discuss a critical and often unseen aspect of value stream management, the Value Stream Network.
Organizations are confronted with many challenges that impede the smooth flow of work from ideation to customer delivery. The dynamic ecosystem of a complex organization calls for a framework that can holistically understand the interdependencies, remove constraints, and streamline activities to drive customer outcomes. Enter the Value Stream Network concept—a powerful lens through which to view, analyze, and optimize an entire organization's workflows.
Chris Gallivan, Planview
In Mik Kersten’s Flow Framework, he discussed three distinct network layers. Each layer rides on top of the previous layer, starting with the Tool Network, next the Artifact Network, and culminating with the Value Stream Network. The most important layer is the Value Stream Network, which is the layer that value rides on as it makes its way from idea to the customer's hands.
The Value Stream Network is the social network of interactions, handoffs, and dependencies between teams and individuals in the organization. It’s how work gets done. A helpful way to think of this concept is to imagine a set of airline routes, interconnecting airports across the globe. The airline network is pervasive. In order for a customer to make it to their destination, they must use the network - there are no other alternatives for air travel. It is also nebulous. Without the use of complex scheduling software, it is very difficult to see what routes are possible to make it to your destination.
Unlike an airline network, a software Value Stream Network has very few single-leg routes. In order to provide value to customers' hands, it most likely takes the work of several teams.
A Typical Value Stream Network
The Value Stream Network is also a dynamic network. Software changes, organizational changes, budget changes, market changes, and entropy all cause the network to evolve on a regular basis. For this reason, attempts to capture point-in-time snapshots of the Value Stream Network tend to get out of date very quickly. Alternative methods of visualizing the network using graph theory may yield further insights, in a similar manner as they have in the airline industry.
Without a mechanism to view the actual flow of value, organizations can get “Stuck in StoryLand”, inundated with activities, and underwhelmed with the business results they are achieving. For these organizations, being able to see the Value Stream Network may be the missing piece to unlock the promise of Value Stream Management.
Steve Pereira, Visible Consulting
Your Org Chart is not Your Org
One of the most important aspects of the Value Stream Network concept is that the depictions we have of organizations don’t effectively illustrate how an organization actually works, or what it’s for. We can see divisions, hierarchies, reporting structures, and in some cases teams, but there’s another way to represent an organization by what it does, and for whom it does it. The value streams that support, design, develop, and deliver value stretch across your organization and out to customers. As you visualize them, an interconnected network begins to appear, your value stream network.
Our typical view of an organization is restricted to a narrow slice
Value Networks
Back in 1993, Clayton Christensen introduced the concept of the value network: “the context within which the firm identifies and responds to customers' needs, procures inputs and reacts to competitors.“ which identifies a “nested system of product architectures” in addition to internal and external actors.
In his 1995 book 'The Great Transition' where he identifies value streams, James Martin alluded to a network of value streams as well: “As knowledge flows over networks, it enables events to take place more efficiently, saving intermediate steps.”
The concept of a value network forms the foundation for a value stream network. The streams deliver value to customers. Customers can receive value from multiple streams, and streams are rarely autonomous.
Seeing Your Value Stream Network
There are many different ways you could begin to visualize your own value stream network. Here are a few ideas based on work I’ve done to map networks in the past:
Streams From Journeys
You can start to map out a value stream network in different ways, depending on your point of reference. Because value streams are ultimately about customer outcomes and business value, it can help to start with a customer journey if you have one to refer to. Looking for the streams of activity that deliver critical touch points in a customer journey reveals an interconnected network of streams, each supporting either a journey or other streams.
A typical customer journey enabled by value streams
If you’re looking to form a bridge between technical and business teams, the customer journey can be an extremely valuable resource to facilitate effective communication and understanding.
Team Topologies Interconnected
Stream-aligned teams can serve as a solid foundation for a bottom-up visualization of your value stream network. You can plot both your product and platform teams within streams that reach forward to customer value delivery, and back to ideation and planning. A value stream network tends to be one level above teams, as streams commonly incorporate multiple teams working as a relay or in parallel.
Team Topologies can form the starting point for a network view of your value streams
The Team Topologies representation can either serve as a starting point or a bridge between the stream and team level.
Start From Value
One of the most efficient and effective ways to map is to start with a target outcome in mind. Do you want to deliver a specific product more often? Do you want to lower infrastructure costs? Starting from a clear target will help you zero in on the stream or streams that will directly impact that outcome, and you can branch out as needed where you find dependencies. This saves you from having to map out the entire organization or getting lost in the details. You can map whatever scope matters most, at the level it’s most valuable to you. As a result, your map will cost less to produce, and it will be simpler to understand and work with.
Mapping Your Network
One of the most useful ways I’ve found to map is to plot teams or streams to consider the focus of each stream and use that to differentiate it and plot it on a map. By considering the customer served by each stream you can identify an internal focus and plot the Y-axis. Is it focused on an internal or external customer? By considering the performance focus of the stream you can plot the X-axis. Is it focused more on efficiency or innovation?
By considering different dimensions you can visualize the differences or similarities across multiple streams and expose interesting insights. Are all your streams clustered in one area? Do they all have a single dependency?
You could use any number of dimensions to plot your streams, such as customer persona or need. Although it has a focus on capabilities rather than streams, there’s a lot of value to borrow from Wardley Mapping here when it comes to customer needs. The main difference with streams is that they can change focus from efficiency to innovation. This is different from capabilities that just become commoditized over time - a stream is dynamic and can change focus whenever the contributors want to change it.
You can plot streams by differentiating the focus of each stream and how they connect
Why go to all this trouble to map your value streams? The more detailed the map, the more detailed your strategic and tactical discussion can be. If you’re reorganizing or tackling a challenging organizational performance issue, a quick visualization of your network of flow can get everyone on the same page, aligned, and clear on the next steps.
The Generative Network
A few months back I was inspired by the code generation capabilities of ChatGPT and asked it to plot a prototypical organization as a graph network and got really impressive results:
A value stream network diagram generated in javascript by ChatGPT
What’s interesting here is that the graph can be updated in real-time, and driven by external systems, so if you wanted to create a dynamic representation using your Jira instance, google sheets, and a little javascript you’re not far from your own real-time network visualization. You can plot interesting dimensions like size based on the number of dependencies (or maybe lead time!), or use color to denote the focus of the team, customer persona, or need.
Like any model, a value stream network won’t be a perfect representation of your organization, but it can be extremely useful to visualize, discuss, and design with colleagues and anyone you want to have big-picture conversations with.
Patrice Corbard, SD ReFocus
Towards Value Streams as Autonomous as Possible
The organization of small cross-functional product teams (stream-aligned teams) aims to accelerate their value stream. The key is to ensure their autonomy by empowering them to make decisions and do all the work necessary to quickly build and evolve the product they own (build and run teams).
The first steps of the VSM Implementation Roadmap identify the functions involved throughout the value stream, from ideation to delivery of the product to the customer, as well as the links with other internal or external value streams:
- Organize - The idea of designing product teams of less than 10 people very quickly raises the question of their possible autonomy. Will they be able to handle the cognitive load covering all business and technological aspects? Will they have the capacity to combine all the necessary expertise within their teams, or can they be helped and supported by setting up platforms, enabling, and complicated subsystem teams?
- Map - Value stream mapping teaches us to see not only the sequence of value-creating activities but also the real interconnections between individuals and entities within our organizations.
As soon as a Value Stream Mapping workshop is prepared or started, it's often clear that a value stream involves many different actors, and that few or no one really knows how the whole stream works.
There are various reasons why a value stream does not find itself independent from the rest of the company: need for expertise or task completion, product architecture, access to a shared resource, etc. Value streams and their teams are not independent but interconnected. Their connections can be stronger or weaker due to their respective missions and the type of their interactions.
On the other hand, we can strive to make them as autonomous as possible, so that they are able to meet their challenges without having to wait unnecessarily because of external dependencies with other teams or value streams.
Company-level Systems Thinking of Value Streams
Value Stream Thinking means always thinking of the system as a whole, to avoid focusing on local optimizations that don't really benefit the whole. End-to-end value stream optimization is based on this principle, which is taken up in the first of the Three Ways of DevOps.
However, if we treat a value stream as a single entity without addressing its relationships to its ecosystem, we can fall into the same pitfalls of not seeing the forest for the trees.
We may be tempted to limit our analysis to what is in our power, on our internal territory. But is it really worth trying to save hours or minutes on software delivery engineering, if an external dependency regularly blocks us for days or weeks?
It is therefore crucial to be able to go up to the enterprise level and visualize the network of value streams with their interconnections.
Visualize the Value Stream Network
Value streams can be of different types, with value streams aligned with the products to be delivered to customers (stream-aligned teams or core value streams) and others supporting them by making platforms available to them in the form of services (platform teams or supportive value streams).
As we indicated in our previous post "Is Platform Engineering a Value Stream?" and as Steve explained earlier, it is possible to use the models proposed by Team Topologies to design or redefine our organization of teams and their interactions.
There are other techniques to visualize these value stream networks, but they don't seem to me to be very widespread or fully supported by tool-based solutions yet:
- High-level mapping of value streams to represent their interconnections;
- Modeling our enterprise architecture with the alignment of value streams with business domains, their contributions to the customer journey, and their interrelationships.
Focus on Dependencies that Impede the Flow
Visualizing the value stream network is not an end in itself! The goal remains to streamline activities by identifying dependencies that impede the rapid flow of value. In this case, it is a question of removing the main constraint of our system on which we must focus our improvement efforts.
« A dependency is just a blocker that hasn't happened yet.
When a team is blocked by a dependency, work sits needlessly idle.”
– Troy Magennis
Interestingly, new tools are emerging to go beyond managing a list of dependencies. Data-driven, they concretely help identify the most impactful blockages that are slowing flows between teams across the value stream network represented in the form of a dynamic graph:
Figure - Predictability360 (in beta) visualizes the days lost by teams blocking other teams
Ortwin De Witte, Flow 4 Outcome
Redefining Organizational Design with Value Stream Networks
Admittedly, viewing organizations as social networks and understanding a value stream are not new concepts. However, the idea of a Value Stream Network as an abstraction for an organization is a relatively recent development.
Let’s look at the hypothesis that we can be better at organizational design if we use the concept of Value Stream Networks.
To the best of my knowledge, the exact term was introduced by Mik Kersten in his book “From Project to Product”. Notably, even in 2017 DOES Journal paper co-authored by Mik Kersten about Value Stream Architecture and the role of a Value Stream Architect, there was no mention of the term 'Value Stream Network'.
Shifting to what I will discuss later, my perspective on a Value Stream Network was soon significantly influenced by the book “Team Topologies”. This connection is far from coincidental. As Mik Kersten and Manuel Pais explored in episode 42 of the MIK+ONE podcast these concepts naturally align or as they put it “Project to Product, Accelerate and Team Topologies, these things somehow dovetail.”
This idea of concepts that "dovetail" also reminds me of Susanne Kaiser's approach, where she combines Wardley Mapping with DDD and Team Topologies. Using a cooking metaphor, the essential ingredient that might tie these elements together beautifully in an organization could very well be the concept of a Value Stream Network.
If the value gets delivered to our customers via a Value Stream Network, we want to make this as efficient and effective as possible. We’d like to “build the right thing”, and we’d like to “build it right”. If we acknowledge that every item going through the Value Stream Network is about hypothesized value, getting fast feedback is key and makes an optimized Value Stream Network even more important. So there are good reasons for wanting to know everything that could impact the flow and throughput of our Value Stream Network.
We know that we have to look holistically at the total system. We also know that “systems are not defined by the components (or in the case of a process, the steps) but rather the relationships between the steps.”
Further, we’ll look at these relationships. If the Value Stream Network can be represented by a graph, let's look at the edges of our graph. The nodes are the teams, the edges are the interactions between teams.
However, before diving in, let’s take some steps back.
A Value Stream and the Idealized/Generic Value Stream
Everything starts with understanding the concept of a simple value stream.
“Whenever there is a product for a customer, there is a value stream.” As described in “The Idealized Value Stream of the Effective Organization” we know how for most organizations the high-level workflow would look like. As we know by now, a linear representation is too simplified to represent reality. But for the sake of this story, this Idealized or Generic Value Stream could look like this in a very simplified version:
In the idealized situation, this entire Value Stream is owned by one cross-functional team. Startups have their own challenges, but yes, every startup is fundamentally such a stream-aligned team, enjoying a continuous flow of work to a business domain, having clarity of purpose, empowered to build and deliver user value as fast, safe, and independently, and having no hand-offs to other teams.
Handoffs
In real life, most teams are in different situations. Even more so in larger companies. As we can see in the non-exhaustive visualization by John Cutler based on Marty Cagan, there are many variations of how much of the flow is owned by a single team, with or without internal and external handoffs.
But as Mik Kersten has put it in his third epiphany: it’s not a value stream, it’s a Value Stream Network: “the network formed by the connections within and between software value streams”. If “the nodes in this network are the teams of people”, then the external handoffs (between teams) are the first type of relationship or interaction between teams in a Value Stream Network (see also Steve’s “teams working in relay”). Because Team Topologies is providing a reference (with patterns and principles) for a cross-functional team, this type of team interaction is (rightly) undiscussed in Team Topologies. This relationship is an anti-pattern that we want to avoid or remove in existing organizations. If however, we want to be able to make a real-life Value Stream Network visible (= map the network), and if we want to visualize this Value Stream Network (= create the Value Stream Network map), then it might be useful to have a light-weight convention and notation to visualize this type of relationship.
Team Topologies, DDD, and the Value Stream Network
As mentioned earlier, the concept of a Value Stream Network goes together well with insights from other communities.
The four team types and three interaction modes described by Team Topologies can be integrated beautifully into how we would describe a Value Stream Network.
In the Team Topologies visualization of teams, the stream-aligned team clearly and rightfully gets the main focus. Also in how it’s represented: the stream-aligned team represents the flow of value. The other teams are always supporting the stream-aligned team(s) in some way. The three interaction modes define how the teams interact. This would allow us to visualize these relationships in our Value Stream Network map based on the notation provided by Team Topologies.
The DDD community also offers different interesting viewpoints. If we want to allow for maximum flow, we need to aim at value streams (or value stream (sub)networks) that can act as independently as possible. In order to make this happen, we need to look at the business domains and organize our Value Stream Networks taking these into account. In how many organizations is the business architecture truly aligned with the often many IT divisions that are delivering the software that should support the business (domains)? Divisions that are often organized based on technological specialisms? Do we have to be surprised that a single-piece flow is most of the time unthinkable due to the many transition points in the software delivery process in large companies?
Another potentially interesting addition from the DDD community is how DDD looks at bounded contexts and collaboration modes. Team Topologies offers three interaction modes, but if we want to visualize how for example different stream-aligned teams need to interact, these collaboration modes offer more than food for thought. They can give us extra options in visualizing how teams interact in our Value Stream Network. With regard to bounded contexts, it’s at least interesting to think about how to map teams to one single or multiple bounded contexts and to reflect on how this could impact the flow and throughput of our organization.
The Idealized Value Stream Network and a Value Streamlet Network
If the nodes in a Value Stream Network are the teams, then the teams will cover a full value stream in the Idealized Value Stream Network. In real life, however, teams don't necessarily cover a full value stream. As we have seen, sometimes they cover only a part of the value stream. This however doesn't make the concept of a Value Stream Network useless in those cases. The Value Stream Network as a concept is a reference, a model. In real life, we will probably be looking more at something that we could call a Value Streamlet Network. Organizations often aren’t yet in their desired state.
How can these insights help us?
Thinking of an organization as a Value Stream Network offers us a lot of possibilities to improve our organization with an adaptive approach.
Simply trying to map an existing organization as a Value Stream Network including Team Topologies team types and interaction modes will make people think about how they are (or aren’t 
The concept of a Value Stream Network obviously offers the possibility to apply all the benefits of a value stream-centric approach. We can (and should) start small. We can apply Value Stream Mapping to a reduced scope. We can zoom in on a (sub)segment of the Value Stream Network, or we can zoom out and look at the Value Stream Network more high-level. We can put fence posts in as Karen Martin would say, while keeping in mind that when we look at a local optimization we need to acknowledge that we need system thinking and the learning needs to continue.
Related posts:
- What is a Value Stream?
- Value Stream Mapping Practices
- Principles of Value Stream Identification
- Questions on Value Stream Identification
- Is a Customer Journey a Value Stream?
- Is Platform Engineering a Value Stream?
Reference:
- Discovering Your Value Stream Network by Carmen DeArdo
- The Flow Framework®: A Prescriptive Approach For Transitioning From Project To Product
- Introducing Predictability360 by Predictability at Scale
- Manuel Pais Episode Transcription
- See The Journey to Product Teams (Infographic) | Amplitude
- A Startup is fundamentally a Stream-Aligned Team. Then stuff goes south
- The Idealized Value Stream of the Effective Organization
- About Team Topologies and Context Mapping
- Adaptive, Socio-Technical Systems with Architecture for Flow: Wardley Maps, DDD, and Team Topologies
See also our research and learning from here:
- State of Value Stream Management Reports
- VSM Foundation Course, in particular modules 2 (Identifying Value Streams) and 7 (Organizing as Value Streams)
Comments 0