Agile Retrospectives: “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. In this post I already explained the full exercise but now I want to create it with a more structured approach. This exercise can be found in the book: “Getting Value out of Agile Retrospectives”, a book written by me and Ben Linders 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 within your colleagues.

Here you can find my previous blog “Getting Value out of Agile Retrospectives: “Star Fish””

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 effective with mature teams. Value Stream Mapping will reveal how the team and system interact. For this kind of exposure, the team must be mature. 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 true agile teams will understand how important is to reduce QA tail introducing TDD, ATDD, Unit Testing or how important is it to have documentation/localization done within the sprint. In order to get more ideas how to bring localization inside of the spring please take a look into this post. 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 activity to be run during all iteration and suitable for analysing the results within the retrospective.

The easiest way to do this is to grab some flip-chart papers and tape them on the wall. Then divide the space in 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 customer. All other tasks 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 relative to 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 extremely 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 :D

The team needs to do this activity everyday in order 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 as the picture seen above. Like I said I tried this activity several times and its 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 for your team? Leave me some feedback in order to make improvements.

On my next blog post I explain how to use the “Team Assessment Survey” exercise to run a retrospective.

In case you are interested in Agile Retrospectives I am at the moment preparing an AGILE RETROSPECTIVES PROGRAM. This is a complete self-study program where you will learn anything that you need to become a great Agile Retrospectives facilitator.