A guide to help teams make changes faster
This article will take a closer look at one of the Dora MatrixChange lead time, and how it can be reduced to optimize software development and delivery 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.
Dora Matrix Has been widely adopted by organizations around the world. They are now the standard for measuring software value delivery.
If you want to measure overall software delivery performance then DORA metrics are the way to go. But what are they?
Read my article on ‘How to accurately measure DORA metrics’ Here,
DORA Metrics (aka Quick Metrics and the Four Core Metrics)
- Lead Time for Change: The amount of time it takes from a commit to get into production.
- Deployment frequency: How often an organization successfully releases to production. High-performance software teams release frequently and in small batches.
- Change Failure Rate: The percentage of deployments due to failure in production.
- Time to Restore Service: The amount of time it takes for an organization to recover from a production failure.
Learn more from Google Cloud’s DORA research page: https://www.devops-research.com/research.html
Organizations must measure and track all four of these key metrics simultaneously in order to make better decisions and accelerate their value delivery performance.
If you focus only on one or two of these metrics you will probably make poor decisions. Let’s say you focus on increasing deployment frequency and decide to reduce testing effort to make more production deployments in a shorter period of time. Your organization/product will probably lose stability and credibility because of your decision.
Focusing on the four DORA metrics is the best and only thing you can do to build a high performing organization.
But now we will talk about reducing the lead time for change (while also taking into account all the DORA metrics).
The interval between a code change and its release to end users is considered the lead time for the change.
Lead Time For Changes = [Production Deployment Time] - [First Commit Time of all changes]
Anatomy of Lead Time
The image below shows the structure of the lead time metric.
Let’s dive into this analysis and understand how we can reduce the time taken for changes.
Lead time to change mostly measures friction in the coding, code review and CI/CD processes.
- Coding Time: The time elapsed between the first commit and the PR being opened.
- Code Review Time: The time elapsed between a PR being opened and a PR being merged.
- Waiting to Deploy: The time elapsed between the PR merge and the deployment pipeline starting.
- Deployment Time: The elapsed time between the start of the deployment and the successful completion of the deployment.
The best thing you can do to reduce change lead time is to identify software development waste and bottlenecks.
Identifying waste and working to reduce it will automatically reduce lead times and Increase productivity of development teams,
Let’s see how we can optimize the lead time steps for changes:
optimize coding time
- Reduce rework in coding cycles (but measure rework first)
- work with small batches
- Avoid unnecessarily complex solutions (requires technical and domain knowledge)
- Avoid multitasking and context switching
- write clear requirements
- Speed up the feedback cycle (always the most important)
Optimize code review time
- Keep it short. If the reviewers decide to conflict with your changes, reviewing the PR will take a lot longer.
- code faster. Break large features into smaller pieces and keep coding time short for each pull request. Look at the problems first.
- Review fast. Don’t let your code become out of date to prevent possible 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 review. Review yourself before submitting. Give it a clear and descriptive title and write the best description.
see my article on code reviews Here,
Customize wait for deployment time
- Automate your CI/CD process.
- Extend your test automation coverage.
- Build a robust set of smoke tests, regression tests, etc.
- Eliminate manual approval processes.
- Reduce pipeline queue time. Improve your CI/CD tooling performance and efficiency.
Optimize deployment time
- Identify friction in the CI/CD process.
- Reduce CI/CD pipeline duration.
- Cache build dependencies.
- Optimize container image size.
- Check network latency.
- Optimize resources.
- Review the pipeline architecture.
These magic words open the door to effective and lasting improvement.
If you want to improve the health and performance of your team, you must start by measuring metrics first. You will then gain insight into what is happening (using trends, benchmarks, patterns, anti-patterns, friction, risks, symptoms, and so on) throughout your development and delivery cycles.
Once you start saying ‘yes, I know where I need to improve’, you will have the keys to optimizing system performance, team health, developer happiness, productivity and organizational success.’