Lead Time for Changes Explained (DORA Metric)

Uncover the essence of Lead Time for Change, a pivotal metric shaping the efficiency of software development. Join us in our upcoming blog post as we unravel the significance of swift transitions from commit to production, unlocking the key to responsive and streamlined development processes.

In today's rapidly evolving landscape, a key responsibility for software teams is to consistently deliver value. Different practices have been introduced to make engineering teams more efficient and agile in the software development process. For the software teams – it is very important to intercept the required changes and implement new software features smoothly.

In this article we elaborate the Lead Time for Changes metrics, one of the key DORA metrics.

If you'd like to go further and learn about the other three DORA metrics, we've created a free ebook for you. Download it now.

DORA Metrics - Quick introduction

As discussed in previous articles – led by the DevOps acceleration survey – in 2015 Google established the program called DORA (DevOps Research and Assessment) group. In 2018 they published their study Accelerate introducing the DORA Metrics – a concept that defines 4 key metrics that can distinguish the high-performance development teams from the average ones:

• Deployment Frequency (DF) – measures the frequency at which code is deployed successfully to a production environment. Engineering teams tend to deliver new features to clients as soon as possible, so this metric is useful to understand how frequently that happens.
• Lead Time for Changes (LTFC) – this metric shows how long it takes for a change to appear in the production environment by looking at the average time between the first commit made in the dev environment and when that feature is successfully running in production.
• Failed Deployment Recovery Time(also known as Time to Restore Service and Mean Time to recovery or MTTR) – measures the time needed for the system to recover from an incident in production. To improve the MTTR – DevOps should constantly observe the production environment.
• Change Failure Rate (CFR) – measures the percent of deployments causing a failure in production, and is calculated by dividing the number of failures by the total number of deployments.

DORA metrics give the team leaders truthful insights, as they can analyze the metrics to estimate the team performance. Then they can improve their internal processes. By looking at CFR and MTTR, leaders can ensure that their code is robust and stable, while reducing the failures. On the other side, monitoring DF and LTTC assures that the team is working at a good pace. Combined, DORA metrics provide crucial info about the team quality and speed.

What is Lead Time for Changes - definition

As mentioned above – lead time for changes measures how long it takes for a change to appear in the production environment. Imagine that you are developing a feature. You took it to the sprint, then someone started working on it. After the developer is satisfied, he opens the merge request, it is checked, and finally, your feature lands in the master branch. How long does it take to go from commit to master to release to production – that is the time to make the change. Less is better.

Why is Lead Time for Changes important?

LTFC helps the teams to make efficient code releases by identifying the obstacles and optimizing the development processes. It can also be used to set a realistic timeline and make correct decisions for future delivery times and project completion. A low lead time for changes enables reducing waste and optimizing the software delivery process. By identifying and removing blockages, your team can efficiently and reduce the amount of time and resources required to deliver new features.

Also, a low lead time for changes can help you to mitigate the risk by enabling more frequent and smaller releases. This allows you faster testing and feedback, which reduces the possibility of releasing major bugs or issues.

How to measure Lead Time for Changes?

Lead time for changes is computed by measuring the time from when a change is requested - to the time it is delivered to production. To manually calculate lead time for changes – you should conduct the following steps:

• Determine the start and end points of the change request process. This can be different for every organization, but it usually starts with a request for change (RFC) and ends when the change is deployed to production.
• Assign and remember a time stamp of the start and end points for a given change request.
• Compute the time difference between the start and end points, and that will give you the lead time for the change.

This process can be repeated for multiple change requests within a given period of time, e.g. a week or a month. Then you can analyze the data to identify trends and areas for improvement. The lead time for changes can differ based on the scope of the changes and the processes involved in delivering it to production. Thus, it's important to track the lead time routinely over time to determine its improvements or diminishments.

Example:

• You received a change request that was submitted on October 1st. The team completed and deployed the change to production on October 15th. The lead time for this change is 14 days (October 15 minus October 1).

• You received another change request on October 5th. The change was completed and deployed to production on October 10th. The lead time for this change is 5 days (October 10 minus October 5).

Within October, there were a total of 7 change requests with lead times ranging from 3 to 15 days.

What is a good Lead Time for Changes?

As we stated – different teams can consider different LTFC values as good or acceptable for them. Still, the Accelerate State of DevOps publishes annual Report with the best practice performance level for this metric, and here are their findings:

• Elite team: LTFC less than 1 hour;
• High-performing teams: LTFC between 1 hour and 1 week;
• Medium-performing teams: LTFC between 1 week and 6 months;
• Low-performing teams: LTFC more than 6 months.

What is the difference between Lead Time for Changes, Lead Time and Cycle Time?

In the DevOps terminology, there are separate definitions for Lead Time and Lead Time for Changes. Aside from Lead Time for Changes, the lead time tracks the time it takes to get from a client’s request to the request being fulfilled. There is also a Cycle time that measures the time it takes your team to complete work chunks upon they start actively working on them.

The lead time for changes measures the time from the first commit to the change being delivered, and it is an approximate time. Still, it has its advantages - it is the easiest metric of the three to measure the performance of the CI/CD pipelines. It also helps you avoid the uncertainty that is characteristic of earlier stages of the software development lifecycle.

When choosing what metric to measure - you should be interested in the end-to-end visibility of your process, thus you must consider Lead and Cycle time.

What causes High Lead Time for Changes?

There are multiples causes for a high Lead Time for Changes and here we list the main ones:

• Unclear client requirements;
• Poor definition of ‘ready’;
• Large changes required and made in the code;
• Manual testing process;
• Inefficient development process (e.g., blocks, dependencies, legacy code);
• Bottlenecks and unnecessary complex paths to production.

How to improve the Lead Time for Changes?

To improve your Lead Time for Changes and achieve low values for it – you can follow these advices:

• Smaller, self-contained changes - working with smaller versions of changes makes it easier for developers to get feedback faster and resolve issues sooner.
• Prioritizing changes – prioritizing based on business value and impact ensures that high-value changes will be completed quickly.
• Process automation – you will reduce the lead times by automating repetitive and time-consuming tasks such as testing, deployment, and provisioning.
• Reducing transfers - each transfer (handoff) in the change process increases the lead time. To maintain low lead times, try to minimize the number of handoffs between teams and departments.
• Process standardization - using consistent tools and technologies reduces variability and increases efficiency, resulting in lower lead times.
• Continuous monitoring and analyzing lead time data – this will allow you to identify the blockers and process improvements that can further reduce lead times.
• Improve communication - Ensure clear communication between stakeholders and teams to prevent misunderstandings and delays, which can increase lead times.

Simple way to measure Lead Time for Changes

Axify is a single platform to observe all the key performance indicators that will help you improve your development and delivery processes. It is equipped with superior dashboards and provides constant tracking of DORA metrics in real-time, hence simplifying the whole process and empowering teams to concentrate on making improvements.

Axify features include all four DORA metrics:

• Deployment frequency -measures how often an organization successfully deploys to production. This important metric makes it easier to test, deploy, provide feedback, and roll back problems, in addition to increasing perceived value for your customers.
• Lead Time for changes – time it takes from the first commit to successfully executed code in production. This metric allows us to assess the efficiency of software development cycles and initiatives. It tends to lead to organizational, human and technical changes.
• Change Failure Rate - measures the percent of deployments causing a failure in production, and is calculated by dividing the number of failures by the total number of deployments.
• Failed Deployment Recovery Time - measures the time needed for the system to recover from an incident in production

Manual calculations can provide you useful insights, but an automated tool like Axify.io can prognostically model system behavior and track lead time for changes effortlessly. Keeping your eye on the lead time for changes will give you insights about the team work pace. By making diligent efforts to lower this rate, you will reduce the waste and optimize the software delivery process, resulting in a streamlined operation and a satisfied team.