Value Stream Mapping for earlier confidence

Value Stream Mapping (VSM) is a useful tool to understand different activities in software delivery and identify bottlenecks.

One of the best parts of this exercise is that everyone tends to understand this visualization, so that there’s a common understanding of the software delivery flow.

Over the past years, I’ve used a variation on the value stream map. By adding ‘confidence’ to the equation, both to get a common understanding of what is happening, as well as to visualize changes in delivery strategies.

Step 1: visualize the delivery steps

With the team, draw out the different ‘stages’ where the changes are. This can be the code on a particular branch, or the deployment environment of an artifact.

Together with this, mark which ‘gates’ are in place – what type of tests or checks run, and whether they’re fully automated or manual.

Step 2: add measurements and ‘confidence’.

On every step, decide with the team how long it typically. For starters, the team can agree on the duration, but when driven with data, better decisions can be made.

Besides duration, the team also looks for the non-happy flow, e.g. bugs discovered, build failures etc. These two measures are zoomed in versions of the DORA metrics ‘lead time’ and ‘change failure rate’.

What is harder to measure is ‘confidence’. But it’s a useful exercise to map this as well. Tests that never fail for the right reasons tend to give a low confidence, while a review that leads to useful feedback, might give a huge boost.

With the team, decide on each step the amount of confidence it gives. E.g. the unit tests might add low confidence, where a long-running ‘regression suite’ might give a huge boost.

Step 3: shift-left confidence

The outcome of the previous exercises is used to spark the discussion to answer questions:

• “What is necessary to get to the confidence we get, earlier?”
  e.g. what does the ‘regression suite’ cover, that the unit tests can’t?
• “Is every step even useful?”
• “What ‘optional’ steps should we make an automated quality gate?”
  for example, checks that some people have in their IDE, could also be run as part of the pipeline?

Try to identify at least a few small improvements or automations, draw these into a new version of the visualization. The first step is to improve confidence earlier, so that other steps may become less relevant and the process can be simplified.

The delivery pipeline can be seen as a funnel, where typically more changes come in, than deployments to production go out. The higher this ration, the longer the delay in the software delivery, and the larger the size of work being deployed – which adds risk to the go-live of every change.

The goal here, is to get confidence earlier and more efficiently, so that ultimately more changes that can be deployed to production.

Conclusion

Adding confidence to value stream mapping is a useful tool for understanding and improving (over-)complicated delivery. Getting confidence early in the process is necessary to eliminate wasteful steps and deliver continuously.

Important to mention, this approach assumes all your team’s changes are valuable, it puts pressure on the internal delivery process, but might not challenge your product strategy (i.e. what is truly valuable to your customers).

Questions? Please reach out to us

This blog is part of our series "Holistic Horizons". Check out the previous entry – "The Cost Paradox of the Cloud" by Albert Starreveld. Or read further to the next article – "I’m thinking about developer productivity" by Jochum Börger.