If you are a modern IT shop and not doing DevOps, there’s something wrong with you. Okay, that’s not fair: DevOps is not easy to adopt, much less succeed at in terms of transforming your organization into an agile, rapid, business-aligned machine. DevOps is not about having the best change management or IT automation toolset. It’s about people and process. As we all know, old habits can be hard to change. No matter what anyone says about service-oriented IT and breaking down the barriers of old days, IT silos still exist and they’re not going away anytime soon. Yet there is a way to soften the edges of those silos so that DevOps can work to your company’s advantage.
What’s the Point of DevOps, Anyway?
For the business at large, the culture of DevOps ensures that developers and operations people are working together smoothly so that agile development can occur without reams of crappy code that make users cringe. Agile means that developers can issue more releases, more frequently, to keep applications fresh and in line with user requests and with marketplace trends. The quarterly software upgrade is for all intents and purposes, dead. Yet frequent releases introduce complexity and risk. That’s where the Ops team comes into play: to ensure that upgrades work as intended, won’t break the network, won’t break the website and won’t negatively affect user performance. By enabling developers and operations people to work together better, not in silos, the whole company benefits. And, developers and operations engineers usually like DevOps because they can work more efficiently and wear more than one hat. They gain a better understanding of where their role fits into the larger scope of IT, and critically, the larger scope of the business. This makes them more marketable, and more valuable.
Creating the Optimal DevOps Culture
In my experience as a performance engineering consultant prior to working at Boundary, I helped many organizations adopt DevOps through advising them on best practices for the culture and staff. I have seen companies push too hard, too fast in deploying a DevOps practice, and it backfired. If you’re not careful, you’ll risk alienating the very people who are your stars in the equation. IT organizations need buy-in from the top, but also from the bottom. You need the right type of people on your DevOps staff, those whom have an open mind and value viewpoints from many corners of the IT universe. These individuals love a challenge, solving hard problems, and importantly, they know that everything they do relates back to the business and its goals.
Here’s my take on the attributes of a successful DevOps culture:
1. Highly communicative: Members of the team should communicate often and over multiple methods, whether that’s email, chat, text, phone meetings or video calls. The method matters little, but staying in touch and responding quickly to messages is crucial to keep all parties on the same page.
2. Problem-solving culture: DevOps teams are highly proficient at solving problems and know how to prioritize tasks, with the business in mind. This calls for both commitment and tenacity, even during very difficult times.
3. Flexible processes: DevOps was developed to enable a flexible, agile environment. Therefore, team member should also take on those characteristics. The IT project management culture of the last many years is not a good fit for DevOps, because it’s too rigid. Yet the PMO can complement DevOps through providing documentation and back-fill support and resources.
Building the Foundation for DevOps Happiness
Keeping these above attributes in mind, below are a few ideas on how you can ensure a healthy DevOps culture in your business.
Before you begin any project in the DevOps way, it’s important to create buy-in. The CIO or CTO (or other senior IT leader) should lead the message, but don’t forget to include those who are in the trenches. Consider how DevOps can best help the developers and operations managers in their daily jobs. Let’s say that plans are underway for launching a strategic new application, yet the deployment process is already proving noxious. Demonstrate the value of applying a different method, a.k.a DevOps, to the project. While DevOps is not a panacea for all issues, it can be applied to any part of the IT development lifecycle to foster collaboration and higher-quality results. That’s the message you want to convey throughout your organization.
Building the team is next in priority: start internally before bringing in new people to your organization. There’s no better way to alienate the staff than to bring in the army of “experts” before considering the talents of the people who already know your company. Yes, you may still likely need an experienced, external DevOps consultant, but make sure that individual comes in as a guidance counselor, not a dictator.
As covered above, individuals who have demonstrated strong communication skills, creative problem-solving abilities and business orientation are excellent choices for DevOps endeavors. I also like to identify people who are deep experts in a particular area, because it shows the tenacity to learn and dig into a subject.
Qualifying some of these skills is not easy. For instance, a problem solver isn’t strictly someone who has resolved an outage but maybe also tackled an organizational problem. Communications and collaborative skills are even harder to qualify: everyone will say they are adept here, but test them. When I’m interviewing people, I may follow-up with an email, a text and/or a phone call. If the individual takes a few days to respond, that’s a red flag.
A critical attribute of any DevOps team member is the ability and willingness to look outside of their own world. Someone might have extreme database knowledge, but when the network guy comes in with questions, can the database person discuss it from the network perspective? I cannot underestimate the importance of taking on a “world view” of IT if you are a DevOps person.
Once you have your team in place, don’t rush full speed ahead into a DevOps program. As with any major change, start small and pilot projects are perfect for this. Choose a focused project which has visibility, but won’t jeopardize the business if it misses the mark as your first DevOps experiment. An ideal project could be an upgrade, a new customer portal or a piece of infrastructure being rolled out. Make sure your first project has finite boundaries, so you can demonstrate results.
Once you have established your first win-win using DevOps, in which both IT and the business are pleased with outcomes and the process, you’ve got the necessary mindshare to expand the program. Occasionally, I have seen revolutionary changes in organizations where DevOps is adopted quickly and spreads like wildfire. Yet that is rare. Typically, DevOps involves creating slow and steady cultural shifts in your organization. With an enthusiastic team, a measure of flexibility and a patient respect for the process, DevOps can be successful in most any organization.
Michael Butt is Director of Products at Boundary.
