How To Use Value Stream Mapping In Your Agile Retrospectives
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.
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.
The 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
- Any extra processing steps
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.
A complete self-study program where you will learn anything that you need to become a great Agile Retrospectives facilitatorSubscribe Me