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.


Make Sure to Get Both Sides of the Story When Value Stream Mapping

when conducting a stream mapping session I recommend considering the following...

  • people are much more likely to find inefficiencies in other group’s work than the work they are doing

  • many individuals don’t understand or really appreciate the value that other groups provide. (Eg developers struggle with architects, business struggles with IT, overall delivery teams struggle with operations and infrastructure)

What this means is that you absolutely have to include an outsiders perspective when conducting value stream mapping session. People within an organization or department of an organization really have a challenging time in even identifying internal issues until either clients or suppliers are brought in to discuss challenges from their perspective.

When ever doing a value stream map, do your best to include someone who is an outsider from the perspective of the scope of what you are mapping. Obviously that outsider has to be part of the value "ecosystem". But needs to be able to look at what the group is mapping from the outside in.

While there has been much discussion within the lean about how trade-offs between groups are one of the biggest efficiency killers, it think including value stream "outsiders" does a lot more than just aid in identify these external hand off related issues. The interaction between people from different groups encourages a much deeper look into the internal processes of the value stream. Bad service can often be equally blamed on issues from both the client and the partner, and getting them together encourages them to figure how to to take an honest look at how they are working and dig deeper to come up with solutions.

value stream mapping

Sunday, March 7, 2010

Leadership and Accountability

When trying to help an organization to improve their delivery processes,be prepared to hear the following soundbites

  • our (the organization) clients are awful at setting priorities,and there's nothing we can do to change this situation...
  • our suppliers are completely ineffectual...
  • we are streamlined and as efficient as we could possibly be...
while this can be frustrating, this is to be expected, the important thing is to include members from other teams when trying to improve a process. invite both the supplier and customer as well as any other stakeholders of a particular process that you are trying to improve.

This promises to continue to be a challenging project,