Value Stream Mapping is a technique that is already used in the context of Lean Manufacturing. At OT2004 I attended the workshop “Understanding the Software Value Stream” by David Harvey and Peter Marks.
Borrowing metaphors from other domains, and applying them to the creation of software can be, from my experience, a dangerous thing. Even adding the word ‘development’ after ‘software’ is dangerous, since that also implies a metaphor. I consider borrowing from manufacturing especially dangerous – I consider software ‘development’ to be a creative activity best carried out inside a ‘living company’ not a kind of machine.
Value Stream Mapping seems worth exploring though, so the main question that remained in my head after the workshop was: how can we map Value Stream Mapping to software ‘development’, without implicitly taking over the ‘production metaphor’.
As described on http://www.mamtc.com/lean/building_vsm.asp:
Value Stream Mapping is a method of visually mapping a product’s production path (materials and information) from “door to door”. VSM can serve as a starting point to help management, engineers, production associates, schedulers, suppliers, and customers recognize waste and identify its causes. The process includes physically mapping your “current state” while also focusing on where you want to be, or your “future state” blueprint, which can serve as the foundation for other Lean improvement strategies. Interesting results that could be achieved with the above are:
- Enabling all stakeholders in the process to see the whole picture. In my experience people usually only see their own part of the process. Optimizing one part without considering other parts might cause the whole process to deliver less value instead of more.
- Both materials and information is taken into account. In software development we work with information only, but since information is supported by VSM, this could be sufficient.
- Focusing on ‘what is’ and ‘what could be’. Reflecting on process is a useful, and often difficult activity since assumptions have to be made explicit. Imagining what could be without taking the current situation into account, however, is much more difficult. There are other techniques (such as Diagrams Of Effects) that are useful, VSM could be a useful addition, since it takes information flows (rather than actions) into account.
Continuing the quote:
… A value stream is all the actions (both value added and non-value added) currently required to bring a product through the main flows essential to every product:
- the production flow from raw material into the arms of the customer
- the design flow from concept to launch
The idea of adding ‘non value added’ steps to a value stream is to identify steps that are wasteful and can be eliminated. Adding everything makes brainstorming about the process easier, because different stakeholders might find different activities valuable. Separating production and design flows is not something that is generally applicable to software.
For instance, in my daily practice of software development, there is no visible distinction between design flow and production flow, because each step in a process based on Extreme Programming encompasses both production and design. One of the things that came up after analyzing the value stream we created at OT, was that not only is value produced at multiple steps in the process, also very early on in the process value can be realized. Ordinarily, for a production line, I would think value is created at the end of the production process, when a product is handed to a customer and (possibly) money is exchanged.
In a process with short iterations, typical of agile software development, value is also created during planning meetings with the customers. For instance, customers get to re-think their business process while brainstorming their next wishes for software (and, as a consequence, perhaps changing the value ). At the next xp-nl meeting (http://www.xp-nl.org/Wiki/XpBijeenkomst4.5 ) we’re probably going to explore Value Stream Mapping further.
.
