In the last quarter of 2015 InfoQ ran a survey on which DevOps practices contribute the most to a healthy DevOps culture, following up on a series of articles on "Patterns of DevOps Culture" (also available as eMag). The goal was to identify which practices stand out, as voted by the community.
Although wide ranging conclusions cannot be extrapolated from 72 participant votes (as of 30th December 2015), there are some interesting results to point out.
The most visible result is that none of the practices reached a consensus among participants. In fact none reached even 10% of all votes: the top-ranked "Including operational requirements in the sprint/backlog" had only 9% of all the dot votes. However, all practices got voted by at least two participants (the least-voted "Infrastructure code review" had 7 votes).
This might not come as a surprise given the lack of a standard definition and/or list of practices for DevOps. The results point to the fact that each organization might require a different set of practices to implement a DevOps culture, depending on their current culture, organization and resistance to change, among other context-specific factors.
If we focus on the top-5 practices (which conquered more than 40% of all votes), we can see the importance given to alignment between Dev and Ops and promoting a shared workflow and goals:
- Including operational requirements in the sprint/backlog
- Having ops engineer(s) embedded in the development/product team
- Shared goals and responsibilities for key metrics
The 2 automation related practices in the top-5 are fundamental enablers of fast delivery and feedback, thus not much of a surprise:
- Automated machine provisioning
- Infrastructure as code
Interestingly, #6 ("Devs monitoring application performance") and #7 ("Devs responsible for application deployments") focus on assigning traditional Ops responsibilities to Dev teams. Besides getting the people closest to the application code and architecture to perform those tasks (thus reducing the handover overhead - and sometimes blame - between Dev and Ops), there are also several side effects from these practices that might help explain why they ranked this high:
- Dev teams better understand the non-functional impact of running their application in a production environment, thus increasing empathy with Ops teams (possibly contributing to practice #1 as well)
- Ops teams are liberated from some of the day-to-day deployment and monitoring tasks, thus freeing time for automating infrastructure and tools which in turn facilitate those tasks
- No need for formal handovers and detailed/brittle documentation as automation becomes the norm and exceptions are handled directly by Dev team
Having these practices in place also means there is at least an explicit intent to break down the "wall of confusion" between dev and ops and the associated ticket culture.
Notice that the list of practices purposely included "conflicting" practices where one stated Devs should be responsible for deployments while another stated a dedicated team would be responsible. The results were clearly in favor of the former as it gathered 3x more votes than the latter option.
Another interesting observation is that both "Devs on-call" and "Devs having root access to production systems" ranked quite low, despite often being quoted as requirements for DevOps. In reality, these two practices might make sense or not, depending on the organization's culture. The results show they are not considered fundamental for establishing a healthy DevOps culture. They might not even be plausible in highly regulated environments.
Finally, as this research was run in parallel with our "Patterns of DevOps Culture" series, it's interesting to notice that none of the practices in the series ranked very high in the results, with "Blameless post-mortems" taking 5% of the votes and "Mentoring other teams' members" reaching 3%.
Which of these practices would you like to see covered in more detail by InfoQ? Let us know in the comments below.