I was recently looking at a ranking of the top initiatives from IT organizations in two major states of the U.S., namely Texas and California, where many large companies host their IT headquarters, and it called my attention—though I have to admit that it didn’t surprise me—that DevOps is part of the statistic. This is something that we all could have foreseen with this movement that was started a few years ago, and that last year had a momentum such that the industry probably hadn’t seen since ITIL’s rage back in 2011.

The first question that comes to my mind is: Why is “everybody” focusing on DevOps now? I like to think of DevOps as bullying—it has always existed in practice (I mean, the need of Developement working in tight collaboration with Operations is not new!), but no one named it before, therefore no one talked about it. Suddenly someone appeared and gave it a name, and it got everybody’s attention. (Don’t get me wrong; I don’t mean that companies shouldn’t be focusing on it. All I say is they should have always addressed the issues that DevOps addresses.)

The Silent Enemy that DevOps will Encounter

But anyway, it is what it is, as they say, and DevOps is a trend in the IT industry. What is really interesting is what is behind this fact. If so many companies are adopting DevOps, that means all of them have issues in common that they are expecting to solve with a DevOps implementation, even if from different perspectives (automation, collaboration, communication, etc.).

The black fact is that in many cases, DevOps is perceived as the magic wand that will solve these issues that have always existed, and that have just lately become more evident with the current and continually growing demands from the business and the market, where IT has to be more agile than ever before. DevOps by itself (as a movement) looks very promising, but it’s like a boxer training with a sparring instead of a real fighter. When taking DevOps to practice, after the initial stages where everybody is motivated and cooperating with the initiative, IT organizations will face their oldest and worst enemy that has caused many other initiatives—if not to fail—to limit the value obtained from them: resistance to change from the majority of people in the organization.

Of course DevOps foresees this, and provides some advice to overcome it, but will this be enough? Could there be like a general formula for every organization to get over change resistance? I don’t think so. Every organization is different, and the specific challenges faced will widely vary from one to another.

Enforcing the New Approach instead of Instigating it

Perhaps the best place for companies to start is admitting that people just don’t like to change, and that you cannot just expect all of them to embrace change (of course there will be champions who will influence and convince others, but still a high percentage of the stakeholders will resist the new approaches).

So what are the options then? What about the organization’s authority? What about the policies, guidelines and rules that exist in a company? Those seem to have lost power over the last few decades trying not to offend certain behaviors or practices from employees, which is ok, but still should be used properly.

The key for organizations to succeed with DevOps (and practically with any new initiative) is enforcing it. Doing awareness and training, managing change, and sustaining improvements are key as well, but if there’s no enforcement, the momentum will be eventually lost, and all the progress made will be lost too.

Enforcing an initiative means not making it optional; it has to become part of what people naturally do. You cannot just ask an employee not to disrespect other people in the organization; there are some social rules that we all know we must follow. Why shouldn’t automation, collaboration and communication be something like respect? Why do we have to convince others to work as a team, when it should come out naturally as a result of enforcement?

Responsibility: The Beginning of Everything

This is where top management comes into place, defining an IT Governance Framework that takes these aspects into consideration. Enforcement comes from the top, therefore it is Top Management that first needs to be committed to the DevOps implementation in order to enforce it properly. Top Management will set guidelines and rules for everything they feel responsible for, but if there’s no sense of ownership for an initiative, well, go figure how you will tell others they must embrace it.

If all these companies adopting DevOps want it to succeed and deliver actual value instead of being a waste of time, they better start working from the top, building an IT Governance System that embeds the new approaches into business-as-usual practices and that doesn’t give anybody the alternative of not embracing the change. Only then will they ensure that DevOps is indeed adopted, whether stakeholders believe in it or not.