Why are we mapping that value stream?
As far as I can tell, the original problem that Toyota was addressing with "value stream mapping" (VSM) was to understand material and information flow in order to improve production lead-time.
"Material flow" refers to the flow of work or value, for example, the car as it's being assembled. "Information flow" refers to the signals that indicate when and what to work on, for example, a request to paint 10 red car doors. A value stream map is thus not just the steps that are taken but also the mechanisms by which people and systems decide what to do next. Queues, decision and prioritization logic, etc. are all relevant.
The key point here is that mapping is not done for its own sake. There should be a goal - improve lead-time, cost, quality to the customer, or to make the work better for the people involved.
How does it apply to IT?
Software delivery has the "advantage" where a lot of non-technical people still pretty much treat it as if it was magic. And this is from the perspective of both overestimating and underestimating the complexity of what is being done. Mapping is useful to get your head around what is happening as well as undermine the general belief in magic.
VSM in pictures
_____________________________________________________________________________
_____________________________________________________________________________
When I think about value stream mapping as applied to the software delivery context, a few key points come to mind:
- Understand what you are trying to do before worrying too much about what you're going to map and measure. In terms of goals, I'd suggest something under the categories of improving lead-time, cost, quality to the customer, and making the work better for the people doing it.
- Pay attention to your queues and decision logic, not just the process steps. It is negligent to treat software delivery as a black box, and a magic black box at that.
- Think more about seeing problems to support improvement than seeing status to support coordination. What can't we see that is hiding potential problems? For instance, we're almost always leaving footprints in the systems we're using to develop and deploy. Making these footprints more visible and accessible can create a lot of opportunity for ongoing improvement.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.