My friend John is a delivery lead at a local Chicago software firm. He’s trying to get the hang of using metrics to help improve the performance of software development in his organization. He was originally looking at lead time and cycle time but was really confused after some internet research. It seems many people think they are the same thing and use the words interchangeably. It turns out cycle time and lead time are not the same thing. Let me tell you the story of John and explain how tracking cycle time and lead time can give you valuable information to improve your software development teams.
John’s 43rd birthday was just this week and to manage the sting of his mid-life crisis he decided to buy a 2019 Ford Mustang 5.0, in red (of course) with black leather and a 6-speed manual transmission. He had to custom order it because no dealership in Chicago had one in stock. It would take 6 months to build and have delivered. That news seriously soured John’s mood, so we grabbed a beer to make him feel a little better.
For a custom order of a Ford Mustang, we have to look at lead time. Lead time is the amount of time it takes to go from order to cash. When John places the new Mustang order, the clock starts. When John takes delivery of the Mustang, the clock stops. John really wants this time to be as short as possible, so he can go smoke the rear tires doing donuts in his local Home Depot parking lot after hours!
Had John ordered a standard Mustang package, he could focus more on cycle time and would find that he would have a much shorter time to wait. Cycle time is the amount of time in-between Mustangs coming off the assembly line. Ford makes roughly 70,000 Mustangs per year. Had John not ordered custom, he would only have to wait for the next one to be finished. If you do the math on 70,000 cars per year you would see that on average, a new Mustang is completed every 7.5 minutes. John would have his car almost immediately if he would just accept any Mustang. But John doesn’t want just any Mustang.
Cycle time is the inverse of throughput rate. Let’s look at an example: if Dave can drink one beer per hour, his throughput rate is just that: one per hour. Dave’s beer drinking cycle time is the inverse of that, which is 1 hour. That means a beer will be consumed by Dave every hour. With only Dave drinking beer, the only way to improve throughput rate of finished beers is to shrink lead time. That means Dave will have to drink a lot faster. Dave didn’t want to get sick, so he invited me over to help him with the beer problem. That decision improved total throughput rate of finished beers (now 2 per hour) and cut cycle time to 30 minutes. However, lead time remains unaffected since the time it takes for 1 beer to be drank is still one hour.
Software development is like John’s custom Mustang. Lead time is an important metric to capture and use to improve since each feature is unique and is made by someone who is unique. You can use average feature development cycle time to understand and help improve a team’s output. It’s also helpful to help determine when adding extra teams to a large software initiative might be beneficial. It’s better if you use and understand both cycle time and lead time to paint a larger picture of how well you’re satisfying customer demand.
In short, cycle time and lead time are not the same, but both are useful. Start capturing lead time and cycle time metrics. Capture the time it takes to go from a software feature request to a delivered feature in production. Aim to reduce that as much as possible to improve your agility and predictability.
