The Accelerate: State of DevOps Report 2019 has just been published. This report is the latest in six years of research. With more than 31,000 survey responses, Accelerate is the longest running study of DevOps in academia or industry.
In the 2019 edition, research continues to show that DevOps drives business value: high performers at DevOps are “twice as likely to meet or exceed their organizational goals.” While this isn’t a new finding, it’s very important that this continues to be true: why invest in improving at DevOps if it doesn’t drive business value?
While there are a ton of valuable insights in the report, in this post I will focus in on the findings which I believe are most relevant to those of us who work “close to a database.” There are three very interesting aspects of the research which hit close to home:
- Speed and stability are not tradeoffs
- Heavy change processes negatively impact speed and stability
- Communities of practice are a common and successful tool to transform culture
Speed and stability enable one another
Accelerate recommends tracking four key metrics, in addition to availability. Note that half of these are related to speed, and half are related to stability:
|Lead time for changes||Deployment frequency||Change failure rate||Time to restore service|
Accelerate explains that the relationship between these metrics is often misunderstood: “Many professionals approach these metrics as representing a set of trade-offs, believing that increasing throughput will negatively impact the reliability of the software delivery process and the availability of services. For six years in a row, however, our research has consistently shown that speed and stability are outcomes that enable each other.” Accelerate: State of DevOps 2019, p17
This is a tricky thing for IT professionals who have been in the field for a while to get our head around.
Another way to put this is that, as Microsoft found, “moving fast with poor quality is as bad as moving slow.” A raw deployment count doesn’t give any indication of delivery of value. If many of those deployments are doing rework and making up for poor quality, that needs to be factored in, because the point is delivering value to customers— hence the importance of stability metrics.
The important thing for IT leaders and data professionals to notice is that the evidence has surely piled up that DevOps techniques are a tool that helps us improve stability: and when it comes to data, that’s typically one of the biggest areas where a company cares a great deal about maintaining quality and stability.
There is a clear action for leadership to take here: moving to DevOps means building a team across development and IT silos, and making the metrics above universal outcomes which the entire team moves towards. You must stop rewarding IT based on stability, and stop rewarding software development based on feature delivery: all groups are working towards the full set of metrics.
Heavy change processes negatively impact speed and stability
IT and database specialists typically act as gatekeepers for production. Traditionally, when things go wrong, heads of IT and their related specialists try to make things better by adding another layer of process to things. This has resulted in complex change approval processes, often including a Change Approval Board.
As much as we like to think that a complex process will make things better by weeding out problematic deployments, Accelerate finds that in our attempt to make things better, we’re actually making it worse:
Accelerate: State of DevOps 2019, pages 50-51
…we investigated whether a more formal approval process was associated with lower change fail rates and we found no evidence to support this hypothesis, consistent with earlier research. We also examined whether introducing more approvals results in a slower process and the release of larger batches less frequently, with an accompanying higher impact on the production system that is likely to be associated with higher levels of risk and thus higher change fail rates. Our hypothesis was supported in the data.
This doesn’t mean that you must get rid of change management. Many organizations simply cannot do that due to regulations, and Accelerate also doesn’t suggest that as the path to success.
But we do need to work towards significantly changing the way that change management and change approvals are done. This includes clarifying change processes to make it incredibly clear to everyone what needs to be done to have a change approved. This also means transforming the jobs of specialists from production gatekeepers into consultants in the software development process: both to build the most effective change process, and to act as peers to review critical changes early in development, and shape the testing strategies for those changes.
Similarly, leadership on Change Approval Boards should shift into more strategic roles, identifying areas where capabilities are needed the most, and providing guidance and resources on how to improve.
Changes like this are not going to happen overnight, particularly in larger enterprises. Perhaps this is part of why Accelerate found this year for the first time that Enterprises, defined as organizations with more than 5,000 employees, comparatively are lower performers than smaller organizations. However, enterprises can change their culture and processes. On a personal note, I am frequently surprised at the massive level of transformation that I’ve observed from my friends who work at Microsoft over the last few years, for example. In an Enterprise situation, the game is about persistence and about seizing promising opportunities to work in new ways.
Communities of practice are a common and successful tool to transform culture
One question I often get from database developers or DBAs is how they can convince developers to change their habits in one way or another. This is sometimes phrased as, “they don’t listen to me.”
Accelerate finds that if you want to change your culture, you’re probably going to need to get out of your silo. They asked respondents to share how DevOps and Agile is spread at their organizations, and that found that “Low performers tend to favor Training Centers (also known as DOJOs) and Centers of Excellence (CoE) — strategies that create more silos and isolated expertise.” Accelerate: State of DevOps 2019, p71
We already have plenty of silos and isolated expertise when it comes to databases, we certainly don’t want to create more.
Instead, tools like Communities of Practice are found to be more effective. 57% of “Elite” performers were found to use Communities of Practice, the heaviest concentration of any single strategy studied.
Communities of Practice build both knowledge and community inside organizations. For IT leadership, it’s critical to encourage specialist groups in your organization to seed and sponsor these groups, and to participate in them as active community members. For specialists such as DBAs, establishing a Community of Practice around database development is your best tool toward transitioning from being a “production gatekeeper” into becoming an internal consultant who shapes how database development is done in your organization — a key contributor and collaborator in the software development lifecycle.
Want more insights?
You can download the Accelerate: State of DevOps Report 2019 today.