10 Ways To Win At DevOps: What IT Pros Need To Know
DevOps can lead to greater developer productivity, higher operational efficiency, and improved user experience. But the journey toward DevOps is not easy. Here are 10 ideas to get you started on the right path.
Let's talk about DevOps. Actually, let's start by defining "DevOps." According to Gartner:
DevOps represents a change in IT culture, focusing on rapid IT service delivery through the adoption of agile, lean practices in the context of a system-oriented approach. DevOps emphasizes people (and culture), and seeks to improve collaboration between operations and development teams. DevOps implementations utilize technology -- especially automation tools that can leverage an increasingly programmable and dynamic infrastructure from a life cycle perspective.
DevOps can be an enormous win for an organization, with benefits that include greater developer productivity, higher operational efficiency, and improved user experience due to continuous feedback. With all the benefits, no one ever said that DevOps is easy.
That doesn't mean it's not worth doing, of course -- but there are definitely some things you should keep in mind if you want to make DevOps worth the effort to your company. We've recently looked at 8 Ways to Fail at DevOps, but now let's look at the topic from the other direction.
As you go through the 10 tips in this list, you'll notice three big themes. First, DevOps is complicated. Really complicated. And it involves an awful lot of people and departments.
Next, those people are vitally important to getting DevOps right. You can write up and implement the best business processes in the history of business, but if you can't convince your employees to enthusiastically participate in those processes, you won't succeed.
[See 8 DevOps Lessons IT Can Teach the Enterprise.]
Finally, those systems and business processes are critical. Just as processes without people will fail, great people working heroically to slog through awful processes will never hit the level of success they should. Everything has to work together.
Devops began in the specialized realm of cloud service providers, but Gartner has predicted that 25% of the Global 2,000 will be using DevOps by the end of 2016. No matter how you define the term, it's obvious that its use will grow for the foreseeable future.
Many of the ideas presented here will strike you as common sense, but we've all been around long enough to know just how rare a commodity common sense can be. To come up with the list, I looked at blog posts and web articles, talked to managers and executives, and drew on our own experience.
Take a look at the ideas here and let me know whether you think we've gotten it right or missed some key suggestions. The comments are open and ready for your thoughts. I'll see you there.
When something involves as many functions, processes, and people as DevOps, it's just not realistic for it to be successful as a grassroots effort. Sure, developers and operations staff can begin to work together, but for DevOps to be effectively implemented, it needs support from the top -- generally, from the very top.
Getting executive buy-in for DevOps requires homework, economic justification, and effective communication. Build your case, rehearse your pitch, and be sure the C-suite is in your corner if you want to bring DevOps to your organization.
DevOps, by definition, crosses functional lines. That's why it's so important to build a team of early adopters and champions for the idea -- a team that includes members from every business function affected by the shift to DevOps.
Yes, I wrote that it's critical to have executive support for DevOps, but it's also vital that employees seeing their jobs turned upside down have colleagues they can turn to for advice and support. That's where the initial team comes in. Choose the members carefully. You want it filled with people who have the respect of their teammates, who are effective communicators, and who are enthusiastic about the move. Yay, team!
Whenever there's a large change like DevOps going on, you'll find some people in management who counsel that the best way forward is to clean house, shoving anyone who resists or who is slow to adopt out an airlock and replacing them with new employees who already love DevOps. That might be a short-term solution, but in the long run it's a great way to make everyone who remains resent both DevOps and the people who were its champions.
Embracing a huge change, like the move to DevOps, is the perfect opportunity to invest in your staff members. You can make sure they're properly trained in DevOps methods and discipline, and upgrade their job skills in the process. Tie the DevOps move to good career development and investment in personnel and you'll find yourself with a staff of DevOps enthusiasts, rather than a team that has to be dragged along.
We've been talking about people so far, but the people must work within systems. It's those systems that ultimately must change if you're going to implement DevOps. The good news is that changing systems to implement DevOps gives you the opportunity to get rid of wasteful processes, streamline inefficiencies, and bring IT systems into alignment with business needs. If you use the DevOps move to clean up and rationalize systems and processes, you increase the chance that the new way of doing things will be seen as a success rather than simply a bow to business fashion.
Once you've committed to new systems of operation, you need to back them up with new tools that work across all the business units and staff members who will be involved with DevOps. Here's where it can get tricky. It's quite likely that careful study will show that far more business functions are involved in DevOps than you first thought.
As you're building (or buying) tools for DevOps, make sure that every unit involved is included in the tool rollout. The worst thing to do in a DevOps launch is to leave out critical functions. Doing so means back-filling both software roll-out and political strategy when the mistake is realized. Cast the widest net you can with your tools and you'll end up happier and more successful.
Feedback is a critical part of both agile and DevOps. The problem comes when feedback is seen as a one-way street rather than a virtuous circle. Make sure that everyone knows that feedback is 360 degrees -- and that they know it from the beginning. When feedback happens in one direction only, it tends to lead to more resentment and resistance than improvement and collegiality.
Oh, yes, and while you're at it, make sure you provide coaching on the way the feedback should be given. If necessary, invest in an outside coach to come in and explain to everyone what productive feedback looks and feels like so they know both what to do and what to avoid. Professionals look forward to honest, productive feedback. No one looks forward to a personal, hurtful, gripe session.
We know that DevOps and agile aren't the same thing, but agile development is often part of a DevOps deployment. That means questions about what kind of agile processes to put in place are appropriate. There are really more of those questions than you might think. In particular, you might want to take a careful look at kanban, especially when you're talking about the operational side of the DevOps equation.
Where scrum is optimized for building intellectual property like software, kanban comes from the world of physical product delivery. It's possible you'll want to look at moving your entire DevOps process to a kanban basis. It's also possible that the dev side will stick with scrum while the operations teams move to kanban. Either way, the DevOps implementation is a great opportunity to review total operations without prejudice and choose the discipline that works best for your organization.
DevOps can become incredibly complicated, because it can involve so very many people, processes, and bits of technology. There really is a hard limit to how simple the entire DevOps process can be and still be effective. Within DevOps, though, there are many different processes that can be ruthlessly simplified.
Precisely what those processes are will be unique to each organization. Examples of what can be done, though, include simplifying the process of feedback by making feedback continuous and simplifying deployment through careful use of automation. Your opportunities for simplification will be uniquely your own, but simplification is exactly what you should do if you want to give your teams the greatest opportunity for success.
As part of the DevOps process you should have team members pick apart every process and every function, and then make each as simple as possible (but no simpler). Then, in each implementation step, the process should be broken into its atomic elements and created one piece at a time. Going through a huge process like the move to DevOps and trying to do it all at once is a great way to end up frustrated and failing. It's that simple.
You don't have to subscribe to the "what can't be measured can't be managed" philosophy to understand that a change as radical as the move to DevOps must show results if it's going to be considered a successful investment of the organization's time and resources. It stands to reason, then, that you must come up with a way to measure your progress along the way if you want to have a chance at convincing executives that they've made the right decision in moving to DevOps.
Perhaps just as important, you'll need these results to show the employees who have resisted DevOps that the move has been worthwhile. Make sure that you're measuring things that are meaningful, and you'll have a solid idea of your progress at every simplified step of implementation.
Follow me, here. When you're implementing something as complex as DevOps, it's almost impossible to plan everything perfectly. Some degree of experimentation will be required, and a great deal of buy-in from the staff is necessary if the end result is going to be something that everyone in the organization considers a success.
You can make great strides toward all of this by empowering employees to work with you, to take ownership of processes, and to try new things if they think it will make the DevOps process better. If you've followed the advice in the last point, you'll be able to measure the success of the experiments. Then you'll be able to accept or reject them based on results, rather than politics.
Speaking of politics, if you want to encourage ownership and experimentation, you must get away from the idea that an unsuccessful result means that someone is going to be sanctioned. In an experiment, a negative result is still a result that provides valuable information. Internalize that approach, and you'll improve more than DevOps in your company.
There they are, 10 ways to win at DevOps. How many of these are you incorporated? How many do you wish your organization had incorporated? I'd like to know. Give me some feedback in the comments.
Follow me, here. When you're implementing something as complex as DevOps, it's almost impossible to plan everything perfectly. Some degree of experimentation will be required, and a great deal of buy-in from the staff is necessary if the end result is going to be something that everyone in the organization considers a success.
You can make great strides toward all of this by empowering employees to work with you, to take ownership of processes, and to try new things if they think it will make the DevOps process better. If you've followed the advice in the last point, you'll be able to measure the success of the experiments. Then you'll be able to accept or reject them based on results, rather than politics.
Speaking of politics, if you want to encourage ownership and experimentation, you must get away from the idea that an unsuccessful result means that someone is going to be sanctioned. In an experiment, a negative result is still a result that provides valuable information. Internalize that approach, and you'll improve more than DevOps in your company.
There they are, 10 ways to win at DevOps. How many of these are you incorporated? How many do you wish your organization had incorporated? I'd like to know. Give me some feedback in the comments.
-
About the Author(s)
You May Also Like