Using DORA metrics to understand software delivery performance
An education technology company
We worked with an education technology company whose engineers were running into friction in software delivery. Leadership lacked a consistent view of delivery performance and reliability across teams.
Alongside the engineering and platform teams, we improved the delivery setup and established DORA metrics as a common way to see bottlenecks and decide what needed attention next.
4
DORA measures tracked
1
shared source control and CI platform
Ongoing
team-level delivery visibility
What was getting in the way of delivery?
Jenkins pipelines were managed by the infrastructure team, leaving application teams dependent on them for build changes. Jenkins was on a very old version, role-based access control was not properly set up, and the pipeline DSL was hard to use.
Source control and CI lived in separate tools, so developers moved between systems for an everyday workflow.
What could be fixed before DORA came in?
Some issues were already obvious without metrics. We moved teams to GitLab and introduced GitLab runners for CI. Developers could own their build pipelines, with source control and CI in the same platform.
GitLab's YAML-based pipeline configuration and documentation made changes easier for teams to understand and maintain.
Where did DORA come in?
Leadership still needed a consistent view of delivery across teams, including where reliability suffered and work slowed down. We used deployment frequency, lead time for changes, change failure rate and time to restore service.
We began with a survey, checked the inputs with engineering teams, then built reports for each team's performance across the four measures.
What did teams do with the data?
Reports let teams compare their performance with one another and with broader DORA benchmarks. Platform engineers used the findings to prioritise work. We also worked with individual teams on tooling and platform changes aimed at the areas the metrics highlighted.
How did the team move beyond surveys?
The survey gave a starting point, not a sustainable source of fresh data. We connected the measures to deployment and incident-management tooling so they could feed dashboards without asking teams to fill in another survey.
Engineering leadership gained an ongoing team-level picture of delivery performance instead of a snapshot from one point in time.
Want to make your infrastructure work harder for your team?
Tell us what your engineers are wrestling with.