A guide to help teams reduce the Lead Time For Changes (DORA Metrics) metric.

In this article, we will take a closer look at one of DORA Metrics, Lead Time For Changes (Change Lead Time), and how it can be reduced to optimize software development and delivery processes.

Optimizing Software Engineering Processes

Metrics are a way of measuring something. They are used to understand the current situation, identify trends, predict future outcomes and make better decisions.

DORA metrics are the best way to measure and improve the health of the software delivery process.

What Are DORA Metrics?

DORA metrics have been widely adopted by organizations across the world. They are now the standard for measuring software value delivery.

DORA metrics are the way to go if you want to measure overall software delivery performance. But what are they basically?

Read my article on ‘How To Measure DORA Metrics Accurately’ here:

DORA Metrics (a.k.a. Accelerate Metrics & Four Key Metrics)

1. Lead Time For Changes: The amount of time it takes a commit to get into production.
2. Deployment Frequency: How often an organization successfully releases to production. High-performing software teams release often and in small batches.
3. Change Failure Rate: The percentage of deployments causing a failure in production.
4. Time to Restore Service: How long it takes an organization to recover from a failure in production.

Learn more from Google Cloud’s DORA research page: https://www.devops-research.com/research.html

Organizations should measure and track all these four key metrics together to make better decisions and accelerate their value delivery performance.

If you only focus on one or two of these metrics, you will probably make poor decisions. Assume you focused on increasing deployment frequency and decided to reduce testing efforts in order to make more production deployments in a shorter period of time. Your organization/product will most likely lose stability and reliability as a result of your decision.

Focusing on four DORA Metrics is the best and only thing you can do to create a high-performing organization.

But now we will talk about reducing the Lead Time For Changes (while taking care of all DORA Metrics as well).

What is the Lead Time For Changes?

The interval between a code change and its release to the end users is considered Lead Time For Changes.

Lead Time For Changes = [Production Deployment Time] - [First Commit Time of all changes]

The Anatomy of the Lead Time

The image below represents the anatomy of the Lead Time metric.

Lead Time Breakdown

Let’s dive into this breakdown to understand how we can reduce Lead Time For Changes.

The Stages of Lead Time For Changes

Lead Time For Changes mostly measures friction in the coding, code review, and CI/CD processes.

1. Coding Time: The time elapsed between the First commit and PR opened.
2. Code Review Time: The time elapsed between the PR opened and PR merged.
3. Waiting For Deploy: The time elapsed between the PR merged and Deployment pipeline started.
4. Deployment Time: The time elapsed between the Deployment started and Deployment finished successfully.

https://oobeya.io — DORA Metrics Tracking

How To Reduce the Lead Time For Changes

The best thing you can do to reduce Change Lead Time is to identify software development waste and bottlenecks.

Identifying waste and working on reducing it will automatically reduce the lead time and increase the development teams’ productivity!

Let’s see how we can optimize the stages of Lead Time for changes:

Optimize Coding Time

• Reduce rework in the coding cycles (but first measure Rework)
• Work with small batches
• Avoid unnecessarily complex solutions (needs technical and domain knowledge)
• Avoid multitasking and context switching
• Write clear requirements
• Fasten the feedback cycle (always the most critical one)

Optimize Code Review Time

• Keep it small. If reviewers decide to battle with your changes, it will take too much time to review the PR.
• Code faster. Break large features into small pieces and keep the coding time short for each pull request. See the problems earlier.
• Review faster. Don’t let your code changes stale to prevent potential merge conflicts.
• Create a Code Review Checklist
• Automate what can be automated in the code review process. Automation is the first gatekeeper of code reviews.
• Be ready to be reviewed. Review yourself before submitting. Give it a clear and descriptive title and write the best description.

Check out my article on Code Reviews here:

Optimize Waiting For Deploy Time

• Automate your CI/CD process.
• Increase your test automation coverage.
• Create a strong set of smoke tests, regression tests, etc.
• Eliminate manual approval processes.
• Reduce pipeline queue time. Improve your CI/CD tooling performance and capability.

Optimize Deployment Time

• Identify friction in the CI/CD process.
• Reduce CI/CD pipeline duration.
• Cache build dependencies.
• Optimize container image size.
• Check the network latency.
• Optimize resources.
• Review pipeline architecture.

“Yes, I know where I need to improve!”

These are the magic words that open the doors for effective and sustainable improvement.

If you want to improve the health and performance of your team, you should start by measuring metrics first. Then you’ll gain insights into what’s going on in your development and delivery cycles (by utilizing trends, benchmarks, patterns, anti-patterns, friction, risks, symptoms, and so on).

You will have the keys to optimizing system performance, team health, developer happiness, productivity, and organizational success once you start saying, ‘yes, I know where I need to improve’.

Yes, I know where I need to improve! — https://oobeya.io