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!
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
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.
|This blog post was originally published by Ho Ming Li on July 1, 2014 at ActiveState blog.|