11/9/18

Discovering Value Stream Mapping in Agile

I know very little about value stream mapping. It seemed like a way to quantify improvements in the biz process. Since this month's topic was Value Stream Mapping, I decided to attend AgilePDX's Virtual pub lunch to learn more.

The topic was described as:
Value Stream Mapping: this Toyota technique is often associated with lean manufacturing - and it can be a powerful tool applied to agile software development processes: Visualizing your workflow and inspecting it for "waste" to delivery more value fluently. But there are many questions: what is the definition of waste (or value)? When is this technique best applied? Join us to talk about your experience mapping value, and hear how others have worked with this process to what effect.
Here are my questions with some answers gleaned during the lunch.

Q: Can I get an explanation of "Why use value mapping?" that isn't a circular definition? (ie: doesn't use the word "value" or "waste").  What's a practical example?

A: It's good for seeing the flow of business.
  For example, if you or your team don't deliver then who's affected by this?
  It helps you fully understand who _your_ customer is in the development process.
  eg: If you're creating an accounting invoice... how to know who will use this?
  It can also expose risk: Finding where the "magic occurs" part of the process is a good way to expose risky areas.


Case study: A company wanted to create an invoice.
Normally it took them 3 weeks to generate an invoice.
Neal used value stream mapping to look at the information flow.
There was a lot of double entry, incorrect information.
They realized they needed to incorporate their CRM system into the accounting system.
This helped reduce double entry work and increased accuracy.
They also reduced their invoice time from 3 weeks to 1 week.

Q: Is this only for large companies?
A: Good for small to medium groups as well.  It's a way for employees to see how they add value.
  It's also good to expose "mysteries" in the value chain.

Q: Is value mapping more of an art or a science?
A:  Some art to it. It's not a black & white answer...
 The more experience with it the more it's a science.
 You can use PDCA to quantify the results -- while testing the changes.
 In the beginning, you might not know the costs of development time and cycle times.
 Once you start learning that, you can start doing metric-based learning experiments.


A: Resource to results ratio = key metric.
 If you can't identify resource to results ratio then you'll need to implement that.
 An example of a resource to results ratio is a baseball player's ERA. It shows the value of an individual's contribution to the team.  (Can also show the value of a team to a company).

Q: What if you don't know how to quantify the value?
A: If it's difficult to see the value stream, then maybe your process needs to be re-evaluated
  Don't worry about trying to hard to quantify the value. This method is also good for exposing problems... showing what don't you know, what is a mess.

Q: What are some stumbling blocks?
A: It's hard to get people to agree on the value of using value stream mapping.
Try it out and see how it's useful.
One person mentioned a decision that could save 3 cents on the product, but will cost 50 cents on support. The big picture of the map showed how the upstream decision caused problems & costs downstream.

A: Putting a dollar amount to processes was a stumbling block.
Steven found that this was irrelevant. Mapping the process helped identify where things were taking too long -- and this was easily translated to "time is money."


A: Are you providing value to the downstream, or are you causing increased costs?
Look at the PDCA cycle (Plan Do Check Act) and test it out.
Is your value added?   If not, then roll it back.
For example, the value chain can show you the cost of your hand offs.

Q: What about using value stream mapping to assess the value of software testing?
A: This is simpler if you have historical data (already released software with defects).
Measure the cost of escaped defects (support, code fixes, customer satisfaction, brand reputation)
Then you can use this to support value of testing.
Alternatively, you can use Net Promoter score to measure this.

Q: Can you recommend any good introductory books?



Related links: