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 as.net


• 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

Conclusions
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.

.