Benjamin Wootton

6 September 2018

4 Uncommon Takeaways from DORA's 2018 State of DevOps Report

Alright, let’s get the bleedin’ obvious out the way first. The 2018 Accelerate: State of DevOps report by DevOps Research and Assessment (DORA) convincingly demonstrates that:

1. Software delivery is critical for high organizational performance
   By this we mean increased profitability, productivity, market share, customer satisfaction, achieving organisational goals—all that good stuff.
2. DevOps and cloud are critical for high-performing software delivery
   Teams with mature DevOps practices in the cloud deploy 46x more frequently, have a 7x lower change failure rate and recover 2600x faster from incidents than low-performing teams.

Thus, DevOp and cloud are critical for high organizational performance.

But you know that. We know that.

Today, I wanted to highlight a few less-talked-about points about DevOps that the report raised that I think are very worth talking about.

1. The digital transformation journey is not linear

It will not always be obvious that you are making progress on your digital transformation journey. You might even think you’re headed in the wrong direction!

The report found, for example, that medium performers are actually doing more manual work that low performers in many areas.

What’s occurring is that when teams start their transformation journey they often identify some quick wins, typically by automating some manual tasks. But this then generates new forms of work (e.g. by increasing test requirements), which again must be dealt with manually, giving the illusion that more manual work has been created.

This can occur repeatedly at various levels. You fix one set of problems and a larger, previously hidden, layer of problems emerges.

The same happens in other domains: people who meditate a lot report that, over time, they feel like their head is more full of maddening thoughts than ever. They worry: “Am I just crazier than before?!”. Nope! They are making good progress. What’s happening is that they are simply starting to notice thoughts that were previously well below the level of their awareness.

Similarly, with software delivery, as you improve, organizational awareness is heightened and it can seem like problems are getting worse. Really you are just digging deeper into the muck. Keep going until you hit the gold!

2. Across all elements of high-performance software delivery the common thread is time

Here are some of the key pillars of high-performance software delivery, according to DORA’s research:

• Availability
• Cloud characteristics (on-demand, broad access, elasticity etc.)
• Infrastructure as code
• Cloud-native​
• Containers
• Open source
• Cross-functional teams
• Continuous testing
• Continuous security

The common thread across all of these is the way they help rearrange what developers spend their time doing:

• Are they logging tickets for, and then waiting months for, infrastructure?
• Are they configuring servers manually?
• Are they manually debugging apps that have not been architected properly for the cloud?
• Are they losing time in handovers between siloes?
• Are they performing manual tests?
• Are they waiting for the security team to perform last-minute checks?

Or are they getting all that done either by embedded practices into the software delivery line or using automation and then spending the time saved to deliver actual software?

The ROI of DevOps comes from the time freed up for new work, delivered in small batches at an increased frequency. The new work results in additional features and products, which drive increased revenue.

High- and elite-performing teams spend 20% more time doing new work than their low-performing counterparts. That 20% makes a huge difference over months and years in terms of additional revenue.

Time is money!

3. How do you create time? The right organizational psychology

What’s the best way of ensuring that developers have the time they need? Trust them to do what’s right! The organizational psychology must foster trust and autonomy.

Keep bureaucracy to a minimum and let teams make sensible decisions. Here are the top takeaways:

• Let team decide how to achieve goals that have been commonly agreed
• Keep rules simple
• Allow team to change rules if they are obstacles
• Let team prioritize good outcomes for customers
• Hold blameless retrospectives

The keywords are letting teams “decide”, “change”, “prioritize”. It’s all about trusting teams to find the best routes to achieving customer outcomes and business goals.

4. Outsourcing isn’t good or bad: it depends entirely on how you use it

The report states that “outsourcing by function is rarely adopted by elite performers and hurts performance”. I agree.

But then they dive deeper. Outsourcing can be appropriate if used carefully.

The problem with farming out key functions to third parties arises when you try to cram as many features in a release as possible to reduce costs. This means that valuable features often have to wait for low-value features to be completed. Like a bus that has to wait to be full before it can depart.

But they state that so-called “embedded” contractor models are a different ball game. This is when the “other” teams behave as part of the primary organization’s cross-functional product team. They are side-by-side with your teams on-site and are embedded in the organizational processes.

Under these circumstances you can add crucial skills and capabilities to your teams at short notice and outcomes are “very likely to be maintained”.

Putting It All Together

Let’s summarise. The right right culture will give support your developers to find the time they need to write the code you need. If your missing some key DevOps or cloud skills, get some embedded help from elsewhere. Then when it looks like things are getting worse...don’t panic! This is a sign (possibly) that your are dealing with your problems head-on, rather than sweeping them under the rug.

Keep going!