Lead time is the time between first code—measured by the first file changed in a commit—and merging a commit into trunk/main.
Lead time helps engineering teams to better understand how quickly and efficiently they can design, build, and deploy new features and products.
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 roadblocks or 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.
Code to commit to merge
Lead time includes the total time elapsed between making changes to the codebase and deploying your team’s changes. To identify the bottlenecks in your system, it’s important to understand how to break down lead time into its two key segments: code to commit and commit to merge.
First, code to commit measures the time elapsed between the first changes made to a file in a commit and committing those changes. Code to commit helps you understand the size and duration of work between commits. Working in small batch sizes and committing frequently can improve development speed, quality, and collaboration.
Second, commit to merge measures the time elapsed between committing changes and merging those changes into the main/trunk branch. Commit to merge measures how effectively your team is able to continuously integrate new code.
Combining code to commit and commit to merge will reveal your lead time—the total time elapsed between first code and merging changes to the main/trunk branch.
Improving lead time
Shortening lead time requires identifying and eliminating delays in the development process—such as creating development environments, running tests, and requesting change approvals.
A few best practices for improving lead time include:
- Loosely coupled architecture. On high performing teams, developers are able to test and deploy their code without requiring orchestration with other services. In systems with a loosely coupled architecture, services and applications serve a single purpose and can be deployed independently.
- Continuous integration and deployment. With CI/CD, teams automate the building and testing of code whenever code changes are committed to version control. Developers receive continuous feedback through fast feedback loops that help them make improvements and avoid conflicts with the rest of the codebase. Once code is ready to be shipped, pipelines are highly automated and efficient at deploying changes to production.
- 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.
Measuring lead time
Lead time can be measured through analysis of version control systems, like git. On the Software.com data platform, team commit data is analyzed through Software's GitHub integration. When you connect GitHub to an organization, you will be able to see up to 60 days of historical data.