8 Ways To Fail At DevOps
There are plenty of places in the DevOps process where an organization can run aground on rocky shoals of woe. Here, we highlight eight points of DevOps failure. Hint: None of these involve technology.
![](https://eu-images.contentstack.com/v3/assets/blt69509c9116440be8/blt138b752012c623ca/64cb3e84fdb0a717784e6cd2/Image_1.jpg?width=700&auto=webp&quality=80&disable=upscale)
When you hear DevOps proponents talking about their operational system, it can seem so perfect it's easy to envision that the path from wherever you are to DevOps could only be strewn with rose petals. Then you start working on bringing DevOps to your organization and reality sets in.
DevOps is a heroic and often successful attempt to link development and operations teams to make each side responsive to the other, and use automation to make the process of deploying software repeatable and less error-prone. There are plenty of places in the process where an organization can run aground on rocky shoals of woe.
In talking with executives, and reviewing articles and blog posts recounting tales of DevOps transitions, a few stumbling blocks began to appear on a consistent basis. This list is based on all of those encounters, leavened with a healthy pinch of my own experience managing development and management teams.
As we look into each of these pitfalls, three broad themes emerge:
Culture
Procedure
Communication
As you look at each of the eight points of failure we spotlight here, you'll find they fit into (at least) one of these broad themes. Notice that technology is not one of the themes.
Even though automation is a requisite part of DevOps, the tools will work out. Barring the most bizarre circumstances, tools won't sink a DevOps transition unless the project is already in serious trouble.
Once you've reviewed our eight ways to fail at DevOps, tell us about your own experiences. Have you seen other challenges that derailed a move to DevOps? Have you encountered a sinkhole so big it makes you reluctant to even try DevOps?
Let's talk about the pitfalls -- and how to overcome them -- in the comments section below. I'll look forward to seeing you there.
Yes, a key part of DevOps is automating software distribution. Yes, for some people, the move to automation is a critical part of their transition to DevOps. But, if automating distribution is all you do, then you're going to have trouble making it all the way to real DevOps.
Automation alone will still leave communications and process chasms between development and operations teams. Make automation part of DevOps -- not the entirety of your DevOps plan -- and you'll be much farther along the path to success.
When you're putting together the list of functions and departments to include in DevOps planning, it's easy to keep a laser focus on groups inside development and in the operational side of the data center. That's understandable from a "let's keep the scope reasonable" standpoint. But such laser focus can come back to burn a hole through your carefully created plans when it comes time for compliance auditing.
By now, we should all have learned critical lessons about compliance. Chief among these is to never assume something we build is going to be compliant simply because it has worked for someone in another organization.
It's far better to get your compliance and auditing groups involved early. Ask questions about whether they've seen this sort of process and this kind of technology. Ask the compliance folks about red flags they see. Ask the auditors whether something you're planning will get in the way of a successful audit. By doing so, you'll find a verdict of success is much easier to come by in the end.
When you start down the DevOps path, it's easy (and rather common) to have the passion of the new convert. You've seen the true light of DevOps, you've drunk deeply from the fountain, and you'll brook no compromise or deviation. Everything must be done by the rules, and if your organization resists then the resistance must be ground to dust. The problem is, dust is pretty well useless when it comes to running a data center.
What you really want to do is consider DevOps discipline to be a set of guidelines, rather than a rigid recipe that must be closely followed. Each organization is unique. Cultural, technological, and process-driven differences must be taken into account when implementing any new process or technology.
If you look at DevOps as an opportunity to replace outdated processes, it's fine. Be sure you're not trying to force your company to serve a framework, rather than optimizing the framework to serve your company.
You know the 3,740 issues that your company is facing today? DevOps is going to cure every single one! Employees will be happy, productivity will improve, costs will be dramatically reduced, IT systems will never, ever break down, and a gentle, golden light will envelop every office. Cue the sound of angelic choirs.
If you go into the process using language which promises too much, executives will be disappointed, no matter how much improvement DevOps brings to IT. In your own thinking, and especially when talking with partners in other business units and the executive suite, be realistic about how big an impact DevOps can have. It is always -- always -- better to under-promise and over-deliver than the reverse. Always.
I know people who genuinely hate the word "culture" when it's applied to companies. Most feel it's a feel-good catch-all for discussions about ping-pong tables and free dry cleaning.
Whatever you want to call it, every company has its own way of doing things, talking about issues, moving forward with decisions, and dealing with challenges arising between and among departments. When you're moving forward with DevOps, you ignore those differences at your own peril.
Just as you need to adapt DevOps principles to your organization's processes and procedures, your company culture has to adopt DevOps. Sure, communication must take place. But, rather than reaching out and installing someone else's DevOps comms framework, try using the communications already developed in your own company culture.
If your company has already made strides in cross-departmental collaboration, build on that progress instead of trying to sweep it away. Always keep culture in mind when imposing change. It's the only way to end up with rejoicing rather than rebellion.
Feedback and post-mortems are critical during any period of great change. The real question is how widely you cast the net for the feedback. If you cast a net no further than the walls of software development and IT operations, you'll end up well-versed on how your staff is responding to the change -- and completely ignorant of the impact DevOps is having on the rest of the organization.
Ignorance of the greater organization is one of the worst situations developers or operations professionals can find themselves in. So, how to avoid this worst-case scenario? Involve business units in assessments and post-mortems. Involve business units in your DevOps planning and implementation.
Cast your net wide, even if some of the people caught are there only for feedback, with no responsibility aside from honesty. You'll end up with useful results and companywide support for your DevOps plans going forward.
What's the point in having a process if it doesn't deliver results right now? We're almost a month into this whole DevOps plan. Where are my dramatic results?!? It must be the staff. We're going to have to start firing people until morale and productivity improve.
We've likely all seen such impatience cause considerable harm at some point in our careers.
Any significant change takes time to produce results. DevOps is no exception to this rule. While it's possible pieces of the process will show quick results, it's likely to take months or more before all the benefits of DevOps become obvious. Give your team, and the process, time to work before you declare DevOps a fraud and revert to your old ways of doing things.
"The devil is in the details," we're often told. It's tempting to keep burrowing down until we bury ourselves in the minutiae of a process. Unfortunately, all the old saws about taking your eye off the large picture can be predictive if you allow your fascination with the details to overwhelm your strategic vision.
There's nothing wrong with keeping your eye on the details -- it's a must. The critical point, as with so much we've been talking about, is to keep those details in context and the concentration on them in focus. Don't get so wrapped around one aspect of the project you forget the reasons for implementing DevOps -- and forget the need for constant contact with your customers and your team in order to know whether you're on the right track.
So there they are, eight pitfalls to dance nimbly around as you walk the path toward DevOps. Have you fallen into one of these pitfalls? Have you found a way to avoid them? I'd love to hear from you about your experiences implementing DevOps in the "real world." Meet me in the comments section below, and let me know what you think.
"The devil is in the details," we're often told. It's tempting to keep burrowing down until we bury ourselves in the minutiae of a process. Unfortunately, all the old saws about taking your eye off the large picture can be predictive if you allow your fascination with the details to overwhelm your strategic vision.
There's nothing wrong with keeping your eye on the details -- it's a must. The critical point, as with so much we've been talking about, is to keep those details in context and the concentration on them in focus. Don't get so wrapped around one aspect of the project you forget the reasons for implementing DevOps -- and forget the need for constant contact with your customers and your team in order to know whether you're on the right track.
So there they are, eight pitfalls to dance nimbly around as you walk the path toward DevOps. Have you fallen into one of these pitfalls? Have you found a way to avoid them? I'd love to hear from you about your experiences implementing DevOps in the "real world." Meet me in the comments section below, and let me know what you think.
-
About the Author(s)
You May Also Like