Back in episode 10, I briefly mentioned the State of DevOps reports as part of the introduction to DevOps. In this episode I want to spend more time reviewing the 2019 report
Back in episode 10, I briefly mentioned the State of DevOps reports as part of the introduction to DevOps.
In this episode I want to spend more time reviewing the 2019 report
Or listen at:
Published: Tue, 15 Oct 2019 15:53:23 GMT
The State of DevOps report is the result of an annual survey to monitor the trends and success rate of organisations adopting DevOps.
Its been running now for 6 years and has a significant level of statistical rigor in its production.
I'd certainly recommend reading the report (and prior years). I'll provide a link in the show notes.
The report is broken into sections;
The report highlights 6 keys findings;
Since the 2018 report, the "elite performers" have grown from being 7% to 20%. The report presents this as a clear indication that excellence is not only possible, but an anticipated outcome for those following the DevOps mantra.
The survey finds evidence that the speed of delivery is contributing to the organisation.
"Our highest performers are twice as likely to meet or exceed their organisational performance goals."
Note that this talks about organisation goals ... Not IT goals.
This key finding highlights the more successful manner of instilling DevOps in an organisation. Moving it from being a niche pet project to encompassing the entire organisation.
The report compares different approaches on how to achieve that. I'll not cover that section specifically in this podcast due to its complexity.
But if this sounds of interest to you, then review the "How do we transform: What really works" section of the report.
When I introduced the Cloud back in episode 9, I highlighted that it was an enabler. A tool that provides the flexibility needed to provide the outcomes needed to support high performance and availability.
The findings of the report back that up.
You will always receive better Return on your Software Development Investment if your people are engaged and happy.
More than anything else, your people are what are important.
And it may seem surprising, but DevOps helps to provide that.
Your people spend more time making positive change - rather than firefighting or constantly having to play catch up.
That has a really positive affect on an individuals wellbeing.
Approval processes and audit requirements traditionally can have a tendency to be heavy handed in their implementation.
I come back to this later in this podcast.
The demographics of the survey show some interesting points;
48% of respondents said they had over 16 years of experience. A pointer to the considerable depth of experience that is going into the survey.
The industry section shows respondents are in a wide variety of sectors - including those heavily regulated like financial services, government and pharmaceuticals - helping to dispel the myth that Agile & DevOps are not for regulated industries. Financial services are showing as the second largest industry.
Company size is fairly distributed with a good quantity of respondents in small-to-medium business (20 to 3,000 employees) and large enterprise (10,000+). This shows that DevOps is in use across various organisation sizes and not just restricted to the unicorn start up as myth might have you believe.
Rather disappointingly the number of teams that included women this year dropped from previously. IT - especially development - has long tradition of being dominated by white middle aged men. This lack of diversity is an ongoing problem in the industry.
The report's results focus round its definition of Software Delivery and Operations (SDO) performance which is based on 4 aspects:
Deployment Frequency - Respondents where asked how often their organization deploy code to production. They found that their Elite Performers where delivering 208 times more frequently than the low performers. Image what this means for organisational flexibility - rather than deploying once every 6 months, you'd be looking at multiple times per day.
Lead time for changes - Respondents where asked what their lead time for change was - how long did it take to go from developed code to it successfully running in production. Elite Performers where 106 times faster than the low performers. So this is how quickly it takes for code that you have invested developer time on, how quickly you can get that infront of the customer and receiving payback on that investment.
Time to restore service - Respondents where asked how quickly a defect could be fixed or service failure resolved. Elite performers where 2,604 times faster to recover than the low performers. Think what this means to your customer. If something breaks, its a much better relationship story if that is fixed within the hour than having to take up to a month.
Change failure rate - Respondents where asked what percentage of changes to production subsequently required remediation due to service failure, bug, etc). Elite performers has a 7 times lower change failure rate than low performers. Low performers reported that 46-60% of their changes resulted in some form of failure. Elite performers reported between 0 & 15%.
I personally think the report provides some great evidence for why you want to invest in DevOps.
The report then provides considerable guidance on how to use their research models in guiding improvements within your own organisation - roughly half the report.
The report provides two different models - dependant on your desired outcomes:
Within each model, they provide areas and themes to concentrate on. They advise you to focus on those areas that you perceive as currently holding your organisation back, work on that, then iterate - identify constraints and choose the next target.
For example within the Software Delivery & Organisational performance model, one of the areas to address is a culture of psychological safety.
This is a subject I touched on in episode 11 on Culture. The psychological safety has a direct relationship on the organisational performance.
The report goes on to look at some of the technical practices; advising that in many cases the best options will be dependant on the team - and they should be empowered to choose between available options based on their own circumstances.
It talks about Cloud being a major driving factor.
It then talks of technical practices like automated testing, continuous integration and continuous delivery and their reliance on each other to good affect. These are technical practices I will dig into in future episodes.
I've talked about Change Management previously in episode 11 when I talked about Cultural change.
The report discusses it as a specific theme;
It talks about how change management - be it for coordinating activities across teams or for regulatory control - is being improved with DevOps practices.
Regulatory concerns like segregation of duties can be handled through lightweight process or automated checks to ensure that it doesn't exceed given thresholds.
In most cases the automated nature of DevOps is actually providing more confidence than traditional approval processes as everything is automated and tracking - providing an exceptionally high level of auditability.
Their survey looks at the outcomes between the traditional heavyweight change process and more lightweight ones;
They found that those using heavyweight change process where 2.6 times more likely to be in the low performers category.
Their data also supports the hypothesis that heavyweight change controls led to a slower release process, larger batches being released and greater risk of failure.
The heavyweight change control process in place to reduce risk where actually producing the opposite affect - something that has largely been understood to be true in the Agile community for many years.
The report does go into further insights gained by the survey data - too many to dig into in this episode.
I would recommend reading the report. Its a weighty document at 82 pages - but it is well organised.
I would be highly surprised to find an organisation that could not find at least one valuable takeaway from it.
I will continue to reference the document in future episodes as appropriate backup to practices as I introduce them.