Lean Tools: Value Stream Mapping

There are some markets with very little variability of evolution of goods, and that as such can support a very long value stream before arriving in the hands of a customer. In this context, value stream means the list of operations that have to be applied in sequence to a good to bring it from the raw material to the customer.

For example, selling gas and other stable goods like Coke (the example in the Lean Software Development book) works even with a very long chain of operations and waiting times. Even if a Coke bottle takes an year to get to you from the production, the flavor won't change.

But what happens when there is a more rapid obsolescence of the product, like with software features? The longer the value stream is, the less you can respond to the market conditions. Many customers may say they would love and pay to have feature A, and you can only answer "in 120 days in our next release".

Even when you plan what to include in a release on your own, it would take 120 days for your choices to get some feedback from a real customer. The features may be totally useless by the time you reach the next release; you can say farewell to iterative development as a single analysis-coding-testing-deployment cycle is too long already.

Wait time

Fortunately, not all time in a value stream is value adding time, as in that case it would be very difficult to shorten the cycle. A part of the time is spent in value adding activities such as conversation with the customers, analysis of the problem, coding (a big part), testing, deployment and so on.

But another portion of time is only waiting: for developers to be available, or for customer to respond, or for the boss to approve a big change. The larger the value stream, the more opportunities for waiting periods to block development.

Mapping

Value Stream Mapping means creating a map of the steps a feature (or user story, functionality, what you call your unit of progress) goes through from conception to the actual usage.

Mapping is not an experiment on a particular feature, but on the typical one: you should use average values for the duration of phases and wait times between them. We're looking for a system-level view instead of specific cases where something went wrong.
The time for drawing the map, if all the involved people are available, is described as not more than half an hour. The goals of the tool are:

• find out a mean value for the lead time, defined as the average time from conception to release.
• Find out which steps are adding value and which are only improving the product a little bit in relation to their duration.
• Find out where the major delays are: the wait times that last several weeks.

Examples

Here's an example of map for an academical CS project. It is composed of different phases, with synchronization with other people inserted between them.

Waiting time is commonly modelled between phases, so apparently I should break up more phases if there are waiting times inside them. The separation of value added time and waiting time is displayed in the vertical axis.

Here is an example from PHPUnit_Selenium, an open source project. The unit of measurement is a typical feature.

The first phase consists of defining a feature with a series of acceptance tests. The delay that follows take place when the feature is related to a github issue posted by someone else (or is a bug fix). You have to be sure that the problem has been nailed before diving into code.

The second phase is implementation: getting the acceptance tests to work by any means. There is then a medium delay, where other similar features to be implemented may display some commonalities and be refactored with the current one.

A third phase is larger-scale refactoring that didn't already arise from the implementation. For example, introducing the Command pattern *link* was one of these large refactorings.

Then, the major delay: before a new package is available a new release has to be created, after several weeks (on average I chose 2, to be conservative). I am insisting on frequent releases to limit this waiting time as much as possile: given the size of the features (small and medium), it's not a disruption to update the package often. I release even to the cost of some API issues, like having to change a method signature because it was made available too soon. No alpha or beta releases are created.

This step is also handled by Sebastian Bergmann, that has the rights to access PHPUnit's PEAR channel. There is a balance between pestering him with requests for the release of PHPUnit_Selenium 1.2.80 and maintaining the waiting time short enough that people do not have to checkout the source from Github.

Conclusions

Learning to value stream map is a step away from coding for me, and it highlights bottlenecks which are not necessarily noticed during the development phase. If you have any feedback to improve the process and the result of mapping, feel free to comment and add your experiences.