Inspired by Michael Dubakov’s article Flow. Discover Problems and Waste in Kanban, I thought I’d spend some time looking at Value Stream Analysis.
We talk a lot these days about delivering value to our clients, but many of us don’t understand the details of how that is accomplished. Sure we understand that raw ones and zeros couldn’t be sold for the same amount as the aggregated application, but let’s take a more concise look at a couple questions? 1) How do we define value. and 2) How do we analyze the process by which we deliver value? (Value Stream)
The first question we seek to better understand is the definition of value. Without diving head first into an economics discussion, we can simply look at value as our client’s perceived worth of the product or service we provide. This has a dollar figure attached to it. While one can argue that value is also inclusive of the qualitative aspects of our product or service, it is not easily measured, so for purposes of this discussion can be ignored. I defined a method of assigning a dollar value to SaaS features in one of my previous posts. This method can also be used to determine the dollar value of a release, iteration, feature or task on either products or services. With a dollar value in hand we can begin to look at answering question #2.
As we begin to examine our Value Stream, I would be remiss without mentioning the work of all the people that have contributed work in this area, Eliyahu M. Goldratt, Taiichi Ohno, James Womak, Kent Beck, Mary Poppendieck and Tom Poppendieck, to name just a few. In Tom and Mary’s book Lean Software Development, they present Tool #2 – Value Stream Mapping which gives us a good way to visually represent our Value Stream:
If we look at the figure above, we see the typical steps that an Agile team may follow transforming an idea into reality. There is active work that is done on the idea/feature (above the line, value add) and time when the idea/feature sits dormant. (below the line, waste) Examining the timing of the above hypothetical flow, we can see that the overall process took 18 weeks with 11 weeks (61%) delivering value and 7 weeks (39%) of waste. This example is a bit far fetched but is meant to provide a simple means of showing how the map works. You may find it more useful to use days as a unit-of measure or even hours. The point here being that you may be able to reduce your feature time to market to only 11 weeks if you could only avoid wait time. If we assume that the feature we are developing will provide $5000 of value in the market, (to our clients) then at 18 weeks we are only delivering $278 of value a week, whereas we hit $455 a week when we do it in 11 weeks.
This can be a very useful tool for improving the productivity of your development organization but we need one more piece to make it effective. Since we are not developing one feature at a time we need to understand the effects of multiple features flowing through our value stream. If we only seek to optimize the flow of one feature’s flow we may do that at the expense of others. We must look at the system as a whole and try to optimize elements that will reduce our wait time for all ideas/features currently in progress. This is not an easy task. You should look at the steps that are costly first and try to identify the pain points in those steps. For instance, if there are days lost because team members are unaware of a status change, seek to implement a tool that sends automated emails on status change.
In summary, here are the steps to analyze your value stream:
- Create a map of the steps that an idea takes from concept to delivery.
- Measure the value-add and wait time of a number of ideas as they flow through this map.
- Assign a dollar value to your ideas and measure your current weekly value and share this with the team.
- If changes were already made to try to increase the flow of value, did they work? By how much?
- As a team, come up with changes that will increase the flow of ALL ideas through the system.
- Implement these new changes and go back to #2.
