Data-driven engineering starts with DORA Metrics
DORA Metrics 101
The DORA (DevOps Research and Assesment) team is a Google research group that has identified four key metrics that indicate the health and performance of software engineering teams.
These four metrics help engineering leader evaluate the velocity (Cycle Time & Deployment Frequency) and stability (MTTR & Change Failure Rate) of their software development efforts. Companies should not only track these metrics at the team and organizational level, but also apply strategies for their continuous improvement.
Mean Time To Restore
Change Failure Rate
With Jira & GitLab, it has always been difficult to get the big picture, to understand where bits of work are stuck, and where teams aren’t working in an effective, efficient manner. LinearB makes visible, what isn’t with any other tool.
Getting Started with DORA Metrics
The goal of data driven engineering practices is to improve the efficiency and performance of development teams. The first step in this journey is to figure out where you are today. Thankfully technology has made gathering your baseline metrics incredibly simple.
LinearB is a free tool that integrates with your Git and project management system to provide team and organization level DORA metrics within minutes.
Once you’ve established your baseline metrics, you’ll be able to identify areas of improvement. It’s important to note that there are no golden metrics. DORA metrics, like all trackable numbers, should be used as conversation starters within your organization. If used with impudence, like measuring individual performance, metrics can erode a healthy team culture.
Discover the real impact of data-driven engineering Schedule a quick demo
Strategies for DORA Metric Improvement
Cycle Time is the easiest and most beneficial metric to start improving. Cycle Time is often referred to as a super metric because it can be broken down into four distinct phases: Coding Time, Pickup Time, Review Time and Deploy Time.
By breaking down Cycle Time in phases, you can visually identify areas of improvement. In the instance below, you can clearly see a bottleneck occurring around PR / MR Pickup time. Bringing this data point to the next team meeting or retrospective will help align the team on how best to improve.
Automating Cycle Time Improvement
Using automated notifications in Slack or MS Teams helps reduce project idle time between hand-offs. Reduced idle time translates to faster Cycle Time, a higher frequency of deployments and ultimately faster feedback loops with users.
WorkerB is a feature included with LinearB’s free team account that provides automated team alerts, personsal notifications, and personal commands for Slack and MS Teams. Automation like WorkerB reduces Cycle Time without human intervention.
Deployment Frequency is easiest improved by focusing on PR Sizes. While Cycle Time metrics like Pickup Time and Review Time play key roles in Deployment Frequency, keeping PR Sizes small should remain the goal.
The general rule for high performing teams is to keep PR Sizes below 150 changes. Breaking your work into small chunks will not only decrease your overall Cycle Time, but also make work estimations more easily refined.
Change Failure Rate
Change Failure Rate can be improved by focusing on your Review Depth metric. Review depth measures the average number of comments per pull request review. This metric is an indication regarding the quality of the review and how thorough reviews are done.
Tracking PRs Merged Without Review is another quality metric that will improve your Change Failure Rate. Development Pipeline Orchestration tools like LinearB help engineering organizations track these quality metrics and set configurable guardrails to alert teams when a potential quality issue occur.
Data-Driven Engineering with LinearB
LinearB is a Development Pipeline Observability and Orchestration tool that helps dev teams continuously improve. Our platform provides unique features that help each level of the engineering organization understand what is happening within the development process.