DORA and the software delivery performance

Measuring DevOps Performance with DORA Metrics

The development process, especially with agile methodologies, is quite difficult to measure and objectively evaluate. Yes, we adapt quickly to market and customer requirements, but sooner or later, most software companies face performance issues.
For those who are just beginning their journey into the world of DevOps metrics, DORA (DevOps Research and Assessments) metrics will be a good start. They are simple, straightforward, and do not require significant time to implement.

The Four Key DORA Metrics Explained

DORA allows one to evaluate their team's software delivery performance based on four main parameters:

1. Lead time for changes - how long does it take to go from code committed to code successfully running in production? The time between ready to deploy and actual deployment.
2. Deploy frequency - how often does the organization deploy code to production or release it to end-users? The more often - the better.
3. Time to restore - how long does it generally take to restore service when a service incident or a defect that impacts users occurs? How long does it take to resume production after an error? The less - the better.
4. Change fail percentage - the percentage of deployments that led to production problems. The less - the better.

The ratings would be Elite, High, Medium, or Low.

Aligning DORA Metrics with Business Goals

DORA metrics help align development goals with business goals.
This is a remarkable but not a universal tool. After all, each team has its environment, product, and problems.

When to Use and When to Skip DORA Metrics

What should one consider when deciding on using this tool:

• Lead time is relevant only for startups, where the key to success is the speed of market entry, even if the product is a bit "raw".
• Deploy frequency directly depends on the current needs of the project and the competence of the team. There is a clear distinction between deploying: adding new functionality or fixing bugs in previous releases.
• Time to restore - for many modern services, it should be measured in minutes, and some services don't allow it.
• Change fail percentage is also a rather controversial indicator; there are industries where it can exist only theoretically, like banking (financial) or medical software.

Evaluate who you are and what will be helpful for your team? Will these metrics answer the questions that are relevant to you, or will they become part of uninteresting stock statistics?

Focusing on Clients Over Numbers

Remember: all metrics are just the tip of the iceberg, and you should focus not on abstract numbers but the specific client and their needs.
For those who still want to dig deeper and understand the nature of DORA: Why? Where? And how? We recommend: Accelerate: The Science of Lean Software and DevOps.