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 for free on 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 chains, service-related industries, healthcare, software development, product development, and administrative and office processes.
Value stream mapping is a lean manufacturing technique used to analyze 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 visualize 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 at how many issues we found, how many dependencies and blockers we had, and so on. Having this information available, 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 time only the right agile teams will understand how important is to reduce the QA tail by introducing TDD, ATDD, and Unit Testing or how important is it to have documentation/localization 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 iterations and suitable for analyzing 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 the business world, customer value is an amount of benefit that a customer will get from a service or product of 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 a waste too. With this statement, I am expecting to get a lot of reactions :D
The team needs to do this activity every day to track all the 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.
As I said I tried this activity several times and it's amazing how much information the 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.
In Summary
An Agile Retrospective is an event that ́s held at the end of each iteration in Agile Development and it serves for the team to reflect on how to become more effective, so they can tune and adjusts its behavior accordingly.
I believe the SailBoat exercise is quite a simple Agile Retrospective Exercise and does not require any special occasion.
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.
