Step up your DevOps game: The dos and don’ts of becoming an elite performer
Every year, DevOps Research and Assessment releases a report about the state of DevOps. What did their findings in 2018 show? What are the most surprising results? We talked to Jez Humble, co-founder and CTO of DORA about the “elite” performers, the roadblocks that prevent low performers from advancing and more.
DevOps Research and Assessment (DORA) recently unveiled their 2018 Accelerate State of DevOps Report. Over 1,800 respondents from a varied sphere of companies were surveyed about cloud infrastructure, leadership and learning culture, delivery performance, database practices, and much more.
DORA’s software delivery performance benchmarks classified teams into three sections: high, medium, and low performers. Each team was measured on their global outcomes. Deployment frequency, lead time for changes, time to restore service, and change failure rate were all recorded.
15% of teams were classified as low performers, 37% as medium performers, and 48% as high performers. Included in the high performers are a 7% elite class who demonstrate excellence.
We talked to Jez Humble, co-founder and CTO of DORA about the “elite” performers, the roadblocks that prevent low performers from advancing and more.
JAXenter: The DevOps Research and Assessment (DORA) recently unveiled their 2018 Accelerate State of DevOps Report. According to the results, only 7% of teams were classified as elite class who demonstrate excellence. What does excellence mean? What does the new DevOps elite look like?
Jez Humble: When we analyzed the people who responded to the survey into clusters, we found an “elite” cluster which was small but did significantly better than the rest of our respondents in terms of both speed and stability. The elite performers are deploying multiple times per day, get changes into production and restore service in the event of an incident in less than an hour, and are seeing low change fail rates – in other words, they’re doing exceptionally well in terms of both speed and stability.
JAXenter: What is the feature that misguided performers have in common and how can they correct that?
The elite performers are deploying multiple times per day, get changes into production and restore service in the event of an incident in less than an hour, and are seeing low change fail rates.
Jez Humble: Misguided performers are an interesting group – they are very slow, deploying less frequently than once per month, but they achieve lower change fail rates than our low performers (although lower than our medium, high, and elite clusters).
What stands out though is their time to restore service: misguided performers report that they typically take one to six months to restore service after an incident. The way to to get better is the same as everyone else: process improvement work to deploy the capabilities we describe in the report, and in our book Accelerate, which are shown to predict higher performance.
JAXenter: What are the roadblocks that prevent low performers from advancing?
Jez Humble: Every organization is different, and will have different constraints. The first step is always for teams (including leaders) to feel some sense of urgency in addressing the problem, and dedicate resources, capacity, and effort to ongoing implement improvement work.
In too many organizations you hear, “that won’t work here, we’re different,” or “that’s the way we’ve always done things,” or “we don’t have time for that,” or “everything is going fine, why do we need to change?”
In contrast, high performers are always trying to get better at what they do.
JAXenter: What are the most important characteristics of cloud computing that need to be met for cloud success?
Jez Humble: In their paper defining cloud computing (SP 800-145), NIST lists five essential characteristics:
- on demand self-service,
- broad network access,
- resource pooling,
- rapid elasticity, and
- measured service.
Of those who said they were doing cloud computing, only 22% actually agreed they met these characteristics – but that group was 23 times more likely to be in the elite group than the low performing group! What this shows is that it’s not enough to just lift and shift into the cloud – by leveraging the unique capabilities of cloud infrastructure you can improve both the speed at which you deliver new services and the stability of those services.
JAXenter: How can we capture the multi-cloud opportunity?
Jez Humble: We didn’t perform analysis on the impact of multi-cloud adoption, but we did ask why people adopted multiple providers. Availability and disaster recovery were the reasons people chose most commonly.
JAXenter: Is automation one of the keys to becoming a better performer? How much automation is too much?
Jez Humble: We find that both test and deployment automation predict the ability to achieve continuous delivery, which in turn positively impacts both software delivery performance and organizational culture. However, it’s important for people to simplify as they go. Taking complex, fragile manual processes and automating them just creates complex, fragile automated processes.
It’s not enough to just lift and shift into the cloud.
Last year, we showed that architectural outcomes are also important, including the ability to deploy and release your product or service on demand, independently of other services the product or service depends upon, and the ability to do testing on demand.
JAXenter: What is the most surprising finding of the latest report?
Jez Humble: There were a bunch of surprises. The impact of effective use of cloud infrastructure is huge, but after that probably the biggest is outsourcing. While we knew that outsourcing by function is bad (for example outsourcing test/QA, infrastructure, or development) the effect is large: low-performing teams are 3.9 times more likely to use functional outsourcing (overall) than elite performance teams.
Furthermore, the “misguided” performers we discussed earlier report the highest use of functional outsourcing. Similar considerations apply to organizations with functional silos.