Cycle time measures the amount of time it takes work to exit a system from start to finish. I've written about the purpose of cycle time and how to measure it in previous posts. The start of the system in cycle time's case is when a software engineer begins their effort. The availability of their effort to users is the end of the cycle time.
There are several ways to measure cycle time. I want to present each of them in a series of posts. The goal of this series isn't to convince you which measurement is correct. The goal of this series is to show you different ways to measure the time work spends in a software development system. We'll talk about the trade-offs between the calculations. This post focuses on takt time.
Actual vs. Ideal Takt Time
It's worth noting a nuance upfront. I'm writing about actual takt time in this post. Takt time is traditionally used to define a metric a company strives to achieve. The common definition of takt time presents an ideal metric. Your ideal takt time sets a heartbeat for production. Ideal takt time is a syllogism that asserts:
- A company works X minutes a week
- Customers demand Y units a week
- Therefore, a company should produce a unit every X/Y minutes
I'm using this post to define your actual takt time rather than your ideal takt time. The metric we'll talk about is a measurement of how often you're actually releasing software instead of how often you should release.
What does actual takt time measure?
Takt time answers the question, "what is the average time between the start of production of one unit and the start of production of the next unit ?" What's a "unit"? For takt time, our unit of work is a release. This release could contain a single line of code or years of development effort. Takt time measures the average time between successive releases. A "release" could be a production deployment, availability on an app store, or whatever finish line your product has that adds value for your users.
Takt Time Example
Here's an example calculation of Takt Time:
This example shows the date and time of four releases named A-D. We subtract the dates from successive releases to derive the "time since the last release" in hours. Takt time is the average of all these times.
Benefits of the actual takt time measurement
All delivery metrics have some value. Peter Drucker advises, "What gets measured gets managed." Given that we can select our delivery metrics, what makes takt time special?
Takt time is easy to calculate. You're already tracking Deployment Frequency, right? Then you have everything you need to calculate takt time. In future posts in this series about cycle time, you'll see that our measurements can get somewhat complicated. The simplicity of takt time is a relief compared to the complexity we'll get into with Production Lead Time and Little's Law.
Shortcomings of the actual takt time measurement
Takt time is general. It gives no insight into indicators of trouble within a release. For example, a delivery could contain work from two merged pull requests. One pull request may have taken three hours of developer time. One pull request may have taken three months of developer time. Takt time doesn't do anything to flag that three-month effort as a problem in your software delivery pipeline. Takt time is only measuring the time between releases. It does nothing to measure outliers within a single delivery.
Takt time is a coarse, but useful, measurement of delivery throughput. If you'd like to receive updates about the next post in this series about cycle time, subscribe to the newsletter.