Archive for May, 2004

Value Stream Mapping Explored

Thursday, May 20th, 2004

at the most recent xp-nl (the dutch Extreme Programming Users’s group) I facilitated session on value stream mapping. This was an interesting case of team learning – if everyone brings a piece of the puzzle it is possible to get a complete picture!

None of the participants, including myself, had much prior experience with Value Stream Mapping. Everyone involved was just very keen to learn.

After a 5 minutes introduction of the technique, we just starting by doing, working on a value stream from one of the participants. Everyone chipped in, and as we went along we developed our ‘diagramming technique’. Since our new office didn’t even have a flipchart yet, we settled on using index cards to create our map.

value stream map with index cards

As we went along, we clarified the meaning of the stations and queues, discussed about using average times, probability distrubutions or numbers from just one project.

At the end all of us understood much more about value stream mapping (you can read our findings in Dutch.

You can talk to me, and You can solve all your problems

Wednesday, May 12th, 2004

I often get stuck in my work, and then I need someone to ask a question to – I’m not afraid to ask for help if I need it ;-) .

It often happens to me, especially when sending an e-mail with a question, that I come up with the answer right after having asked the question. If that happens to you, you don’t really need a person to ask the question to, you could do just as well ask a teddy bear for help. Often the answer becomes clear when you have articulated the question properly.

Recently, my colleague Thijs Janssen presented Erik and me with a teddybear. a teddy bear wearing a t-shirt with the cq2 logo and the words 'talk to me and _you_ can solve your problems'

Erik and I often thank Thijs for helping us solve our problem, while actually, we solved it ourselves right after asking him a question…

Applying Value Stream Mapping to software

Wednesday, May 12th, 2004

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

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 ( ) we’re probably going to explore Value Stream Mapping further.