This document discusses value stream mapping and provides resources on the topic. Value stream mapping is a lean manufacturing tool used to analyze the flow of materials and information needed to bring a product to a consumer. The document includes images related to mapping journeys and overcoming bottlenecks. References for further information on value stream mapping are also provided.
Mastering MySQL Database Architecture: Deep Dive into MySQL Shell and MySQL R...
DOES SFO 2016 - Alexa Alley - Value Stream Mapping
1. VALUE STREAM
MAPPING
ALEXA ALLEY - @ALEXAALLEY
PROGRAM MANAGER - HEARST BUSINESS MEDIA
http://www.timvandevall.com/wp-content/uploads/printable-treasure-map-for-kids-1.jpg
I could stand up here for the next 25 minutes and teach you how we do a VSM workshop, but I won’t be doing that. There are books, videos and artifacts that can teach you step-by-step how to host and facilitate a VSM; but one thing we have learned from doing these with 5 different businesses and multiple teams, is that you have to be flexible and iterate each workshop to fit the need of the individuals. There is no handbook that will tell you exactly how to complete a workshop in 100% of the situations you face. No two teams are alike and while each challenge has similarities, the way teams interact and their end result requirements are likely differing. The key to any successful VSM is aligning on a common goal and focusing on the journey to getting there and worrying less about what the end result looks like. During this time together, I will talk through the benefits we’ve seen within HBM of doing a VSM, how it can help drive a DevOps Culture, and how those changes have a positive impact across the whole organization. I’ll also go through some tactical examples of workshops that we’ve conducted in the past. A high-functioning DevOps team is much like a crew on a ship. You must trust each other to do quality work to keep the ship running smoothly. Just like the sails can’t be raised before the anchor, dev teams can’t work on a product without clear requirements. Now… Let’s go on a journey
What is the goal and purpose of hosting a VSM workshop?
Increase Visibility
Highlight and strengthen the DevOps Culture you are working to achieve
Build a stronger more collaborative internal community across all job functions
You want to build a community that allows visibility of work across the entire business, trust among the teams as well as from leadership, does not reprimand for failures, and encourages innovation and forward progress
Identify barriers to flow (bottlenecks) and reduce friction points
Identify communication patterns (business creates products and software that are reflective of their environments and teams)
Showcasing tool interdependencies
Understand where work is sitting for approvals or gates and where there are significant hold-ups for rework and inefficient processes
These bottlenecks help to build the Transformation Plan
One of the most difficult things we face before hosting a workshop is getting buy-in and interest from all parties, from leadership all the way to individual members on a team
Show them value in a way they can understand
Leadership: Tangible
Individual Contributor: Intrinsic
Find your Champion. The captain of a ship needs to be trusted and respected by the crew, just like the person leading the change for the business. Leadership and teams need to support this person.
Internal champion
This person doesn’t have to be a manager or an engineer; just someone who sees the need and value for speeding up and transforming the workflow for the business and has demonstrated their ability to innovate and improve their own processes or their teams
VSM Facilitator
A fresh set of eyes, outside of the Value Stream (if possible)
Objective member who has no stake or opinion in the numbers or outcomes but will push your team to strive for the Right changes for the business
Also someone who is comfortable enough to let the team know when the discussion and conversation is getting off-topic and pull everyone back to the objective
The VSM starts before the actual first day -- Do not expect to go into a room with everyone and have them understand why they are there.
When determining who should be present, think of people who have a stake in the Value Stream and have authority to make necessary change. These members should be able to speak to the Process and time required to do the work. If mgmt cannot accurately provide this, a representative who can, should be there
Mentally prepare the team by pulling together key stakeholders for short AMA. This gives everyone the opportunity to discuss concerns, questions and opinions on defining success. From the perspective of the facilitator, this gives you the chance to start looking at how the teams communicate
In our experience, the AMA is what really gets the C-level and upper mgmt teams bought in to the idea and can support the process and change (monetarily and transformationally)
Once the team is informed, we build the charter -- The charter sets a clear scope, lists all members of the team who need to be present, addresses the main concern and specific Value Stream we will be mapping, as well as desired deadline to complete a transformation (typically 6 months to a year)
All members who will be at the workshop need to be aligned and in agreement on the scope and specific Value Stream you are mapping
The facilitator needs to set expectations for each day as well as after the workshop (Artifacts, Quarterly Sync-Ups & Transformation Plan)
Each member in the workshop needs to be an active participant.
We set a loose agenda to guide the workshop; the real value comes through organic conversation and collaboration
It is important to remain flexible through the whole process and make this valuable to the team participating
Realistic expectations. One workshop will not change a habit that’s been built for the last 10 years. It’s iterative and needs to be revisited regularly to make revisions and keep the business up-to-date on the initiatives and progress
Most importantly: This is Blameless. No finger pointing or blaming another person/role for long delays or holding up the VS. All participants are Equal
We start day one by reiterating the prep work, scope and expectations. Details on Map
We have created a presentation to teach the attendees about VSM’s, some of the terms we will use frequently (PT, LT, what a process card is and the info that should be on it, information flows, etc)
This presentation is kept up for the entirety of the workshop and follow along with the process for reference points
This should be very high level; focusing on process blocks, not maps
On this day we only focus on WHAT. Not WHY or HOW. (this is day 2) While we are concerned about the “what” you should still allow flexibility for open communication, be sure that communication is adding to the process and has value to the topic at hand without straying too far into the weeds
Spend a lot of time mapping out this day. This is the base of defining your future. We want to find where there are friction points, holding patterns for work to transfer between teams. This is where teams see how they fit in
We put LT in days INCLUDING weekends since these are still days that the customer does not have a product or feature. (We remove weekends when determining efficiency ratings since you are not expected to be working all weekend.) PT is in hours since this is typically a much shorter duration of time. %C&A is tricky to grasp since this is the time that the downstream work center is able to begin working right away without needing explanation from the upstream work center
Once everyone agrees, we start building the future state in the same conceptual format of (process cards, information flows, etc.) but without constraints
The future state is your ideal world. If you could build your perfect value stream, what would it look like?
In the future state, the tool doesn’t matter. If you want to automate something and you don’t currently have a tool for it, that’s where the transformation plan comes in. This is where you really focus on DevOps transformation and automating where you can and building collaborative cross-functional teams
The JDI’s, Kaizen and Project cards build out the transformation plan. Before bringing up the map, unbiasedly rate the cards from 1-10 in both Value and difficulty
The easiest to do with most value will be in priority, High value with more difficulty will be scheduled to complete by the goal you have outlined, or put into a backlog based on budget or team constraints, etc
This work is and the timeline for completion is done by the Mapping team and executive leadership, not the facilitator.
How you measure success can be very unique. That should be defined by leadership and the transformation teams when building out the planning deadline and goals. Will you measure success in number of deployments, customer feedback, number of defects, etc. However you decide to do it, it should be reflected in an obvious way that shows value.
Just like the seas won’t always be smooth, we see challenges in every VSM. These can be overcome by doing some prep work and having a skilled facilitator.
Disagreement on averages and/or the sample set. We use the 80/20 rule. 80% of the time what is the most accurate time spent on one process card? We’re focusing on estimations, not exact numbers. You don’t need to get perfection
Defensive posturing around the numbers. People tend to not want a negative number associated with their process (shocking, right?!) But it’s important to reiterate these are just the numbers and is not a reflection on the team/individual. Remember… We are blameless
Often people will come into the workshop with a personal agenda. This is why it is so important to align on scope at the start of the workshop
We see silent objectors as well. These are the people who feel they have nothing to add, or only contribute when shooting others down. (Introverts/snipers). We value all opinions and input as long as it is adding value to the conversation
A VSM drives DevOps in any size organization
*iterate as the business changes
*collaborate with members in the business outside of your team (across different verticals)
*automate where you can
Increase performance across the entire system rather than a specific department
Feedback loops/communication
Build a culture that allows for experimentation and continual iteration and learning
Anyone can build this competency in their organization