Cloud Zone is brought to you in partnership with:

Passionate about technology and startups. Have worked for the BBC in London, in Japan, Cloudera in San Francisco and MailChannels in Vancouver, Canada. Currently reside in Vancouver where I'm working on building PaaS based on Cloud Foundry, called Stackato. I enjoy writing about technology, especially when it relates to interesting startups. Phil is a DZone MVB and is not an employee of DZone and has posted 53 posts at DZone. You can read more from them at their website. View Full User Profile

5 Common Barriers When Introducing DevOps

  • submit to reddit

[This article was originally written by Ho Ming Li.]

In my talk at Silicon Valley DevOpsDays last week, I wanted to bring about awareness, discuss some of the lessons learned, and offer some thoughts and tips about bringing DevOps to an organization. I've listed below five common barriers and ways to overcome them.

But first, why DevOps? Why should a company take on this approach? While we could write a book (and others have) answering this question, ultimately people want to do things better, faster, smarter and realize that this can be done by implementing a DevOps culture. DevOps will translate into developer self-service, greater agility and increased collaboration between Dev and Ops. Panacea!

DevOps: Tools and People

Introducing the concept of DevOps to an organization has always been difficult. Many would choose to approach it by bringing in relevant tools to ease the transition to becoming more "DevOpsy". For example, let’s start with Vagrant for local development, put together some Chef recipes for configuration management, leverage Jenkins for continuous integration, and of course continuously deploy to a PaaS like Cloud Foundry or Stackato. Sounds like a great software development flow.

However, from experience with prior customers, tools are often neither the problem nor the solution when introducing DevOps. While these tools are pivotal in accelerating the lifecycle and providing the self-service, agility and collaboration that organizations need to implement a DevOps culture, the challenge is really around people’s willingness to adopt DevOps as the culture going forward.

Take Agile for example. Agile tools don’t make a company Agile. Rather, companies become Agile because they put into practice the philosophy behind Agile. They thoroughly understand what it means to be Agile, and can envision the benefits and gains that will stem from being Agile. Until this happens, a company is not Agile just because they use the tools.

Tools contribute to making life easier and supporting a DevOps culture. But just using the tools alone won't help implement DevOps.

Because DevOps is a cultural shift and not a technology shift, people (human behaviours) are the biggest barriers to introducing DevOps in your organization.

Barrier #1: People Who Do Not See the Light

You will hear things like "What is DevOps anyway?"..."Why do we need DevOps?"...or even "We don't need it". All are typical questions and phrases that people say when the talk of DevOps comes up.

Roadblocks like these are common with any change and really the only answer is… educate, educate, educate. We need to talk it through and look at what others are doing. It takes time for people to see the light and it may seem like it's taking forever for people to get what's obvious to you. Remember, you were probably there at one point too. It's important to frame DevOps in ways that people can see how it benefits them. You need to sell DevOps.

Barrier #2: If It Ain’t Broke, Don’t Fix It

Of course you'll also hear comments about the change being "too troublesome" and the desire for people to "stick to the status quo" or "stay with what we have". If it isn't broken, we don't need to fix it. While things are functioning, can they be better? If you don’t change and make progress, you will definitely be left behind.

Change isn't easy, but someone has to be the change agent. You need to be that superhero ready to move a company forward despite the obstacles. (By the way, being a superhero isn't easy.) The one to rally the troops and help things progress. Companies need to instill a culture that encourages change. Fostering innovation can only be done by establishing a culture that accepts and rewards new ideas.

Barrier #3: Dude, that's my job!

5 Common Barriers When Introducing DevOps Quote

With change comes uncertainty. Sometimes people like to keep doing what they do, even if it's more manual and an automated solution exists. The idea of automation causes people to become concerned–they feel they won't have the same job responsibilities or they cannot keep doing what they do, and this leads to a feeling of weaker job security.

In this situation, once we can identify that a member of the team is afraid of losing their job, the most important action is to communicate with them that their job will not be lost after automation. Let them understand that the main goal is to free up some of their time, to make their life easier, such that they can move on to do other fun things at work.

Automation means you can have more time to do other things and be more productive in your job. It doesn't mean it will be eliminated.

Barrier #4: The Great Divide

5 Common Barriers When Introducing DevOps

While hate may be a strong word… developers hate ops and ops hate dev. Or so it seems. Part of this great divide is that there isn't an alignment between these two groups. Without this, both groups can't move forward.

This meme reflects the general antagonism that can exist between the two groups. To overcome this barrier, there is a need to bridge the gap by each group learning what the other does. Developers need to learn ops, and at the same time, ops can learn the challenges of being developers. Marry the two, and like all marriages, it is necessary to understand each other.

Barrier #5: One vs. the Rest

One person gets it. Awesome! But the rest of the team doesn't… and the rest of the company doesn't. Sometimes it is one versus the rest. Being the lone person advocating for change is never easy, but you can overcome this barrier by identifying and empowering those who get it.

As an agent of change, you can't be afraid to evangelize and spread the word internally. Whether it's lunch and learns, group discussions or mailing lists, it's vital that you get out there and bring the rest of the people over to the good side.


The methods of overcoming these barriers have a common theme… learn, understand and communicate. Learn what it means to be DevOps, understand it intimately, and then evangelize it to everyone--members of all levels, from users to managers to executives (and really anyone who will listen). Ultimately, DevOps is a mindset and culture, and we need to think about the people, not just the tools. Embrace DevOps from the people angle and help implement the change in your organization.

Image courtesy of Tim Pierce

- See more at:
Published at DZone with permission of Phil Whelan, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Serguei Meerkat replied on Sat, 2014/07/05 - 4:20pm

As a developer I am used to design software using single responsibility principle.

I have learnt to concentrate on one problem at a time.

Now it seems like a developer is supposed to do everything. He does planning (something managers used to do), he does testing (there used to be QA for that) and the latest trend - do Ops as well.

Developers probably don't earn enough so that it is OK to make them to do the jobs that other people can do better then them...

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.