Measure Your Lead Time And Cycle Time

When you measure and analyse lead time[1] and cycle time you learn how value flows through your system. You also discover improvements you can make to deliver value faster. Unfortunately most teams do not measure lead time and cycle time which is a lost opportunity.

Here’s an example of how a data center team I worked with reduced their cycle time from 32 days to 5 days, and how it started with us measuring it.

Physical board + manual excel ftw
We visualised our work on a physical board we and tracked our metrics manually because in different ways the tools that were available to us (jira, trello, leankit kanban) did not meet our needs.

We had no idea what we would discover but when we looked at our metrics we learned that our cycle time was significantly higher (point 8 in the diagram below) whenever work was related to scaling a part of our datacenters.

We investigated further

To understand why we recorded how much time these tickets spent in the different states from start to finish[2], and whether that time was value adding or waste. We color coded value adding states green and waste states red.

Whenever we made progress we would note down the date, and how much time we’d spent on the ticket, on the backside of the sticky.

A lack of inventory(buffer) affected our cycle time
We found that when we didn’t have some specific hardware in stock our cycle time increased to over 30 days and the waste was 80%(24+ days waste). Compare that to a cycle time of 5 days when we had the part in stock.

Because we knew how many requests we got per month we could evaluate roughly how large hardware inventory we need to keep in order for our cycle time to always be 5 days. Together with our procurement team we discussed how large inventory we were willing to maintain from a financial and risk perspective.

Buffers can be good if they are small and increase your flow
No, not if it’s done in order to increase flow. While maintaining 0 inventory causes starvation and maintaining a large inventory either puts you at a financial risk or makes you slow if you want to change hardware, there is something in between.

Tips if you’d like to try this out for yourself

1. First visualise your workflow and make it more granular than the traditional “To do”, “In progress”, and “Done”. We identified 11 states in our workflow.
2. Track progress, timings, and dates on the backside of the stickies. It’s difficult to remember when 2+ weeks or more has passed. :)
3. In the analysis meeting, draw the workflow on the board and do a focused retro on that data e.g. ask “what’s working well in our process”, “what’s slowing us down”, and “what can we do to reduce waste”.

If you try this, please reach out and share your stories. I’d love to hear them!

Thanks for reading and good luck!

-V

[1] Lead time = time from when an idea is generated until it’s in production. Cycle time = time from when work is started until it’s finished. In our case – when it’s in production.

I should point out that there are different definitions of LT and CT. For example in lean manufacturing it means something different than it does in lean software development.  And even agile teams use it differently. Some teams have defined cycle time as the time from when they commit on work until when it’s in production. Other teams define cycle time as the time between when they start working on something until when they send it to their ops team for deployment, or until when they submit an app to appstore. What’s important is to identify and agree what makes sense for you, and to then measure that.

[2] Here are the states we had:

1. Not started
2. Figure out steps + create a plan
3. Inventory Hardware (HW)
4. Place Hardware order
5. Waiting for HW to be delivered
6. HW delivered, waiting to be installed
7. HW is installed pending configuration
8. HW is being configured
9. Pending Deploy
10. Being deployed
11. Done