Saturday, March 13, 2010

An Overview on Value Stream Mapping for Software Delivery

Value Stream Mapping (VSM) is a Lean process tool that can help teams to get an understanding of where some of their biggest problems are. When done correctly, value stream maps are produced by collaborative, high touch, low ceremony session that can lightly apply a structured method to identifying organizational waste and potential areas for improvement.

When conducting these sessions, I tend to focus on 3 lean tools. (It should be noted that Alexis Hui created all these fancy graphics

  • Value stream maps

  • 7 wastes as identified by Mary Poppendick

  • 5Ys approach to root cause analysis


Value Stream Mapping

Value stream maps can be used to map the flow of work from the start of the delivery process (ex: client request) to the end of the delivery process (ex: system delivered to the client). They are similar to process diagrams, but meant to be much less detailed, but getting things into process areas.

There is lots of advice from the manufacturing world discussing how to do Value Stream Mapping in non-IT delivery context. Many of the examples have complex notations, lots of symbols and icons that may, or may not apply to the software delivery context. Folks like Mary Poppendick, Alan Shalloway, and even Kent Back recommend taking a much lighter approach, using a much simpler notation. During our session we focused on using for simple icons preprinted on sticky notes. We also asked the group to focus on giving their opinion on a couple of key metrics for each of the icons


7 Wastes of Solution Delivery
While value stream maps are being drawn, very as participants in the session will recognize obvious inefficiencies relating to bureaucracy, delays, people being too far away from each other etc. As these wastes are recognized participants can apply them to the various process boxes or inventory pieces. Shown below are the 7 wastes as identified by Mary Poppendick her book Implementing Lean Software Development: From Concept to Cash


5 Whys

As errors are identified by participants in the value stream mapping sessions it’s important to reflect on the underlying issues of these problems. In his book, Agile Software Development: Achieving Enterprise Agility, Alan Shalloway recommends using a simple but powerful tool known as the 5 whys to do root cause analysis.
While our experience has been that strictly following the five whys is not necessary to get the heart of all problems, it’s A good way to kickstart conversations when progress is stalled, and it can help apply some structure to participants who sometimes can descend into too much detail or go off topic.


Structuring the Facilitation

while the sessions are meant to be applied with an open approach, we have found that lightly applying some structure to the value stream mapping sessions makes it much easier to get newcomers who have never done by Stream mapping before the start.
The process that we used involve the following steps:

  • identifying and categorizing various families of value streams

  • mapping the various identified value streams into various process areas and inventories

  • measuring things such as cycle time, value generation time, and waste for the various value streams

  • performing root cause analysis on the areas with the worst ratio of value to non-value-added activities, performing the five whys as necessary

  • developing homework for members in the sessions to immediately act upon


Categorizing the Value Stream Product Families

We asked participants in the sessions to come up with unique value streams based on attributes like

  • solution size

  • new builds versus enhancements

  • legacy versus more modern platforms such

  • distinct business lines

it should be noted that in this organization these attributes cause very different processes to kick in, certainly not an ideal situation but an obvious candidate for improvement, i.e. simple standardization where appropriate.



Developing the Current State Value Maps

During our session we asked participants to map out the value streams, and I have to say despite assertions from noted and respected experts in this field, this was by no means a simple 10 to 15 minute exercise! While we tried to keeping high-level there was significant redundant processes and activities that could only be discovered by going into a reasonable level of detail.
We try to make sure that we are holistic and covering the end and process flow, from business goal setting all the way to operations and support and everything in between.



Measuring the Value Streams

After mapping the value streams, we then solicited participants to put simple measurements where they knew them, writing down on sticky notes things like cycle time, actual effort and size of different inventories. We then flagged areas where there could be significant problem areas. Problem areas could be identified by looking at things such as large backlogs, and long lifetime of inventories, processes were the wait time was large, and really large/complex process flows.



Analyzing Potential Problem Areas

We then used a combination of the seven wastes and the five whys to identify problem areas and do root cause analysis on potential solutions.



Looking at Tactical ways to Implement Improvements

At the end of the session we took a overall look at all the different various value streams, and started identifying common problems across all of these value streams. What was interesting is that even though individual value streams used very different processes, they all suffer from the same pattern of problems. These were

  • an architecture gating process that was perceived to be bureaucratic, cumbersome and contained a lot of duplication

  • infrastructure group that had very high turnaround times for what was perceived to be very simple requests

  • an extremely long project charter/project initiation timeline, which value activities being measured in hours or days, and delays and waste being measured in weeks and months



the sessions were IMHO fantastically successful. Participants were eager to point out new solutions, and the opportunity allowed individuals from different organizational departments to actually collaborate together to come up with new ways of working together. I think the big differentiator between lean continuous improvement tools versus other approaches is that lean encourages the use of approaches that anybody can learn in a couple of hours or days. "Sophisticated" techniques are replaced with mechanisms that allow workers to look at and improve their own processes.



  1. Very well written and thank you for the detailed examples.

  2. Well organized... great details to get a quick start with Value Streaming.

  3. Very nicely written ....what about takt time?

  4. The ideal VSM will capture process rate at each step so that you have the data to balance the future state VSM against takt time. This means a different format then what is used in this article. Drawing a VSM that captures process rate can be done with free software such as what is available at

  5. we, thanks for the shameless plug, I'll go buy that right now and let the profits surge!

    Seriously, taking VSM techniques and applying them literally to knowledge work doesn't well, work. Where VSMs do work is that they are collaborative, low fidelity, and focus on flow. All of the NVA / VA, take time, etc is just guess work, somewhat distracting, and based on opinion when you ae talking about knowledge work. I've for the most part moved on from this article, amd relying exclusively on VSMs, better to get a a kanban up and pay attention to WIP and flow in real time, you will learn more.

  6. Perhaps this blog is not the place to discuss this back and forth so no need to post this if you do not want.


    I agree no one should rely on VSMs exclusively but I disagree that they are distracting. They should be a key step in any improvement program. That being said the VSM you show is more of a flow chart and that is why I put the link to the software that I use...and no you don't have to buy it, it is free.

    I have found that creating a VSM serves two great purposes: It gets a group of people together to start looking at the total flow and it moves people away from hearsay to real information.

    The discussions that happen while creating the VSM are a great team former and the VSM group of people usually goes forward to be the project managers. A proper VSM (done with actual data) will match reality, ie the total NVA will equal the total flow time and the total VA will equal the total direct labor/machine time. So, it is not opinion based.

    A VSM is not the starting point or the ending point, but a key step and so people don't go off and work on their pet projects.

  7. This comment has been removed by the author.

  8. Eliot,

    Your perspective implies a brand of lean influenced by operational thinking. One more suitable to manufacturing and repeatable work.

    Lean for Systems is much more concerned with what are primarily one time processes necessary for creation of new capabilities and developing new products.

    In that space calculating NVA is nonsensical, what is the value add time for building a use case? Doing the design? Getting feedback? Which part was waist? All answers will be base in opinion, not fact. Unlike in manufacturing we are measuring abstractions of information, not tangible goods.IN this space paying attention to queues, looking at failure demand, amount of work in progress, etc...

    VSM while useful, can't be taken literally from manufacturing and applied to knowledge work. Value networks have become the common way to look at this kind of work, not value streams.

    I encourage you to look at work from David J Anderson, Reinerstein, and Shalloway. There has been alot of work done to adapt Lean to this domain, I encourage you to have a look.