Value Stream Mapping is a powerful lean tool that is commonly used in Agile and DevOps implementations as a foundation for continuous improvement and transformation, but its application doesn’t always lead to the expected or desired result. Author Jeff Pierce's article helps you to avoid some of the most common failings companies encounter when they try to implement it.
As an Agile Coach, Scrum Master, and instructor, I meet and interact with many people who have used Value Stream Mapping to successfully transform product and service delivery by focusing on value delivery to their customers and eliminating waste in delivering that value. Unfortunately, I often hear from people who have attempted to use Value Stream Mapping and have failed. They failed to identify and create a shared understanding of what is important to the customer, failed to identify and eliminate non-value-add (NVA) activities from their delivery processes (waste!), and ultimately failed to improve their customers’ experience.
What is Value Stream Mapping?
Before we can talk about how a Value Stream Mapping effort goes wrong, we need to discuss what it is and what its purpose is. Value Stream Mapping origins are from Lean manufacturing and a Value Stream Map (VSM) is a lean tool that is a complete visual fact-based time-series representation of the stream of activities required to deliver a product or service to a customer. The VSM provides a holistic view that can create a shared understanding of the entire delivery process, from the original customer request through to the end delivery to the customer. In short, the goal is to provide a simplified picture of the overall delivery process to drive improvement. The VSM picture (see examples below) includes metrics that provide a quantitative foundation for strategic data-driven decision-making. This blog is not a guide on how to create a VSM but an exploration of why Value Stream Mapping efforts fail.
The image below illustrates the core components of a traditional VSM for a manufacturing company. This view provides customer inputs, information and materials flows, and workflows and processes. Note also there are metrics for each process and a lead time ladder that separates value added work time from non-value-added (waste) time.
Wikipedia – https://en.wikipedia.org/wiki/Value-stream_mapping
The example below is a VSM for software delivery (current state) that again illustrates the processes from client request though development and delivery with significant flows and process metrics.
Without this view and understanding of the delivery process, organizations will typically fail to create customer-centric workflows and processes and have difficulty with efficiently providing value to their customers.
Creating a Value Stream Map
The process for creating a VSM is fairly straightforward. You start with planning and preparation, which includes garnering leadership support, scoping, teaming, data collection, and preparing the organization for Value Stream transformation. Once you are prepared, you start understanding the current state.
Following a kickoff, you create a high-level process definition and perform value stream walks, a form of a “Gemba” walk, or going to the place where value is created. Value Stream “walks” involve observing the processes, talking to those performing the work, and gaining a firsthand understanding of the work to create and deliver products and services at your organization. This is an iterative process, and the Value Stream Mapping team gains deeper levels of understanding during each walk until they are able to fully and accurately document and create the current state VSM and verify it with participants.
Optimizing the Value Stream
After constructing the current state map, the next step is performing value analysis to identify opportunities to optimize and improve the value stream. A Lean focus on identifying the “right” value delivery improvements includes elimination of waste (muda), unevenness (mura), and overburdening (muri). The value analysis will identify opportunities for optimization and standardization to increase value delivery.
At this point the team would make decisions about what to improve and begin designing the future state, which can involve the removal, redesign, and creation of new processes and redesigning workflows to optimize the future state.
Common Value Stream Mapping Failures
Leveraging Value Stream Mapping has far reaching impacts and can be a powerful tool for identifying strategic organizational improvements. However, many organizations are unable to realize the full benefits of VSMs due to a number of common failings:
- Mapping with an inappropriate team—The mapping team needs to consist of cross-functional members who are capable of examining and understanding the intricacies of the work being mapped. Further, since mapping is a strategic improvement activity and the team will be designing the new future state, which will include organizational changes, the team will need to include individuals who have the authority to make that level of change. Organizational leaders must participate, both to understand the realities and issues of the current state and to participate in the development of the new improved state.
- Mapping without an appropriate understanding of customer value—Creating the “customer perspective” internally without actually talking to customers or customer representatives will lead to misinterpreting what is or is not valuable to customers and will impact the VSM when trying to differentiate value-added activities from non-value-add activities.
- Mapping without developing metrics—VSMs have three critical components that include information flows, workflows, and timelines. Understanding the time it takes to accomplish throughput and the quality of the output is critical to understanding opportunities for improvement. Accurate measures for cycle times are necessary to correctly identify bottlenecks. Using outdated or estimated measures will lead to poor analysis and potentially trying to improve the wrong processes. A VSM without metrics will not provide targets for process redesign nor the foundation measures needed to measure the success of the future state implementation.
- Failing to adapt mapping for knowledge-based or non-linear work—Value Stream Mapping origins are from lean manufacturing, where flows are typically linear and departmentalized. In knowledge-based and non-linear work environments, VSMs need to be adapted to take into account the cross-functional interactions and collaboration necessary to accomplish work or improvement opportunities will be misidentified or overlooked.
- Analysis Paralysis—Scoping the mapping effort is critical as trying to map everything will result in the team getting lost in the detail and failing to map the flow and failing to identify critical improvement opportunities and solutions.
- Creating VSMs during a Kaizen (specific change improvement) event—Value Stream Mapping is a strategic activity whose purpose is the creation of a plan and alignment for improvement. Kaizen events are activities whose purpose is the design, test, and implementation of specific improvements. Value Stream Mapping should precede the Kaizen event, identifying the plan and targets for the Kaizen activities.
- Using maps for tactical improvements—Using VSMs only at the process level will miss the entire point as the macro-level view is necessary to create organizational understanding and alignment. Value Stream Mapping is used to set strategic priorities, and limiting the VSM to only certain functions in the organization will result in a limited view of reality and the issues in cross-organizational interactions. Process-level mapping is more appropriate for deeper exploration of sections of the value stream where improvement opportunities exist.
- Re-engineering Approach—Value Stream Mapping activities can lead to a re-engineering approach as opposed to incremental and continuous improvement. A re-engineering approach is very disruptive to an organization and can create value delivery issues while the organization is implementing new processes. While this may be necessary, I have been on engagements where the organization was moving backwards and stopping to re-engineer was more productive than continuing. It is generally a better practice to take a more Agile approach, which is to make a small set of changes and understand (learn) the impact, and then make the next set of changes. This is less disruptive and will potentially prevent large impacts from flawed process redesign.
- Creating Maps but taking no action—Many organizations will undertake the effort to create current state VSMs but fail to design the future state or create implementation plans to transform to the designed future state. While this may be valuable to inform and align, the goal and true power of Value Stream Mapping is the improvement of the value stream, which cannot be accomplished without actually implementing change.
In conclusion, Value Stream Mapping is a powerful lean tool that is commonly used in Agile and DevOps implementations as a foundation for continuous improvement and transformation, but its application doesn’t always lead to the expected or desired result. I hope this post helps you to avoid some of the most common failings companies encounter when they try to implement it.
Great article. Some important points the author makes that I would like to reiterate (in the author's own words):
1. "Failing to adapt mapping for knowledge-based or non-linear work." Indeed, most knowledge work, including product development, is not linear. It is iterative to a large degree and collaborative to some degree. Product development is dominated by deep-focus activities, interspersed with collaboration across functional areas. It is non-linear.
2. "Analysis Paralysis—Scoping the mapping effort." Remember that the purpose of a VSM activity is not to document the process. The purpose is to find "Lean wastes" - problem areas. As such, focus where the problem areas are. Trying to capture too much detail where there is not a problem is a waste of time.
I would also like to point out that VSM comes from Lean manufacturing, and its purpose was to improve production flow. However, when applied to software product development, one is not actually mapping the value stream: one is mapping the capability development and delivery process. That is, one is mapping the processes that are used to maintain and add to the current software systems. Those software systems deliver value - their use constitutes the value stream. That needs to be understood too, but it is separate/distinct from the capability development/delivery stream, which is now the software is developed. That is the process that needs to be mapped, so really that is not a VSM, but is a "capability development stream map". But that is a mouthful: when talking about this most coaches mean that when they say "value stream map".
Hi Jeff, Thanks for sharing your expertise on VSM.
I'm particularly interested in your comment "Failing to adapt mapping for knowledge-based or non-linear work—Value Stream Mapping origins are from lean manufacturing, where flows are typically linear and departmentalized"
'Agile' Product Development often involves a hypothesis driven iterative and incremental approach and that's a good thing! I'm interested in your opinion on how appropriate a VSM approach is in mapping and eventually improving such a process.
Lets assume that the VS being mapped is one that delivers Product Features (and hopefully some Customer Value). The trigger is the identification of an unmet market need, the endpoint is delivery of a Feature( or Product/Service/whatever). The approach taken will involve running experiments to create feedback loops to guide the next stage of development. All Features follow the same process of ideation, iterative and incremental development but the actual process for any two features will be different: there isn't the linear path one would expect in say manufacturing.
Thoughts on adapting VSM for these scenarios appreciated.
I think the work Mik Kerstan / Tasktop has done on 'Product Modelling' may address this issue: he proposes integrating all tools involved in the creation of value in a VS with a hub/integrator so that all events in the flow of value (features in this case) can be recorded and monitored and used to create insights on actual lead/cycle times on features as they move through the Value Stream. This is interesting in that it takes a different approach to VSM: it records all the data one would need to do a VS mapping exercise and lets one analyse the results. This would take account of the high variation in process that different features took through the Value Stream. (I haven't used and am not plugging Tasktop! I have read Mik's book 'project to Product' which was very insightfull.