What is lead time?
Lead time in DevOps measures how much time has elapsed between committing code and deploying it to production, tracking the time spent on implementing, testing, and delivering changes to the codebase.
Lead time in software development is also one of the four key metrics used by the DevOps Research and Assessment (DORA) team to identify how well a software development team performs. The four key metrics are:
- Deployment Frequency: measuring the number of times a product is released successfully.
- Time to Restore Service: measuring the time it takes to amend a problem in production.
- Change Failure Rate: measuring the number of deployments that cause problems in production.
- Lead Time for Changes: measuring how long it takes a commit to be put into production.
While different teams may take the meaning of lead time metrics differently in accordance with their own goals, the ultimate aim of DevOps lead time is to find efficiencies and increase the speed of deployment. It’s a well-calculated metric that helps technical teams measure their DevOps capabilities.
Long vs. short lead time
Long lead times limit your organization’s ability to deliver value to your customers. If customers need to wait months or quarters for product updates, they are more likely to leave for competitors who can ship new features on a weekly—or shorter—cadence.
Long lead times can be a sign of developer frustration. Engineers could be experiencing bottlenecks when shipping code, hurting team velocity and morale.
Short lead times mean that organizations can rapidly deliver more value to their customers. Teams with shorter lead times are able to more quickly respond to customer feedback, set their industry’s pace for innovation, and ultimately win the marketplace.
In high-performing organizations, developers integrate commits to the main branch with fewer roadblocks and less time spent waiting. Shipping features to production feels effortless, automatic, and smooth.
Where to start with lead time
Knowing where to properly start with DevOps lead time will help your future tracking. The first step is to decide when you and your team consider the work to truly start and end.
Most teams measure lead time as the time it takes to get a commit into production. To measure lead time, calculate the time elapsed between making a commit and releasing it to production.
Some teams track lead time starting when development work is first scheduled, often in a project management tool such as Jira or Clickup. Calculating lead time beginning when you create a task helps teams understand the full feature life cycle, including the design and planning stages, but can be skewed by backlogs or different project management techniques.
Collecting data
You can collect the data of your tracked lead time in one of two ways. The traditional way would be to simply ask developers for the average lead times. The other and, arguably, most efficient way would be with the help of a dedicated DevOps metrics platform.
Many companies are now opting for the latter, integrating their DevOps software and commit data into their everyday tracking. In contrast to simply asking developers to let you know the average lead time, using an automated metrics platform will give you more accurate results that are easier to aggregate and analyze.
Categorizing data
As previously mentioned, different DevOps teams will measure their lead time in different ways. In terms of tracking lead time for changes in production, teams will generally categorize their lead time as:
- Less than one hour - Elite
- Between one day and one week - High
- Between one month and six months - Medium
- More than six months - Low
Usually, those who categorize their lead time as less than one hour, or elite, can also deploy code 973 times more frequently than those who are categorized low.
Showing the data
Because the main purpose of DevOps lead time is to measure how long it takes between code being committed to when it is deployed into production, it’s easy to see why it is also beneficial for tracking areas for improvement in DevOps performance.
Pinpointing these weaknesses isn’t for punishing developers, but rather to see where team processes could be improved and why things might not be running as hoped. The data can ultimately help your teams make the necessary changes needed for success.
A good way to present the data is by visualizing your metrics together in a dashboard. This involves collating the data and processing it through a data warehouse like Google BigQuery, before transforming it into a comprehensive dashboard. A good example of lead time graphing done well is the GitHub Google Four Keys project. Although it requires some manual setup, it’s a project that works well with most codebases and DevOps tools, collating data into a dashboard that is clear for engineering managers and developers to understand.
How to optimize lead time
Optimizing and reducing your lead time can be beneficial to your team and the success of your business, and there are a few ways it can be done.
CI/CD and continuous deployment – Automating the pipeline
Continuous deployment is a commonly used strategy in software where each code commit or merged pull request is automatically released to production once it passes the automated testing stage.
CI/CD integrates the continuous deployment strategy with continuous integration, a practice where code changes are made regularly. By employing two strategies, CI/CD enables development teams to deploy code to production more efficiently and quickly.
By employing CI/CD, speeding up the delivery process, and reducing manual tasks, you can substantially reduce lead time.
Test automation
Test automation is the process of automatically reviewing software to make sure it meets the expected standards. Developers would usually use bespoke software to test automation, as it better guarantees accurate checks.
Because test automation replaces many of the manual checks for developers, it ultimately reduces lead time. Not only does it save developers time going through the tests themselves, test automation also allows for any necessary changes to be made early in the development life cycle, reducing change failure rates.
When you integrate CI/CD with test automation, you can reduce your overall lead time, allowing you to release products to customers at a much faster rate.
Loosely coupled architecture
On high performing teams, developers are able to test and deploy their code without requiring much orchestration with other services.
In systems with a loosely coupled architecture, services and applications serve a single purpose and can be deployed independently.
Lightweight change approval
Developers do not need to wait for external reviews or slow change approval boards to merge and deploy code changes. They have access to team members who can review and comment on their changes, in addition to automated testing through continuous integration and deployment.
Flow time
Developers protect time for focused, uninterrupted coding. They have a balanced meeting load and are able to find time for productive deep work.
