Luis Goncalves

How To Use Value Stream Mapping In Your Agile Retrospectives

by Luís Gonçalves
value stream mapping

Value Stream Mapping

Hi guys, in this post I will explain how can you use Value Stream Mapping as a tool for a retrospective.

This exercise can be found in the book: “Getting Value out of Agile Retrospectives”, a book written by Ben Linders and me with the foreword from Esther Derby. The book can be downloaded by free in LeanPub.com or InfoQ.com, please download it and spread it to your colleagues.

If you are interested in getting some extra Agile Retrospectives exercises, I created a blog post with dozens of Agile Retrospectives Ideas, check them and see if you find something interesting.

What can you expect to get out of this technique

Although value stream mapping is often associated with manufacturing, it is also used in logistics and supply chain, service-related industries, healthcare, software development, product development, and administrative and office processes.

Value stream mapping is a lean manufacturing technique used to analyse and design the flow of materials and information required to bring a product or service to a consumer. At Toyota, where the technique originated, it is known as “material and information flow mapping”.

It can be applied to nearly any value chain. As an outcome of using Value Stream Mapping, you can visualise how your development process is working allowing your team to identify several possible parts of the software development process that can be improved.

I guarantee you that you will have plenty of data for your retrospective at the end of the iteration. I tried this couple of times, and I was surprised how many issues we found out, how many dependencies and blockers we had and so on. Having this information available, it will help a team to decide how and where they can improve.

When would you use this technique

Value Stream Mapping will be more useful with mature teams. Value Stream Mapping will reveal how the team and system interact. For this kind of exposure, the team must be knowledgeable. I believe, if team members are new to agile, they will not understand most of the things this exercise will reveal.

For example, from my experience one of the most common things this exercise reveals is the QA/Loc/documentation tail for each story. If the team is not mature enough they will not see this as a problem.

I believe most of the times only right agile teams will understand how important is to reduce QA tail introducing TDD, ATDD, Unit Testing or how important is it to have documentation/localisation done within the sprint.

Value Stream Mapping technique will reveal some complex problems that only mature teams are ready to deal with.

How to do it

Value Stream Mapping is not an activity to perform during the retrospective. Instead, this is an event to be run during all iteration and suitable for analysing the results within the retrospective.

IMG_20130217_190326The easiest way to do this is to grab some flip-chart papers and tape them on the wall. Then divide the space into equal intervals, each interval represents a day of the iteration. Draw a line on the Y axis; this line should be on the position Y=0.

You should have a flip-chart for each different story of the iteration. If your team is not co-located there is no problem, just create an excel for the same effect.

During development, the team should be concentrated on one story at a time. If they are doing any activity that will bring value to a customer, each member draws a line on top of the Y axis line. If they are waiting, blocked or doing some activity that does not bring value to the customer, draw a line under the Y axis line.

If you are new to this exercise, as a rule of thumb, you can think that all tasks that are needed to accomplish a story, bring value to the customer. All other duties bring a waste. As it is used in a business world, customer value is an amount of benefit that a customer will get from a service or product about its cost. Waste as Poppendiecks describes in their book “Lean Software Development” is:

  • Anything that does not create value for a customer
  • A Part that is sitting around waiting to be used
  • Making something that is not immediately needed
  • Motion
  • Transportation
  • Waiting
  • Any extra processing steps
  • Defects

If a team is incredibly mature, you can start thinking that all QA activities that are performed as validation instead of part of development or bug fix, should be considered a waste. As an example, Unit Testing, TDD, ATDD and some other techniques can be considered QA activities as a part of development.

If we do a testing at the end just to validate that everything is fine, then you can think this is a waste. Bug fixing can be considered as a waste too. With this statement, I am expecting to get lot of reactions 😀

The team needs to do this activity every day to track all different activities inside the team. Do not forget to write notes when people are blocked or in IDLE; these notes are important to be discussed in the retrospective. The possible result can be something like the picture seen above.

Like I said I tried this activity several times and it’s amazing how much information team gets out of this exercise. For me, this is one of the exercises from my toolbox that I more appreciate.

What do you think about Value Stream Mapping as an exercise for your next retrospective? Do you think it could be useful for your and your team? Leave me some feedback to make improvements.

AGILE RETROSPECTIVES PROGRAM

A complete self-study program where you will learn anything that you need to become a great Agile Retrospectives facilitator

Subscribe Me
Rate this post:
Luís Gonçalves

About Luís Gonçalves

http://luis-goncalves.com/

Luis is not simply a consultant, he helps people and businesses grow. He expects to deliver 10 times more value than what you’d actually pay for. As an Agile retrospective expert, customer happiness and client success are his biggest drivers!

Comments

Share your point of view

  1. Good post Luis. I’ve used this exercise at the beginning of coaching engaging to help clients figure out where they need to concentrate their time.

  2. As I perhaps said before, I rather do VSM in the prespective (before doing the work) than in the retrospective. If we do it in the prespective, we can see what is going to block us, what we will do wrong, what will not bring value, where we will have to wait, etc, so that we can prevent these things happening. During the sprint, we don’t record it on a flip chart (=waste), we do something about it before it creates waste. If in retrospective we find that we caused/created/suffered waste, the waste is already produced, the time already evaporated.
    VSM is meant to prevent waste. In repeatable processes, like production, we can use it to measure the waste in order to learn to prevent it. In development, we have both repeatable processes and things we haven’t done yet. By imagining doing it and doing VSM on the imagination, we can learn to prevent it before it happens.
    So, better use it as a tool for the prespective rather than for the retrospective.

  3. Thanks for the post Luis. I’m not a developer but I can see a more general application of this when it comes to my working day, basically monitor at the end of each hour whether the previous hour was productive or waste … I seem to spend far too much time on things that I shouldn’t be wasting time on!