DevOps isn’t the latest developer fad or programming trend, it’s essential to delivering superior products and services in a safe, effective and timely manner. Investing in DevOps is no longer an option given the frequent changes in customer needs, technology and security challenges.
Last summer, DORA released it’s comprehensive study on what are the common characteristics of organizations that have successfully adopted DevOps principles versus those that haven’t. The research is based upon 6 years of data from more than 31,000 professionals and was led by Google Cloud’s Nicole Forsgren. You can read the entire report here. You can also read Ivan Krnic’s summary of the State of DevOps Report on dev.to here.
While Ivan focuses on the recommendation that organizations adopt “Communities of Practice” method of adapting and improving DevOps, I am going to highlight some of the other recommendations.
1. The better an organization used the cloud, the more likely it accurately predicted software costs. (page 37)
Because it’s relatively easy to scale and control, organizations that reported using the cloud more effectively were 2.6 times more likely to accurately predict the cost of operating software. They were also 1.65 times more likely to stay under budget. Taking full advantage of the cloud’s elasticity and monitoring was much more important to an organization’s success than whether the cloud was public, private or a hybrid.
The cloud’s standard “pay for only what you use” model also encourages efficient coding. Investing in traditional server infrastructure and its fixed costs makes it less likely organizations will focus on efficiency.
2. A culture that encourages learning and improvement over blame significantly increases productivity. (pages 28 and 53)
If you’ve never failed, you’re probably not trying to do anything worthwhile. The DORA report found strong evidence that the best performing teams encouraged trust, risk-sharing, creativity and information sharing. Focus on fixing the system that led to failure, not an individual's mistakes. This isn’t about avoiding accountability, it’s about fostering an environment of psychological security so that your skilled employees are more productive.
3. External code reviews does NOT reduce risk. (pages 50 to 52)
A change process that requires approval from an external team was 2.6 times more likely to be among the worst performing organizations in the report. There is no evidence that a slower, heavyweight change process lowers risk. In fact, data tended to support the hypothesis that deploying larger batches of codes less frequently led to more failures, not less.
Instead, the findings suggest organization’s adopt a clear lightweight change approval process that relies on peer-reviewed code during the development process and automated testing. Automated tools were able to detect problems earlier in the development process than formal reviews. Respondents to the survey that had a clear understanding of the change process were 1.8 times more likely to be among the best performing organizations in the report.
4. The lowest performing organizations were the most likely to use proprietary tools. (pages 59 and 60)
Everyone knows investing in automated testing and deployment tools are fundamental to improving DevOps. But the reports findings suggest developing proprietary tools can be counterproductive. The report also found the best performing respondents were the more likely to use open source tools and planned to use more. Finding and contributing to the communities around commonly used tools helped developers feel more productive. (page 63)
5. Feeling productive reduces burnout. (pages 68)
It may be obvious, but it’s another reason to invest in DevOps: the more productive your engineers feel, the less likely they are to burnout. Burnout isn’t just being tired, it’s a recognized medical condition that can wreck an otherwise valuable employee’s ability to contribute. The less automated testing, self-guided learning and peer-driven review your organization supports, the more likely your skilled employees are going to have their time wasted, leading to frustration.
We noticed that ourselves at Gennovacap when working with an AI company. It wasn’t just that their cloud architecture didn’t allow for easy scaling, but deployments were crashing - and what is more frustrating than that? Our team of AWS DevOps engineers didn’t dramatically lower their AWS billing using Spot instances, but provide a stable development environment for their engineers.
Want to learn more about the 2019 Accelerate State of DevOps Report, but don’t want to read the 82 pages yourself? Then we recommend listening to the Arrested Devops podcast, where hosts Matty Stratton and Jessica Kerr talk with the report’s main author Nicole Fosgren and Jez Humble.
Top comments (0)