On the first episode of our “Hacking the Org” podcast, VP Engineering and Chief Architect at eBay Randy Shoup talked about how he used Value Stream Mapping to understand the bottlenecks in eBay’s development process. It is also a technique we use regularly on client engagements. But WTF is Value Stream Mapping? Let’s strip it back to its most basic form: Value Stream Mapping is a method to attain visibility of your organisation’s feature delivery process. Or, more accurately, a version of it. Essentially, we’re trying to discover what steps are involved in getting from Point A to Point B? Who’s involved in each step? How long does each step take? What’s involved in moving from Step 1, to Step 2 and so on?
Let’s establish first what I’m talking about when I say “Point A” and “Point B”.
Point B is a fairly easy one, so let’s start there: at the end. Point B should really be the moment at which “value is delivered to the end user”—the moment whatever feature you’re deploying arrives in production and is available for the user to, well, use. This is certainly the traditional end point, but it does have a certain whiff of waterfall about it, assuming as it does that whatever ends up in front of your user works perfectly and is perfectly aligned with that user’s requirements at the first attempt. It’s wise therefore to extend your Point B slightly beyond this and include whatever processes your organisation has for verification, validation and decisions around iteration so you can examine that as well.
Point A is more open to interpretation, but it should be as early as possible in your development process. Generation of a user story for the development team would seem like a good starting point, but it’s really too late in the process. How did the Product Manager get the information she needed to write the user story? How does your organisation gather data from its users? Is the marketing team involved? Customer Success? Sales? All these people are important factors in your value stream and understanding the way information flows between them (or doesn’t!) is critical. Starting at the point of “getting user feedback” is usually a good rule of thumb.
The amount of work you’re going to be able to do on your Value Stream Map will depend on who it is that’s completing it, but always over reach in this regard. If you’re feeling confident that they’ll only be able to complete the middle 60% or last 40% (for example) of the Value Stream Map, still include the steps outside the team's direct “sphere of influence” and see what they come up with. This is usually even more interesting than the parts they’re confident about.
Once the start and end points have been decided, we can begin the process of filling in the gap between them.
We’re looking to discover a few basic things here: work time (or touch time), wait time, teams or individuals involved. By finding those things we can also see what the handover points are and who’s involved with them.
The questions are simple:
- What is the first Step after Point A?
- Is this something that the team completing the Value Stream Map (VSM) works on, or waits for?
- How long does the work typically take?; or How long do they usually wait?
- Which teams are involved in work or the wait?
- What is the handover process in each direction?
Work time and wait time are essentially the same thing, viewed from a different perspective. From the perspective of a development team, approval or deployment might be viewed as wait time; for a marketing team everything between user story to go live might be viewed as wait time, with the entire development process essentially a black box to which they have no access whatsoever.
Once all the steps have been filled in with as much detail as possible, we’ve added some additional classifications to the typical VSM template that we use to make an assessment on the reasons behind any longer-than-expected touch or wait (or work) times.
We use the pain point classifications of Capability, Motivation and Opportunity, and three areas of possible failure: Preparation, Process, People:
- Capability: they don’t know how to do the thing they’re being asked to do.
- Motivation: the benefits don’t outweigh the pains. They have no intrinsic or extrinsic motivation to act.
- Opportunity: the social or physical context didn’t allow this action to happen.
- Preparation: we didn’t correctly prepare what we had done for the wait time, or we didn’t find out enough about what the team we were handing over to needed from us.
- Process: there is an intrinsic problem with our process that created the longer-than-expected wait time.
- People: all other things were in place, someone just didn’t do what they were supposed to do and needed to be chased.
We’ll also typically assign a percentage to each of those as a guess of what the weighting of those contributing factors might be.
Once that’s all been completed, we are left with a story about how your organisation goes from user feedback to feature delivery, which is great and is always fascinating, but it should not be treated as a statement of fact. As the VSM stands at this point all we really have is the perspective of one group of people, which is not a solid enough foundation to use for decision making of any kind.
Ideally we’d now repeat the exercise with all the people or teams that have been identified on the first VSM and see where the maps diverge and converge, and start exploring the reasons for those differentiating perspectives. If that isn’t practical, you need to at the very least test the assumptions that have been made by speaking to the other teams or individuals who’ve been mentioned on the map you’ve created.
To make this a bit more concrete this is an idealised, “Instagram” view of a map (click on image to expand):
And this is an example of a map from a real client engagement but with the sensitive parts removed (click on image to expand):
A real-world example
During a current state Value Stream Map we were putting together for a client recently, one of the team members casually wrote a wait time of “two to five weeks” for one particular deployment approval process. The alarm bells rang so loudly in our consultants’ heads I could practically hear them. Immediately we pointed out that this approval process shouldn’t take anything like as long as that, so we looked into it and discovered a dual failure. Firstly, the thing that the team had to wait so long for was being done manually, and it was a hugely tedious process that could be automated very easily. Secondly, the process was only being taken care of by one person so when they went on holiday nothing would happen until they were back and dealing with an enormous backlog of work (hence the two-to-five week timeframe). We were able to reduce toil and time to delivery in one fell swoop with very little effort.
And this point, really, is the most important thing about the way that we use Value Stream Mapping: we never treat it as a “source of the truth”. Instead, we use it as a way to build up a bank of assumptions a team (or teams) has of itself and the environment in which it operates that can be explored, challenged or validated by speaking to more people in the business. It is a starting point, and only really shows its value (pardon the pun) when you’ve spent time interrogating the findings and challenging the assumptions made during its creation as we did in the example above.
It’s a piece of the puzzle, not the whole picture.
Previous article
