Tracking metrics like lines of code written is a recipe for frustrated developers and poor efficiency. DORA metrics shift that focus to really understand what drives developers so their productivity can be effectively tracked and improved over time.
A tech organization's most valuable assets are its people and data. The two must function as a unit for maximum output.
However, many organizations struggle to reconcile both assets, resorting to poor metrics. Some count lines or codes, others, velocity.
The problem is, these aren’t what really matters.
Consequentially, they deal with frustrations, high turnover rates, low ROI, and tons of wasted potential.
For example, many developers would do a better job with less code than more. So you can expect such developers to get frustrated in an organization where lines of code are used as a productivity metric. Often such frustrations lead them to just quit.
An organization that measures velocity would have only successfully wasted their resources—velocity only tells them what they did the previous week; plus, it’s not transferable between teams.
Besides, do rates of velocity equal real value? If company Y measures velocity and its teams are forced to produce loads of things, but they're all useless, then is company Y really productive?
A better option for companies is an all-encompassing developer lifesycle metric system that understands their engineering teams' productivity and measures accordingly—that framework is DORA.
DORA metrics are a framework of four metrics that help DevOps teams visualize and measure their performances effectively. These four metrics establish elite, high, medium, and low-performing teams and allow team leaders to (mindfully) consider processes that will improve their DevOps team's performance and generate value for the organization.
Let's pause for a minute to learn its origin.
The DORA metrics come from the DevOps Research and Assessment (DORA) team. In 2018, this Google-acquired research team surveyed a total of 32,000 development teams around the globe across multiple industries. Their goal was to determine what makes a high-performing team different from a low-performing one by understanding the practices, abilities, and operations that generate high performance.
In the DORA organization's report, Accelerate: State of DevOps 2018, the DORA team explained these metrics for the first time. According to the team, they indicate the performances of DevOps teams as related to software development and delivery capabilities.
Let’s explore each one in detail.
Deployment frequency indicates how often an organization successfully deploys code to production or releases software to end users. It’s essential as it’s the first place teams start.
DevOps' goal of continuous development requires teams achieve multiple daily deployments, and the deployment frequency metric provides a clear picture of where they stand concerning that goal.
How do elite performers make multiple deployments daily?
Many elite organizations change batch sizes to be as small as possible to make this work.
A common misconception of development frequency is that the more codes you ship, the more prone you are to risks. The assumption is if a certain percentage of production fails, then shipping more will only cause more issues.
However, the opposite is true, as seen with many elite organizations, since these modified and shipped productions are done one at a time in small batches under necessary observations.
Look at it this way:
If a bunch of modified productions are sent out at once, and something goes wrong, it’s difficult to track what modifications influenced whatever happened.
However, if productions are shipped in the smallest sizes possible, in several batches, at fixed daily intervals, it becomes possible to be a high-functioning organization that can (effectively) reduce overall risk and still increase deployment frequency.
To calculate deployment frequency, calculate the median number of days per week with at least one successful deployment.
Lead time for changes measures how quickly your team responds to changing conditions, events, or needs. It begins from the second the developer commences to the moment the products are shipped—for example, the average time between committing and releasing code into production.
Dividing these moments into buckets is a great way to track this metric.
Here’s how to do it:
The time it takes for a developer to work on something = bucket 1
The time it takes to deploy = bucket 2, etc.
By looking at things this way, you can determine what takes the most time and optimize accordingly.
Lead time for changes is an essential metric for your team as it ultimately establishes how successful the organization can be.
“How so?” You may be wondering.
Well, imagine a customer faces a bug; the quickness with which your team gets rid of that bug and ships the fix to production will determine if the customer keeps using your software or moves to a competitor.
Here are the benchmarks for the Lead Time for Changes metric:
To calculate lead time for changes, you need the project's starting time and the deployment's exact time. Then, you use the average time as an indicator of overall performance.
The mean time to recover, also called the time to restore service metric or mean time to repair (MTTR), measures how quickly a team can recover when customers face unhealthy situations.
The mean time to recover is a step in the incident process. Essentially, it must work together with the other metrics. If not, the team creates patches and hacks that, more often than not, make incidents worse than they initially were.
For this reason, your team must develop a culture of shipping production as soon as possible so that when an incident happens, shipping changes and fix comes naturally.
Here are the benchmarks for the Mean Time to Recover metric:
To reduce their MTTR, some elite performers use feature flags—toggles that allow them to switch a change on or off in production.
To calculate this metric, track the average time between a bug report and the moment the fix is deployed.
The change failure rate is simply the ratio of the number of deployments to the number of failures.
Here are its benchmarks:
The secret to having low rates is getting the developer (s) involved during deployments. This way, they understand the impact of their changes and the failure when an incident happens. Ultimately, excellent feedback is created, and the developer can ensure the incident doesn't repeat itself.
You can calculate this metric by dividing the deployment failures by the total deployments and multiplying your results by 100.
Data-driven decisions are crucial for not only driving better software delivery performance to make you an elite performer but also for helping you deliver organizational value faster.
Reviewing DORA metrics at the start of every retrospective one of the fastest and best ways to reach those data-driven decisions.
By measuring and tracking DORA metrics and trends, your DevOps team receives correct evaluations that guide your decisions to build better products that eventually lead to customer satisfaction and retention. Additionally, it amplifies feedback and pushes the team to align their productions with their organization's goals.
Ready to take the next step in reconciling your team and data and becoming an elite-performing team? We would be happy to accelerate that with DORA metrics. Contact us here or request a demo.
Join the ranks of data-driven companies seamlessly acting on feedback and driving substantial improvement with less effort.
ScatterSpoke helps you eliminate waste in your dev process.