Why the Way You Visualize Value Streams Matters

This article explores how value streams can be visualized – and why the choice of model matters more than you might think. Unlike models locked in mass production thinking, new approaches like the Assembly Line Model embrace the specific characteristics of modern product development. The way you visualize your value streams decides what you see and how you act.

‍Visualization is Modeling

When we visualize a value stream, we are always creating a model. A model simplifies reality by selecting certain aspects, abstracting details, and representing them in a useful way. As George Box noted, “All models are wrong, but some are useful.” The usefulness of a model lies in what it highlights, not in capturing every detail. A good model makes complex systems easier to understand. It helps people see the most relevant aspects, engage in meaningful discussions, and build a common understanding. In the context of value streams, the right model clarifies purpose, reveals strengths and weaknesses, and points to opportunities for improvement. Most importantly, it enables better decisions about how to set up the value stream – how to organize around value and optimize flow – so that outcomes are delivered faster, with less effort, and at higher quality.

Taking a historical view helps explain why different modeling approaches emerged and evolved. Traditional lean models, such as the material and information flow map – originally developed at Toyota and later documented by Mike Rother and John Shook¹ in Learning to See – provided the foundation. Morgan and Liker² adapted the mass-production model into a lean product development approach, which was later refined with elements like swim lanes, influenced by business process mapping practices.³ In turn, the DevOps community adapted these models to fit its context. Yet, despite these advances, most approaches remained rooted in the original mass-production mindset.⁴

‍A new Model tailored for Product Development

Yet, despite their differences, these models remain anchored in the mass production paradigm. They emphasize repeatability and efficiency but fall short of addressing the dynamics of modern product development. While each model can still serve a purpose in the right context, the real question is: how well do they align with today’s iterative and incremental approaches? To explore this, it helps to contrast the assumptions of the mass production mindset with those of the product development mindset.

Traditional value stream mapping originates from manufacturing, where the goal is to produce consistent batches of similar items on a production line. At the end of the process, you expect a uniform set of nearly identical products. In this context, going back to a previous station is seen as a failure – it indicates that a part deviates from the standard, introducing unwanted variability into an otherwise controlled and repeatable process.

But software and cyber-physical development doesn’t follow the rules of mass production. We’re not producing batches of identical items – instead, we’re evolving a product that adapts, expands, and improves over time. Features, bug-fixes, and enhancements are added incrementally or in parallel, and the product gains new capability as it moves through the development process. The result is not a collection of uniform outputs, but a product that continuously evolves in response to learning and market insights. Iteration is not rework – it is the engine of progress, often leading to better solutions, deeper understanding, and higher quality. This kind of positive variability – where ideas improve as they are tested and refined — is not just accepted; it is essential. To make this possible, product development relies on short feedback cycles, smaller batch sizes, and reduced transaction costs, all of which improve flow and accelerate economic decision-making. Shift-left practices further strengthen these loops by bringing testing, quality, security, and compliance earlier into the process – building quality in from the start. Together, these practices enable faster learning, higher quality, and the continuous delivery of value to customers.

‍Why It Takes the Right Model to See

As explored in Why Value Stream Thinking, breakthroughs in complex systems rarely come from more data – they come from a model that makes structure and causality visible. One of the most powerful illustrations of this principle comes not from engineering, but from medicine⁶.

In 1854, London was in crisis. A cholera outbreak was killing people in Soho. Hundreds died within days. The dominant belief at the time was the miasma theory – people were convinced the disease spread through “bad air.” The smell was blamed. The weather was blamed. The air was blamed. And the more people died, the more confident they were in the wrong explanation.

John Snow didn’t start with a new theory. He didn’t collect radically new data. He didn’t win an argument. He changed the model. He took the same death records everyone else had – and placed them on a map. Suddenly, something became visible that had been invisible before: a cluster. Almost all deaths were concentrated around a single water pump on Broad Street.

Same data. Different representation.

When the handle of that pump was removed, the outbreak stopped. The breakthrough came from a better model – and that model gave birth to modern epidemiology.

The parallel to product development is direct: most organizations already have the data. What they lack is a representation that makes the structure of value flow – its bottlenecks, feedback loops, and dependencies – visible. The following section explores what such a model looks like.

‍Finding the right Model for Product Development

The proposed Assembly Line Model – which addresses these challenges – is introduced in The Assembly Line Model – A High-Level Introduction and explored in depth in the articles on Assembly Line for Value Stream Identification and Assembly Line for Value Stream Optimization. A complete overview of all related guidance is available at the Value Stream Thinking Overview.

Conclusion

Visualizing value streams goes far beyond drawing diagrams – it is about creating models that shape how we understand, discuss, and improve the flow of value. As the story of John Snow illustrates, the breakthrough rarely comes from more data – it comes from a better model that makes the right things visible.

Traditional approaches rooted in manufacturing provided important foundations, but they fall short when applied directly to the dynamic, iterative, and feedback-driven nature of modern product development. Software and cyber-physical systems evolve continuously; iteration is progress, not failure. In this context, effective visualization must highlight feedback loops, learning cycles, and the practices that enable them – smaller batch sizes, reduced transaction costs, and shift-left approaches that build quality in from the start.

The Assembly Line Model addresses this need by offering a structured yet flexible way to represent how value truly flows in product development. Ultimately, the right visualization is the one that reduces complexity to the level required, fosters shared understanding, and guides meaningful action.

‍Appendix – Which Modeling Approach Fits Which Context

When looking across industries, we can distinguish three major approaches to modeling value streams.

• The Material & Information Flow Map, rooted in Lean mass production and popularized by Rother and Shook, focuses on visualizing physical product flows.
• The Product Development Value Stream Mapping (PD-VSM) method, described by Morgan and Liker, adapts Lean thinking to knowledge flows and cross-functional collaboration in product development.
• The more recent Assembly Line Model, often used in DevOps and digital contexts, addresses the unique characteristics of software and cyber-physical systems with iterative and feedback-driven workflows.

Notes & References

1. Rother, Mike, and John Shook. Learning to See: Value Stream Mapping to Add Value and Eliminate MUDA. Brookline, MA: Lean Enterprise Institute, 1999. ↩︎
2. Morgan, James M., and Jeffrey K. Liker. The Toyota Product Development System: Integrating People, Process, and Technology. New York: Productivity Press, 2006. ↩︎
3. If you have more information about the historic background of swim lanes in value stream mapping, please contact me. Current evidence suggests they were introduced by Rummler and Brache in Improving Performance: How to Manage the White Space on the Organization Chart (San Francisco: Jossey-Bass, 1990) as a way to clarify roles and responsibilities across functions and address performance gaps in the ‘white space’ between organizational units. ↩︎
4. Another common high-level notation represents value streams with chevrons, used mainly for introductory or definitional purposes (as done in our article Types of Value Streams) to illustrate the major steps from the initial trigger to the delivery of value. The Scaled Agile Framework uses the Chevron representation as starting point of its Value Stream Identification. I am still looking for the origin of the chevron representation. ↩︎
5. https://commons.wikimedia.org/w/index.php?curid=28553995 ↩︎
6. The story of John Snow and the 1854 cholera outbreak is vividly told in Johnson, Steven. The Ghost Map: The Story of London’s Most Terrifying Epidemic – and How It Changed Science, Cities, and the Modern World. New York: Riverhead Books, 2006. ↩︎