Going from a Value Stream Map to Value Stream Optimisation

Read this blog if you already have a Value Stream Map (VSM) and you are wondering how to reap its benefits using a structured process. If you need to know why and how you should make a VSM, please read the article ‘How to create a Value Stream Map’ written by my colleague Michiel Sens. Don’t forget to return here.

1. Read your VSM

So, how does a VSM look like? Depending on the linearity of a process people either display the process based on activities per role or by a flow of process steps.
Fig 1a. Process steps as a flow

Fig 1b. Activities per role


Even better is to combine the two approaches to get an idea of work per role as well as the overall process flow.

Fig 2. VSM with combined roles and process flow

 
The first step to identifying improvements in a process is knowing what to look for. In your VSM, look for improvements by identifying potential waste and a low first-time-right ratio for any process step. To identify waste we first need to understand what types of waste there are.
Learning from Lean process management we can identify eight types of waste when it comes to software product delivery (hence the acronym TIMWOODS for Lean wastes):
T – Transport – Unnecessary transfer of files, data, documentation or code
I – Inventory – Keeping ‘done’ features in a repository without releasing them to customers
M – Motion – Walking between office spaces to transfer/retrieve information from/to colleagues or handing over code, documentation or packages
W – Waiting – Waiting for a specific role to be available, waiting for permission, waiting for a build, test results or a deployment
O – Over production – Building certain features or user flows “because they probably will be used”
O – Over processing – Run more tests than necessary to validate a feature, unnecessary approvals, over-defensive coding
D – Defects – Defects that could have been encountered earlier through testing
S – Skills – Under- or overuse of specific roles (for example, the one Ops specialist that has to do all the Ops work) 
While some steps can seem like a given, you should also wonder whether they add value to the customer or your process. For example, a manual approval process by management does not add customer value and potentially does not even help enhance your process. If this is the case, then this step should be considered for removal or automation. On the other hand, do not overzealously remove steps in the name of cycle time as you risk the chance of losing vital quality assurance actions.

2. Re-acquaint yourself with your process

You now have the skills and theoretical knowledge to read the VSM. Take your time and really read through your VSM. Is the process described in the VSM different than you thought? Are there any surprises about process steps executed by other roles? Asking yourself and your team these questions allows you to gain a common understanding of your delivery process.
Once you have re-acquainted yourself with your process and overall flow, it is time to zoom in on the metrics that were identified for the VSM. First of all, look at the total time required to deliver a product increment, also called Cycle Time (CT).
Does this time surprise you?
Many Dev teams we coach at Xebia are often baffled by the cycle time for their product, and so, this data acts as motivation for improvement.
Each process step contains its metrics. For functional testing, we could encounter the following metrics:
Fig 3.


For each step, the metrics are:
Cycle-time (CT): the time it takes to finish this step
Value-added CT: the time actual useful work is done, which in this case means executing a functional test
Non-Value-added CT: any time that is spent that can be considered as waste
First Time Right (FTR): The percentage of times that this step succeeds. A fail means re-work earlier in your process and increased cycle time.

3. Turn VSM data into process improvements

Looking at the example given in fig. 3 and its metrics gives input for a discussion about whether there is an opportunity for improvement. The example in fig 3. takes 35 minutes to process and consists of 10 minutes of real work. What happens in the other 25 minutes? Can we identify the type of waste? Is there something that happens manually that can be automated?
Why do our tests succeed in only 80% of the time? Is 80% First Time Right good enough for this type of testing work?
Asking these types of questions about the data of the VSM will eventually lead to specific improvement ideas. Some teams that we encounter get stuck in writing down problems without solutions which makes it hard to prioritise what to solve first.
Writing down improvements in a user story format makes improvements easy to compare both by estimated value (expressed in outcomes such as decreased cycle time, increased FTR) and effort.

4. Prioritise improvements by comparing effort and value

Your list of improvements will, when implemented, lead to a different process and thus an improved Value Stream. While it is better to define a future VSM and work toward it, we recommend that teams without prior knowledge of Lean and process improvement first start with picking up and implementing improvements one by one. That way, they get in the mode of continuous improvement and are able to adopt practices such as Continuous Delivery. A team trying to adopt DevOps that has never deployed to an Acceptance environment doesn’t know how an improved process of going live should look like.
Once you have compiled a list of improvements based on VSM data, I recommend making an effort/value matrix in which you plot your improvements. The improvements that cost the least effort and deliver the most value are your quick wins and should be implemented first. Improvements that have much value but require much effort are often good candidates for splitting up in smaller chunks.
Fig 4. Effort/Value Matrix

Mapping the value also helps with the business case for improvements. Many teams that we work with think they know what the “right” thing is to improve but knowing is not enough for stakeholders. Stakeholders need to accept that implementing improvements is an investment that requires team capacity. Showing the stakeholders what the value of an improvement is in terms of measurable outcomes helps to shape the business case for them.

5. Rinse and repeat

After an improvement has been implemented, we need to measure its outcome and update our Value Stream Map. This gives you another opportunity to look at your Value Stream and look for new improvements. Continuous Improvement is nothing more than repeating this process until the effort of most improvements outweighs their value.
 

Conclusion

Having made a VSM does not equal value stream optimisation, but with a few steps, you can start reaping a VSM’s benefits. The key is to repeat the process steps described in this blog to achieve continuous improvement that is based on data. It is key to focus on measurable outcomes to really improve your Value Stream and become a highly performant team.