![Run [X] profile image](https://media2.dev.to/dynamic/image/width=50,height=50,fit=cover,gravity=auto,format=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Forganization%2Fprofile_image%2F4409%2F76a189d4-f217-4a32-a966-9a212ca26023.png){kind=small}
Image by Kharnagy, shared via CC Attribution-ShareAlike 4.0 International License.
The Puppet 2021 State of Devops Report highlights that DevOps is now cemented as standard industry practice, whereas previously it had been the product of a “vibrant, enthusiastic,
and productive community, vigorously debating and sharing methodologies.” DevOps becoming an institution is in some ways a great thing, but it also makes it important for teams attempting to incorporate DevOps practices to remember that DevOps is not (or at least not just) automation.
As the report highlights: plenty of teams and companies use a high level of automation but are still not achieving the goal of DevOps, which is continuous production. The 2021 report points out that a highly evolved DevOps team using automation can roll out new software changes in under an hour with a very low failure rate. Meanwhile, miid-evolution teams, which often report a high level of automation, are lagging significantly behind that, rolling out changes in days or weeks. So why might two highly-automated teams differ so widely in terms of their ability to deploy?
The answer is culture. A highly-evolved DevOps team isn’t just about automating processes; it’s about eliminating production roadblocks. Automating processes without making changes to how your teams communicate is just moving the roadblocks around.
A key first step to truly effective DevOps is to synchronize development and operations teams--teams that in traditional tech culture are siloed--and in fact, often at odds. Forte Group points out that that typically, development teams are incentivized to push things forward (get their deliverables in on time) and quality assurance teams and system administrators are incentivized to minimize disruptions (which often means pushing back deadlines to focus on a quality product). In order to create a culture where continuous development is possible, these teams have to think of their work as sharing an objective. Additionally, they need to communicate frequently and effectively.
DevOps also requires a shift from one big deliverable at the end of a long development period to small, incremental deployments that happen regularly and are constantly being monitored and adjusted. The principle of CI/CD, requires a big shift in company culture. While automation is a part of CI/CD (especially if continuous deployment is also part of your structure), the principle that allows CI/CD to succeed is the ability to make mistakes. Expecting a certain amount of failure and building in a margin of error represents a big change from trying to put out a perfect product and then assigning blame when the product inevitably isn’t as perfect as anticipated. This model of releasing things as long as they are within an exceptional margin of error, and testing them in the field, can be emotionally challenging. If it’s going to work, teams and managers have to get good at not punishing each other for the inevitable failures that are part of this iterative process.
These changes can be a big shift for a company that typically operates on a more traditional model. Gartner, Inc states that it can be best to introduce the principles of DevOps to a few select teams first, to allow them to model behavior for the rest of the company later. They state that leaders should “focus their efforts on an initial, small [DevOps] team, establish the values and behaviors needed, and take incremental efforts to recognize and reinforce desired outcomes prior to scaling." This prevents a situation in which a CEO imposes DevOps principles on a whole company from the top down without taking the time to see how DevOps mixes into the existing company culture. Changing incentives and manager behavior takes time even if everyone on the actual team is onboard, and having one success story can be a selling point for adopting the principles company-wide.
So: if your CEO is expecting a pivot to DevOps without laying out a clear plan for how incentives and communication are expected to change, it’s likely that your company will be in the majority that won’t get the benefits of rolling out DevOps correctly--faster delivery, acceptable margins of error, efficient use of automation, and strong collaboration. Any company that’s going to get to “highly evolved” DevOps is going to need to examine what they reward and penalize, and how teams talk to one another.
Top comments (3)
Every time I mention that DevOps is a culture I get people moving the conversation in another direction. Sigh... If everyone understood this, every engineering team would 100x their productivity and customers would be much happier
Really dumb question, but could you pls define DevOps for me?
Great question: DevOps, like Agile, is a design goal for an organization or team. It's a set of practices that combines software development and IT operations. It aims to shorten the systems development life cycle and provide continuous delivery with high software quality.
Pretty good writeup here: newrelic.com/devops/what-is-devops