Understanding Lead and Cycle Time with our part-time community
Lead Time and Cycle Time are important concepts for teams who want to manage and plan their activities, minimise delays, and measure their efficiency.
Let’s walk through a hypothetical example.
- You walk into a restaurant and sit down.
- A waiter gives you a menu and walks away.
- Waiter returns, takes and confirms your order.
- Kitchen prepares your food.
- Waiter serves your order.
As shown below, the Lead Time clock starts when the waiter confirms your order and stops when you receive your order. The Cycle Time clock starts when the kitchen starts to prepare you food and stops when the waiter serves your order. How do you feel when your order is delayed by requests that are more important than yours? The words frustrated and dissatisfied come to mind. It’s important to avoid delays that negatively impact lead and cycle times, and more importantly user satisfaction.
We can transpose this to a software development team that delivers a bug fix.
Same team within our context
We are trying to get to grips with both the Lead and Cycle times, when working on guidance and tooling projects. The part-time nature of our community and our family>job>rangers mantra, often inject unexpected delays, skewing both the Lead and Cycle times, as shown below.
As you can see, our times includes delays due to the commitment to families, job, frequent travel, as well as disruptive context switching. For simplicity we are ignoring delays between the creation of the bug and the start of work.
Our Lead time is significantly longer.
It’s important for us to track both times, accept and understand the anomalies. By doing so, we can evolve our engineering process to deal with challenges and continue to improve our overall efficiency.
A few observations and improvements we are tracking
Inefficiency increases both the lead and cycle times, bloating the time and effort it takes to deliver value
We have virtual teams who support the teams with user experience and testing services, and help us raise the quality bar. We typically engaged them toward the end of the project lifecycle, adding a dependency on their availability and resulting in longer lead times 
.
We’re now encouraging members from the virtual teams to join the project teams to promote autonomy and reduce the dependency on virtual teams 
.
Less is more, especially in the context of work in progress (WIP)
It feels natural to open the sluice gates by increasing your work in progress. However, increasing the WIP limits is like throwing more resources at a problem … it usually makes problems bigger and increases the lead times . What’s interesting is that we observed the behaviour (increase WIP limits) and resultant bottlenecks during a recent Kanban Game hosted at Vancouver Microsoft.
We’re not suited for multi-tasking! Having less work in progress, allows us to understand the big picture, to focus, and deliver value faster … shorter lead time .
Work in progress (WIP) limits will bite you if ignored
When tolerating the red numbers (work > limit) on your boards, you are not only observing bottlenecks and higher lead times, but a willingness to comprise your workflow . Don’t do it, unless you want your backlog to merely represent a wish list.
Re-starting a project, especially during complex debugging, is frustrating, expensive and bloats the Lead time
We continue to promote short 3-4 sprint releases, each delivering 1-3 features, driven by a common goal. Projects experiencing multiple stop-start events or exceeding these timelines are re-triaged to ensure that they are still feasible and valuable. It’s often better to stop, than to drag a project, with a growing lead time, across the finish line.
You may be asking why this post is focused on the lead. It’s the time that our product owners, stakeholders and users perceive and therefore the most important when looking for improvements.
Sound familiar?
Have you got similar challenges? We would love to hear your feedback!