Paul Hammant's Blog: Value Stream Mapping

Value Stream Mapping (VSM) has emerged as a thing we should do before we tweak a software development production line. I was taught by Kevin Behr on a client mission five years ago. The exercise was in front of the business about their view of a value stream. That wasn’t software development, it was a pure business ‘service’ flow for their clients. All we’d be able to acquire before hosting the session (in a “war room” with full-wall whiteboards) was giant one-foot hexagonal multi-color stickies. And I’ve been using hexagons ever since for no super-strong reason. If the group is small enough I’ll use A3-sized paper. Well, multiple sheets (drafts) if rubbing out pencil lines isn’t working too well.

For Kevin’s session, attendees were pulled from their business activities during the working day and assembled to help draft a VSM from nothing. In fact it was a few groups in succession (one hour each), with an attempt to further refine the product of the previous group.

A typical s/w dev value stream

Value is added to the work as it flows rightwards. Everything has a touch-time and a wait-time. Touch-time is when work is actually happening. Wait-time is when “it” is not being worked on but it could be. The length of the touch vs wait timelines is made proportional as far as possible. Or a little, in my case here because of screen constraints that real whiteboard/wall setup don’t have.

Things flow backward when defects are identified. It is important to determine what percentage of items are defective in that way. Some super-broken companies have VSMs that don’t pull work backward when defects are identified (some car makers of the ’70s).

A group realization is that defective work gets yanked back to an earlier step, then flows through again once fixed - with impacts as to capacity.

Typical Session Challenges:

• Attendees need to suspend disbelief that this is a useful exercise
• Spirited debate about steps generally, defects, durations
• Repeat confusion on touch vs wait time (elapsed time vs expended effort time)
• Multi-tasking clouding everything - again conflating elapsed & expended
• Batching and unbatching making things complicated in some situations (perhaps s/w dev less so)

Common Recommendations

• Focus on where the biggest bottleneck is - one at a time if not a slam-dunk risk-free realization
• Try to solve your quality problems at the moment they happen by improving the way the work happens
• Align staff to a way of working through training, and add measurements to make sure that’s locked in.
• For us in software development at least, we should all be attempting “shift left”

Essential context before making recommendations

An understanding of the Theory of Constraints (ToC) is key. Clarke Ching has a great little book “The Bottleneck Rules” that you could buy a few of and hand out to somewhat defuse the risk of the attendee’s gut feeling that this isn’t a useful meeting. I’ve collected other people’s videos in a blog entry visualizing the theory of constraints that may help a little.

On bottlenecks - fix one and another pops up as a consequence. You may have a gut feeling as to where, but you should really wait and see.

Within ToC, “Just in time” ways of working need to be enforced. One that comes up a lot - stories are in fact seldom “ready for dev”. A similar one, stories were worked on too much before development and the captured info (in say Jira) is too much and possibly wrong. In itself that could be a BA waste as not all stories are chosen to be coded/delivered.

For us in s/w development we don’t need a pert chart to look at multiple dissimilar streams coming together in parallel to create a single product (like car manufacture), which is a relief. I mention pert charts because in a previous era they were used for “critical path analysis”, and that is were improvement effort could be focussed. With ToC and “critical chain analysis”, there was a realization that it could get more complicated. For me “critical path” was part of my early 80’s education. But even as I was being taught that in a business lecture, Eli Goldratt was pushing the science with “The Goal”. To close a circle, Kevin got to know Eli Goldratt in his retirement years and went on to write “The Phoenix Project” (with Gene Kim and George Spafford). Speaking of co-authors, Jeff Cox co-authored The Goal and I always liked his “Zapp! The Lightning Of Empowerment” book, too.

An understanding of cycle time improvement strategies, and within (but secondary) to that, an understanding of work in progress (WIP) limits. Our industry has historically been fixated on WIP limits.