Lead time for changes is one of the most interesting metrics you should use to evaluate the efficiency of your Engineering performance.
But why do you need metrics in the first place? “If you can’t measure it, you can’t improve it.” Often attributed to Peter Drucker, this quote means that without measuring your results, you can’t know whether you are succeeding or not, and it’s harder to adjust your process in the right direction.
There are four key Accelerate metrics that we will cover in detail: Lead time for changes, Deployment frequency, Time to recover, and Change failure rate. In this article, we are focusing on Lead time for changes.
So keep on reading to know what Lead time for changes is, how we measure it in Pulse, and how your team can start using it to achieve elite engineering performance.
What is Lead time for changes?
In a nutshell, Lead time for changes measures the time that a commit takes to reach production. This metric is correlated with both the speed and the quality of your engineering team.
“Shorter product delivery lead times are better since they enable faster feedback on what we are building and allow us to course-correct more rapidly. Short lead times are also important when there is a defect or outage, and we need to deliver a fix rapidly and with high confidence.”
Accelerate: The science of lean software and DevOps: Building and scaling high performing technology organizations
What does Lead time for changes measure?
Lead time for changes is a good indicator of the efficiency of the development process, the code complexity, and your team's capacity. It is one of the most interesting speed metrics for an organization to work on reducing its delivery times.
This metric is inspired by the Lean principles and analyzes how quickly your teams react to change (like a bug fix, new functionality, or other code changes).
How to read Lead time for changes?
On the one hand, a Lead time for changes that is too high is an indicator that there may be inefficiencies or bottlenecks in your teams’ process. On the other hand, a low Lead time for changes shows that your team can quickly react to feedback or changes.
Your teams’ goal should be to continuously reduce your Lead time for changes because it means that, when there is a problem, whether a minor bug or a critical outrage, your team can deliver a solution in a timely fashion.
What’s the difference between Lead time for changes, Lead time, and Cycle Time
Differently from Lead time for changes, Lead time measures the time it takes to go from a customer’s request to that request being satisfied.
Cycle time measures the time it takes for your team to complete work items once they begin actively working on them.
Lead time, cycle time, lead time for changes
Yes, Lead time for changes is an approximation. Still, it has its advantages: not only is it the easiest metric of the three to measure by focusing on the measuring CI/CD pipelines, but it also avoids the variability that is characteristic of earlier stages of the software development lifecycle.
Keep this in mind when choosing what to measure. If you are interested in the end-to-end visibility of your process, you should consider Lead and Cycle time.
Lead time for changes in Pulse
Products like Pulse make it very easy for your team to know how your Lead time for changes looks like. Pulse seamlessly connects with your GitHub and Jira to give you Lead time for changes and other Engineering metrics out-of-the-box. Your team only needs to focus on making informed decisions to improve your results.
How is Pulse measuring Lead time for changes?
Pulse measures Lead time for changes by calculating how long it takes to go from code committed to code successfully running in production. It’s computed with the following formula:
median(deployment timestamp - changes timestamp)
Here, changes timestamp is when code is actually checked into your repository, and deployment timestamp is when your code is deployed to production.
Lead time for changes in Pulse
Pulse calculates the four key Accelerate metrics, including Lead time for changes, by detecting your Pull Requests flow, interpreting semantic version tags, or receiving dedicated events through its API.
Pulse takes care of all the details to ensure your metrics are accurate and reliable. For example, Pulse correctly tracks your changes even if you squash or rebase the commits when merging the pull request; and it also associates all GitHub teams with the person that commits a certain change, enabling you to explore the metrics per team.
What Lead time for changes should a team have?
The best practice performance level for this metric, published every year on the Accelerate State of DevOps 2021 report:
- Elite: less than 1 hour
- High: between 1 hour and 1 week
- Medium: between 1 week and 6 months
- Low: more than or equal to 6 months
How to start using Lead time for changes
Over time, Lead time for changes should be getting smaller, while your team is increasing in the performance level until reaching best practice levels.
Having a small Lead time for changes allows your team to continually receive valuable and actionable feedback and deliver high-quality software quickly.
Causes of a high Lead time for changes
- Very large changes to be introduced in the code;
- Unclear requirements or poor definition of Ready;
- Tests are being carried out manually;
- Inefficiencies in the development process (e.g., blocks, dependencies, legacy code);
- Bottlenecks and unnecessary complex routes to production.
How to reduce Lead time for changes
- Work on small and self-contained changes: working with smaller versions of changes makes it easier for developers to get feedback faster and resolve issues sooner.
- Use test automation: incorporating automated tests at every stage of the CI/CD pipeline can help you reduce delivery times since it helps catch issues earlier.
- Automate code reviews: using automated code review tools like Codacy can help you improve your code quality and save your team valuable time.
Conclusion
Lead time for changes is a fundamental metric to analyze and improve the efficiency of your DevOps team. It is a valuable metric to understand the capabilities of your team and how quickly they respond to changes.
Together with Deployment frequency, Time to recover, and Change failure rate, this metric provides valuable insights for your team to achieve full engineering performance.
With Pulse, you can easily measure and analyze the Lead time for changes in your projects and make better decisions.
We also suggest you keep reading about how to measure engineering performance with this article: The dark side of productivity metrics. After all, picking the wrong metric can give you a false sense of security and lead you to adopt prejudicial behaviors for your team.
Webinar: How to boost your Engineering Speed & Quality with the right Metrics.
Are you looking for ways to deploy faster and more efficiently without compromising code quality?
Our team leads at Codacy and Pulse will show how you can make the most out of the engineering data already available to you, and empower you to measure all your engineering performance.
Join us in our Webinar: How to boost your Engineering Speed & Quality with the right Metrics. See you there!
👉 When: March 24th 2022, 11 am CST
👉 Where: https://bit.ly/codacywebinar_