Spot waste with value stream mapping

Value stream mapping is one of those activities that sounds like it has been designed by consultants to seem as complex and obtuse as possible, in order to warrant the consultants’ stellar fees.

True enough, when you look at a value stream map like this one from the Lean Enterprise Institute, you can see that they can produce quite complex diagrams:

I would argue that this isn’t really a map, but a diagram. But, anyway…

The aim of the map is to show how customer or user value flows through the various parts of an organisation from end-to-end, and therefore make it easier to spot waste and opportunities for improvement.

In the case of manufacturing, there are supply chains, factories, distribution and logistics, stock management and staffing concerns to include.

Software development is not that much different. To create value for users, software needs to go through planning, discovery, research, design, development, testing, release, monitoring and maintenance processes.

Unlike manufacturing, much of this work is done in people’s heads, or via conversations. It can be less concrete and predictable than physical manufacturing.

So we tend to accept waste rather too easily, believing it to be an inevitable part of a chaotic software development process.

In reality, much of this waste is repeated, unnecessary and completely avoidable.

Take a look at that map above again. Right at the bottom there is a timeline that looks like castle battlements. This is the lead time ladder.

Here’s an example lead time ladder for a software engineering team (from Lean Software Development: An Agile Toolkit by Mary and Tom Poppendieck):

As mentioned in yesterday’s email, a team is either working to add value or they’re not. The lead time ladder aims to show for a single unit of work how value-adding activities like development and testing are interspersed with wasteful activities like waiting, changing requirements, and seeking approval.

For front-end work, you’ll naturally focus on common sources of waste around discovery, design handovers, development and testing. But it helps to have a clear understanding of the whole picture, and it’s easy to forget the impact of maintenance work and outside interruptions. All of these should be represented in the map.

Once you can see the waste clearly, it becomes a lot easier to tackle it.

But it’s important that the whole team comes to this realisation together. We’ll look at how to run a value stream mapping exercise next time.

All the best,

– Jim