Intro to DORA metrics
Actually using data to make impactful changes in software delivery and operational performance.
I know some of us roll our eyes when we here tech leaders say “we want this to be data driven” because sometimes nobody actually knows what data they need and WHY.
As on my staple thought leaders Simon Sinek says, “Start With Why” and the book is a great read for those who like to read. For the TL;DR you can always watch the TED Talk- How Great Leaders Inspire Action. Once you know get your why, come back and let’s get going on the DORA metrics 101.
Why do metrics matter?
If you haven’t read my other post, Metric here, metrics there, metrics everywhere, go ahead and start there so we’re all on the same page and talking from the same point of understanding. Back to why metrics matter, well simply put, in order to measure if changes to the state of something are working or not you need to know a few things
the state of the thing at a point in time
the changes that one makes to the said thing at another point in time
observation of change efficacy on said thing over a period of time.
WHY one needs to make a change to said thing in the first place.
There are many reasons ranging from improving quality, operational efficiency, moving to different tools etc. You need to you know your why in order to understand how to best use the metrics provided in the DORA framework.
How to measure your why?
Now that you know your why, let’s delve into how you can begin to establish variables and methods to measure said why. This is where the DORA Framework and metrics come in. Below we see the DORA core model, “a collection of capabilities, metrics, and outcomes that represent the most firmly-established findings from across the history and breadth of DORA’s research program”- https://dora.dev/research/
The model provides you with leading indictors pertaining to your team’s performance and overall well-being, and lagging indicators that speak to software development and delivery practices. Note that the model also is outcome focused and not output focused.
In order to gain value from using this model, there are 4 key metrics that one can use to measure their why, namely:
As this is a introductory blog, I will let you go ahead and do a bit of reading for yourselves about the metrics, and how to use them. Everything that you need can be found on the official site.
What now?
Excellent question, what do we now do with all these data points and our why? Well we put it together of course and establish a baseline from which we can begin to measure. We need a baseline because how else do you measure the difference between one point in time vs another point in time? So establish a baseline for each of those key metrics. Don’t overthink it or focus too much on getting fancy tools. A simple REST or GraphQL query or two or 4 should be able to help you establish baseline data points from your sourcecode repository manager.
Decide on a cadence for measurement and how much you would like to improve your scores by. That becomes your key result, and you can evaluate what changes are required in order to achieve said key result. There may be changes in people, processes, tools and behaviour, after all DevSecOps touches on all these aspects. Personally I would recommend an iterative approach to implementing this model, where tweak are made when they are needed after each review cycle.
Okay, that’s it for today and I think we’re all on the same level of understanding about the basics of the DORA metrics, why we need them, how to use them and what value they can add to your tech teams.
As this this forms part of the bigger picture about potentially adding S(ecurity) to DORA, it is imperative that we understand the basics of the framework before we add the security goodness to the metrics.
As always,
Be Kind. Be Brave. Be You.
Mats.