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?

• Value Proposition Design by Alex Osterwalder
• Value Stream Mapping by Karen Martin and Mike Osterling.
• The New Lean Toolbox by John Bicheno
• Learning to See: Value Stream Mapping to Add Value and Eliminate MUDA by Mike Rother and John Shook

Related links:

• When Is Value Stream Mapping The Right Tool For Software Development? by Adam Light 
• iSixSigma description of Value Stream Mapping
• SAFe and Value Streams  - "A value stream is a long-lived series of steps used to deliver value, from concept or customer order to delivery of a tangible result for the customer."

Testing, Agile and Devops: How does it all jive?

Devops is slightly nebulous phrase because it's a mix of technologies, methods and roles.  In short, it means that operations works tightly with development during the development cycle and beyond.  Think of it as “shifting right” in the same way that many people talk about shifting quality left in the development process.

Some of the technologies are 

• Containers, like Docker or Kubernetes 
• Automation frameworks like Jenkins and Travis CI, 
• Continuous integration models (again, Travis CI).

While there are many parts to Devops methods, the most interesting are:

•  Using automated regression tests for both staging and live environments, often staging the tests within a container. This helps shift QA to the right while reducing risks.

• With containers you can treat configuration like code -- storing the configuration as scripts in a revision control system.  So, the container configuration can be static and tracked.  This enhances security as well as making the configuration more transparent.

• Netflix’s idea of a Chaos monkey - introducing problems into production systems to test their resilience.

The Devops role, is someone who specializes in these technologies. Also essential is someone who can work with the team and help interface with QA, security, development, operations.  The ultimate idea of Devops is embedding someone representing operations in the development team.

So, how does it all come together?  Agile methods mean that you have potentially deployable code at the end of a sprint. With Devops that can become actually deployable. But, devops also helps make deploying to production less scary:

• The deployment is automated.

• SDETs have written automated regression tests to check the existing system.

• Containers allow you to run multiple test deploys in parallel, testing multiple configurations.

• Security configuration can be built in to the container scripts.

Since automated tests, deployment and configuration are all code, they can be revised, tested and run automatically often.  This allows QA to focus during a sprint on the new functions, including end-to-end and user experience.

Product Camp Portland 2018

Over the weekend I had the opportunity to attend Product Camp Portland.  My motivation was that usually I'm on the technical side of projects. Product Camp was a chance for me to explore and hear how people who work with the customer-side of development solve problems and explore possibilities.

Product Camp is an Open Space conference, or un-conference, similar to Agile Open Northwest. This means that attendees pitch potential sessions and everyone votes on the topics they want to attend.

The pitch process took about half an hour and it was interesting how interactive even that process was. Teresa Torres was the first woman in the line-up. She remarked how the gender ratio was biased 5:1 towards men. From her encouragement, more women proposed sessions and the end result for the conference was closer to 50/50. It was an immediate and inspiring outcome.

There were slots for 16 sessions in all. I was only able to attend four, but I took sketchnotes of the sessions I attended. It's a fun way for me to quickly internalize the topics and I like to share with attendees on twitter.  It's also a good way to meet people.
Here are my notes.

Arya from Cambia told her story how she became a product owner, and then discussed the key points for creating a compelling story that engages customers and colleagues.

Dave Flotree covered the key points of how to gather user-validated design data through interviews. He also discussed how to use Affinity Diagrams to create a holistic picture of your users' needs.

Teresa Torres gave her definition of continuous product discovery and then discussed the problems and questions people had about the process. 

Paul W. Save and Dr. Quentin Caudron from CBRE had traveled all the way from Vancouver, Canada to talk about how product managers can integrate machine learning into their systems.  I really appreciated their talk, and also how enthusiastic they were about my sketchnotes.

Overall, Product Camp Portland was conference which managed to stay cozy despite having over 350 attendees. I look forward to attending again.

FYI, here's Mike Rohde's "The Sketchnote Handbook" which has a lot of good ideas and inspiration about using drawing to capture the ideas during meetings and conferences.