I've worked at a number of interesting companies over the years and as regular readers of my blog will know, I have developed my own opinions of what DevOps is and how to do it right.
Surveying thousands of job posts with "DevOps" in the title, it struck me that few, if any, spoke about culture. Job posts for release engineers, automation engineers, systems administrators, even software engineers and developers are all commonly prepended with DevOps. These posts call for skills that have existed years before the term DevOps was coined, so what makes them DevOps?
This got me thinking about some of the difficulties I have encountered in trying to bring DevOps and more generally agile concepts into companies large and small. The problems I encountered were never around tools but culture. Sure, there maybe issues to address such as tool adoption, the use of pull requests to help collaboration, Kanban boards and so on but that was never the source of the problems.
I've seen various approaches, embedded DevOps, DevOps teams, transformations of existing teams and in all cases the cultural aspect of DevOps is a much bigger issue than the tools. Why is this?
At DevOps Days Boston there was an excellent speech by Katie Rose titled GridIronOps: What Women's Tackle Football Can Teach Us About Competitive Software. In the course of this unique and lively presentation of the cultural challenges in DevOps, Katie made the point that one similarity between DevOps and women's football is that we are trying to change the culture of adults. Young boys learn the collaborative required for successful team work at early age but these are grown women taking up the sport as adults.
This comparison left a powerful impression on me. Coming into a company to "implement DevOps" inevitable meets with cultural resistance. If you build a separate DevOps team it is immediately perceived as a challenge to other teams that existed before you got there. If you start merging operations people with development teams then you are bringing together what are, more likely than not, conflicting ways of working. If you are a development manager seeking to take on automation and configuration management, there is the danger that you will be seen as a threat by the operations team. If you are an operations team trying to encourage developers to take on their own deployments you run the risk of being seen as trying to pass off responsibilities. All of some of theses problems will arise in the course of trying to implement DevOps.
So, to get back to the title of this post, why did I create DevOps Advocates and what is it? Thinking about how to avoid some of the problems cited above, I was reminded of the early days of agile and the concept of agile coaching. Companies that were most successful with agile often hired outside consultants to come in and review existing workflows. These consultants would then work with the teams to figure out where agile would fit within the business. What were they doing right? and wrong?
The use of a third party avoided the defensiveness one often sees in trying to move a company over to a DevOps culture and practice. The agile coach was seen as an independent voice who's only agenda was to improve process and make a company more successful. So I decided there is a need for DevOps coaching along the same lines as the Agile coaching of an early age.
I am seeking out consulting gigs from companies who need more than tools. Lots of companies have intelligent people who, with a little nudge, can become excellent advocates and practitioners of DevOps. The companies I am interested in are those willing to have an independent assessment of where they are currently on their DevOps journey and where they need to get. Initial conversations at DevOps Days and other meetups tell me there is a demand for what I am pitching. It's early days so only time will tell if I am right but it would be stupid not to give it a try.
For more information or to get in touch visit http://devopsadvocates.com/.
