Just like any other term in IT, DevOps is a term that has got overloaded to mean just about anything. There is the ‘DevOps Engineer’ – the tooling guy, some IT teams are using ‘DevOps Team’ as the title for the erstwhile Production Support or Tier 2 Support group, some others describe “Deployment” teams as DevOps and so on. Its a ‘trendy’ sounding name however my beef with making it a title is that it appears like DevOps is the accountability of some single, defined entity. And that entity should be driving ‘DevOps’ outcomes. DevOps is not a step in an assembly line, it is a mindset. Making it a part of the title hides the essential concept of it being a pervasive culture thing that needs to be absorbed by the entire organization.

Don’t get me wrong, all the automation, establishing of the deployment pipeline, containerization, infrastructure-as-code thing is super! The tooling there done right makes a very mature team that runs like efficient, well-oiled machinery. And more power to the teams that champion that cause, if the title is a feel good for them – go ahead call them that but don’t stop the DevOps adoption in the organization there. (Btw, I also think that tooling should be a given, like setting up your cellphone bill on auto-pay and paperless.) However, there is more to DevOps than the tooling. The definition that stuck with me is – DevOps is whatever you do to deliver business value quicker to your customer. In my understanding, that was the objective behind agile too but somehow agile seemed to have focused on agility in the Business – Development hand-off. The agile processes were about enabling nimbleness to the Business’s needs and developing in short-yet-meaningful increments. It ignored, or to be fair, shortchanged, the Development – Operations agility. That is, enabling nimbleness in the Development – Operations hand-off. DevOps focuses on that agility. Hence it wouldn’t be wrong to define DevOps as Agile extended to beyond the Development all the way to Operations.

So instead of, rather in addition to appointing a team of tooling ninjas, in order to truly facilitate the mindset absorption by the entire organization, it would be good to actually do things that promote the interactions between Development and Operations. Literally break down the cubicle walls between them. Moreover, the simplest things to do is to walk around. For developers to walk around and mingle with the Support and Operations group to get a feel for the real-world issues that they face once code into production. Get into conversations about today’s support request and how they went about addressing it. How the disk ran out of space and went undetected till a customer complained about some broken functionality, how they seem to get more performance issues on certain days, how some data is manually verified while investigating particular issues. All of these conversations point out specific valuable aspects that need to get fixed – a missing unit test, a slow query, an incomplete integration test and so on. And the investment to fix has high-return in terms of both the value of the fix and the culture value through the collaboration. After all, DevOps is a culture thing!

Authored by a “DevOps Evangelist” ;).