The DevOps Movement: Four Steps to Creating a Culture of Cooperation in Your IT Shop

Despite being 8 years into the DevOps movement, I cannot tell you how often I am asked the question, “What is DevOps?”  In this post, I will explore what DevOps is to me, based on my real world experience building DevOps organizations.

First and foremost, DevOps is a culture.  It is not an organizational construct.  If you’ve waved your magic wand and renamed your “Operations team” as the “DevOps team” and adjusted titles, but have not changed the culture of how development and operations work together, you have not implemented DevOps. Sorry, no DevOps for you!

To understand this culture, let’s explore the traditional divide between development and operations, as well what incentivizes each group.

I come to cloud from a long development background.  I have led many teams throughout my career building various software products.  In almost all cases, I have been embedded with a product management arm of the organization that is constantly evaluating the competitive landscape to determine which features need to go on my roadmap. Once identified and on said roadmap, I was measured on how fast the team(s) could get the features into production.  We could not change the code base by implementing new features or fixing bugs fast enough. In short — change everything!

In one of my last roles, I worked with a counterpart in a more traditional Operations department (it wasn’t called that by the way, but that just highlights that DevOps is a culture, not an organizational construct). The metrics that were used to measure my counterpart’s success were completely different than the metrics used to measure my performance. His metrics were around site availability, number of outages their severity and duration, etc.  In other words he was measured based on stability. And the best way to try to maintain stability … change nothing!

It is this divide that has been responsible for so much pain in many an IT shop over the years. It led to the birth of the DevOps movement – a bonafide strategy designed to tear down this wall of confusion between development and operations.

So how do you go about changing your culture to embrace the DevOps movement?

First, get on the Agile train already.  If you’re not practicing a healthy Agile process, shore up that process, and invest in Agile coaches to help your organization execute Agile well.  It’s really not difficult. Simply embrace the principles, and don’t try to “Frankenstein” the process to work within your environment.  If there are obstacles, remove them.

Second, establish a cross-functional Agile team that includes developers, testers and traditional operations engineers. Get the team in the same planning sessions, stand-ups, demos, and retrospectives. I can tell you that I have seen firsthand how just having these diverse perspectives on the team changes things. In planning sessions, the traditional operations engineer can ask questions like, “How is that going to handle load?  Does it log these conditions?” And so on. Having these perspectives ultimately will influence developers to write better code. This is especially true when you have to look your teammate in the face the next morning after a late night/early morning outage, which resulted from a problem in your code. To raise the stakes, have the developers take a shift in your on-call rotation, so if they put bad code into production, they get the call.  Eventually, you want the lines between traditional operations engineers and developers to be blurred.

Third, build a robust CI/CD pipeline with rigorous quality gates. If you’re doing big bang releases … stop!  It will serve you better to limit your deployments, because traditionally, deployments are big events with a lot of change — and they almost never go perfectly.  In fact most fail — spectacularly.  Here’s why: Even though change isn’t being deployed, code is being changed, and that risk is accruing. All that you have done is deferred the pain until the night you have the full bucket of risk come raining down on you in one big bang release.

Instead, trickle small increments of change into production. This, along with the constant refinement of the CI/CD pipeline and quality gates, dilutes the risk significantly. Asking an engineer to fix a piece of code written six hours ago is a lot more straightforward than fixing a piece of code written six months ago (or longer). In most cases, with smaller increments of change, it becomes possible to “fail forward” by fixing the issue, as opposed to a wholesale rollback of a big bang release.

Fourth, retrospect and refine — let the team be autonomous, and control its own destiny. Have them work together to optimize how they would like to deliver changes safely and responsibly into production. In short, tear down the wall, and give the team a shared purpose. This will help you to foster an environment of cooperation and collaboration. In this way, people are first, and process is second – the essence of what DevOps is, based upon my experiences.

Remember, DevOps is a culture, and culture is best defined when cultivated, and not imposed.  This means the environment must foster collaboration and reward ingenuity – and issues that the team identifies for improvement must be addressed in a manner that is acceptable to both sides of your IT “shop.”

I’m curious of others’ experiences with DevOps, so if you have other observations and suggestions I would love to hear your feedback.