Is DevOps a People Problem And a Technical One?
Is DevOps a People Problem AND a Technical Problem??
originally posted MAR 11, 2015
Over the past few years, I’ve become more familiar with the works of Jerry Weinberg. One of his best is a book called Secrets of Consulting, which I highly recommend to all those who give advice for a living. Among the many rules and secrets that he shares, there are two that stand out time and again:
There’s always a problem. If they’re bringing a consultant in, there’s a problem to solve, even if they don’t really know what that problem is.
It’s always a people problem. Even in the most highly technical of scenarios, at the end of the day there’s a people issue at the root of it.
Now I don’t want to be one to quibble, but I believe that DevOps is that unusual scenario where getting good at it is both a technical and people problem. Let’s take a look at what that really means.
The Technical Problem
When we look at the practices that are so important for DevOps, we see a lot of technical solutions. These practices enable DevOps to run smoothly and efficiently and make a huge difference in the success of an IT organization. Many of them require a high level of technical sophistication as well as discipline, to achieve. What are they? Most of these practices are well understood as the foundation of DevOps. Items like Continuous integration have been around a very long time, and require a CI server as well as the concurrent automated Unit and Acceptance Tests to make Continuous Integration worthwhile. This also requires a tight integration with the version control system, so that everything can be under version control. All artifacts of delivery need versioning to truly be successful and, dare I say it, safe in a Continuous Delivery environment, which is of course the logical conclusion of a DevOps approach.
But wait, there’s more
So yes, there are technical practices that are required to truly “do” DevOps. But in order to do those practices, we need people. Bringing operations into the Team Room requires a mindset and a willingness to change that can be very difficult to engender. I’m not just referring to the difficult things like learning to automate and *choosing* to automate all Acceptance Tests, but also simple things like remembering to include monitoring items in all of your stories.
This is a big shift in thinking. Development teams are used to finishing something, handing off to operations, and moving on to the next thing. They don’t want to be bothered with something in production unless there is a bug, which they will often see as an inconvenience. Building a culture that goes beyond deployment, but treats development and operations as a single, holistic entity takes a lot of support and willingness on the part of everyone.
Sometimes it’s just about language. We need to start asking different, or more, questions during our analysis of stories. Instead of asking if a particular test should be automated, ask instead “how will we automate this one?” Including automated deployment and monitoring in our definition of done, or at least in the tasks we identify, will take us very far in the culture of DevOps. This brings the whole cross-functional team into a world where the success or failure of a story doesn’t stop at the Sprint end. Getting our team members to all take that to heart, and looking for the operational aspects of a story is hard, and requires patience and nurturing. For that matter, so is getting the team into the mindset that automating tests is not optional, but required to ride this ride. This also takes patience and nurturing.
Darn it, Jerry Weinberg is right again! It really is a People Problem!
