If we acknowledge that we live in a software engineering world where complexity is inevitable, you may ask, what’s the point in trying to change anything about how we work?
Additionally, with so many clamouring voices around us trying to make us see sense, how can we go from day to day, making a difference in the way we build software when there are just so many options?
What we are trying to achieve (we are told) is a mystical state of Flow whereby code almost just builds itself, at high quality, to a mythical customer specification (which never exists). We would need to become mind readers to achieve this, and then be able to build, migrate and deploy perfectly.
It doesn’t take a leap of imagination to realise this expectation is unreasonable. You cannot achieve this level of perfection.
So why do we pretend that this is a realistic goal? And what is a realistic goal? There are so many ways to improve, anything we do could be considered positive.
So what is step one?
DORA Metrics
Step one is Measurement. If we agree that our engineering processes need improvement, then we need a way of measuring that improvement.
And to measure it we need basics in place. Let’s look no further than the DORA metrics.
- Lead Time – and perhaps we could add Flow Efficiency to that too. Therefore we measure the time from (say Jira) ticket creation to deployment to production (Lead Time) plus the ratio of time worked (hours spent on a ticket) to Lead Time (this is Flow Efficiency expressed as a percentage).
- Deployment Frequency – how often do you deploy? This should be readily available and obvious to find for everyone involved in software delivery.
- Mean Time To Recovery – how long does it take (from detection) to implement a fix. You can use incident tickets (perhaps they sit in Service Now?) for this metric.
- Change Failure Rate – how often do your changes (deployments) result in an outage? This will require some root cause analysis and some administration.You will need to ensure that changes that have been identified as causing problems are easily identifiable in your tracking systems.
A Start Is Important
For the moment, don’t worry about where your organisation sits in terms of ranking your DORA metrics alongside other companies. It is of more use to having a relative measure that is unique to your situation. This baseline will allow you to measure the change in your performance over time.
The next thing to do is ensure that you measure regularly or, if possible, create a dashboard that will enable you to track them automatically.