No improvement coach or consultant should start a new engagement without a plan on how they will collect delivery data. Too often change is introduced into a system without a baseline assessment being undertaken. This is a wasted opportunity. In this post I want to provide you a quick guide on how I collect data prior to starting to introduce changes into an Agile delivery system.
Here is my approach to data collection:
- Choose the delivery system you want to collect data on. Depending on the organisation’s size and the type of work done you will need to select what to measure. It could be a portfolio process, a team’s end-to-end delivery process or a product discovery process.
- Meet a representative sample of people from across the system; get to know the key stakeholders. This is an opportunity to position who you are and why you are engaged; the aim being to ensure everyone knows you’re here to help and are a “friendly” (you are not here to find out who is responsible for low performance). Collecting data on a system can create fear from those doing to the work so it is important to set the tone for the mapping work.
- Invite everyone to a value stream mapping workshop. Get the people involved in executing the chosen process together for a 2-3 hour workshop. Choose a representative piece of work that travels through the chosen system. For teams I recommend a story that requires 5 or less dev days of effort. For portfolios this may be an epic of work.
During this workshop walk the process with the people in the room capturing all activities undertaken in the process of doing the work; also record all wait times between activities. Best to do this as a facilitated activity on a whiteboard (real or virtual). It might be messy, but it has all the raw data. See below for an example.
- Calculate process efficiency scores, lead times and end-to-end cycle time. After capturing the raw process, document the map in a visualisation tool and put the data into a spreadsheet. See below for the Mural I created from the above raw picture.
- Debrief with EVERYBODY and design data-driven change experiments.
A value stream map not shared is a lost opportunity to align everyone on the systemic problems that everyone could be solving. Often when everyone sees the waste in the system, they become more motivated to remove it. You can even calculate how much the wait time costs and make a case for change with your sponsor.
But what do you change first?
Look at the largest constraint to the flow of work (the longest wait times) and start a discussion on what could be a possible experiment to try. Experiments are a great way to frame changes to the way of working because they are not permanent and can be reversed if they do not produce the expected outcome.
Conclusion and Final words
It is my firm belief that the creation of value stream maps needs to be a mandatory practice for all ways of working/Agile change coaches/consultants. What these maps allow us to do is present a set of recommendations (for change) together with data to support our position (as opposed to our opinion).
The additional benefit of using these maps is the ability to “prove” that the changes introduced into an Agile system have had a measurable impact on delivery performance.
