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.
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.
Thoughtworks acknowledges the Traditional Owners of the land where we work and live, and their continued connection to Country. We pay our respects to Elders past and present. Aboriginal and Torres Strait Islander peoples were the world's first scientists, technologists, engineers and mathematicians. We celebrate the stories, culture and traditions of Aboriginal and Torres Strait Islander Elders of all communities who also work and live on this land.
As a company, we invite Thoughtworkers to be actively engaged in advancing reconciliation and strengthen their solidarity with the First Peoples of Australia. Since 2019, we have been working with Reconciliation Australia to formalize our commitment and take meaningful action to advance reconciliation. We invite you to review our Reconciliation Action Plan.