BT
x Share your thoughts on trends and content!

Research Insights: No Silver Bullets for DevOps Culture

by Manuel Pais on Dec 31, 2015 |

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.

Results Table

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.

Rate this Article

Relevance
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Discuss
General Feedback
Bugs
Advertising
Editorial
Marketing
InfoQ.com and all content copyright © 2006-2016 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT

We notice you're using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.