Overview of DORA — DevOps Research and Assessment

DORA — Quick Intro

In simple words, DORA is a way to Measure DevOps Performance.

The DevOps Research and Assessment (DORA) comes out of Google’s research group of the same name best known for their work in a six-year program to measure and understand DevOps practices and capabilities across the IT industry.

The DORA team’s research identified four key (Accelerate) metrics that indicate software development and delivery performance from their study data.

On top of the above DORA also emphasizes on following:

• The (four) Core Capabilities are applicable to high-performing technology organizations.
• Approach to measure and improve Delivery Performance.
• Essential role of DevOps in achieving scale.
• The reason why “Culture” isn’t the foremost important factor for fulfillment.

We offer DevOps Consulting and Support you in achieving best-in-class DevOps. Do feel free to ask us for more information at — info@bridgeapps.co.uk

The 4 DORA (Accelerate) Metrics

Let’s consider the Dora Metrics under consideration -

Deployment Frequency (DF) — is the number of deploys into “Production” in a defined period of time. This is a measure of Agility of the team in delivering software. DORA infers that teams with high performance aim to ship smaller and more frequent “deployments”, rather than clubbed up and more bigger “releases”. This improves time to market a feature, leading to improved value for customers along with reduced risk for the development team.

Change lead time — is the time between a change request to the delivery of the change. Lead time is a measure of the overall effectiveness of the implementation of the development methodology.

Longer change lead times — is typically a result of pooer deployment and development process.

Shorter change lead times — shows better work organization, stronger development frameworks, better team coordination, and better development and deployment processes.

For a given change request, Change lead time is measured as the time taken from the first commit to the time of deployment. This measure omits the time taken for requirement prioritization & requirement gathering/design but assumes that development can start immediately post the request phase.

Change Failure Rate — is defined as the ratio of the number of deployments to the number of failures. This is a measure of the quality of the code and the maturity of the team members.

This assumes an optimum implemented DevOps including automated regression testing, higher test coverage & trained developers performing development to understand and cover both technical and business test cases.

A higher change failure rate — shows a poorer quality of code and points to a need for more investment into training team members, more emphasis on developing stabilized framework.

Mean Time to Recovery (MTTR) — is defined as the time taken to recover from a production issue in a given period of time.

This is a measure of the system stability, quality of code, and more importantly, team understanding of Data and logic for the business requirements at hand.

MTTR optimization results in minimized downtime of the system and helps to build systems that can detect, diagnose, and correct problems faster when they happen.

How to Measure DORA?

As observed from the metrics, the DORA metrics are all about measuring how efficiently DevOps is implemented — both team and technology-wise.

For a DevOps Practice manager, DORA is the primary measure that captures the metrics and provides a measure of the efficiency of the team.

Our suggestions on going ahead with capturing DORA metrics are as below -

1. Define a time window for capturing and reviewing DORA metrics, for e.g. every quarter or every 2 months.
2. Create a Dashboard for capturing these metrics, which shows current DORA metrics and their comparison with past DORA metrics.
3. Capture and review qualitative DORA metrics on a per resource basis, where applicable, measuring within the team and reviewing where applicable.
4. Optimize the DevOps process to have a higher Deployment Frequency, with a better Change Failure Rate.
5. Attempt to have the lowest MTTR, by ensuring more better regression testing, and higher test coverage in code. Use of the Cloud improves MTTR significantly, along with better Integration design.

We offer DevOps Consulting and Support you in achieving best-in-class DevOps. Do feel free to ask us for more information at — info@bridgeapps.co.uk

Originally published at https://bridgeapps.substack.com on March 28, 2022.