Michael Fritzius is President of Arch DevOps, LLC, discusses how you can adopt DevOps successfully, and not repeat the mistakes of others.
As the demand for software increases, DevOps is poised as the next paradigm for quick, quality releases. Some companies are successful at implementing it, while others fail catastrophically. But why? Is it random chance that it fails, or is it something deeper?
I say it’s deeper. I’ve found that there’s a common, culture-related theme to companies that can’t adopt DevOps, and I want to share what that is with you so that you don’t make the same mistakes.
That one thing—the big secret to DevOps success is: Eliminate fear. And that’s it.
DevOps is innovation
It may sound simplistic, but the core of DevOps is innovation. When fear keeps us from wanting to try, act, pivot, wonder, craft, ask, touch, execute, probe, apologise, deliver, retool, or even fail, then those unhampered by that fear will outperform us.
I really want you to succeed at this. So, whether this is your first time, or you’re a little trigger-shy from a recent failure, you have to be free to move—fearlessly—in whatever direction gets you to your goal. To that end, I’d like to identify, and then suggest, strategies on how to combat the common places fear can manifest.
The mother of all fears is the fear of failure. Many people are afraid to take a calculated risk if they feel like they’ll be punished or embarrassed if they end up being wrong. But, there’s a really simple way to prevent that fear, and that is to point out the positives instead of the negatives. For some, it takes a lot of bravery to get out of their comfort zone, so try rewarding people for taking a risk and trying something new. Define what it was that was learned as a result of the failure. Not only will this foster a nice fear-free zone to work in, but people will own up to their goofs sooner, and not be as likely to sweep mistakes under the rug.
Picking the correct stack
This can be scary, because we think we have to have the correct solution, in one shot. It’s tempting to adopt what worked for another company and expect it to work for us. Not so. Everybody’s problem set is unique, like a fingerprint. So, instead of picking a stack, and risk getting yourself painted into a corner, try adopting a technology to fix an immediate pain point. Maybe it’s automatically starting tests upon check-in, or pushing a build out to various systems. Whatever it is, once the tech’s in place to solve that problem, to make it less tedious, then move onto the next one. Soon you’ll find that—surprise!—you now have a stack.
It’s inevitable that we change chunks of technology, so preventing the fear of change should be high on the list. If we can’t change when we want to, it’ll be difficult to change when we have to. Plus, the longer we put it off, the more likely we’ll need wonky workarounds to keep working. Instead, commit to a periodic amount of time—such as one day per week or per sprint—to researching and implementing tools, upgrades or refactoring. When more people are involved in this, they all get more familiar with the inner workings of the stack, which helps them be less afraid to change things, too.
The fear of never arriving
Finally, I’d like to address the fear of never arriving. It’s easy to get discouraged, thinking that the work’s never going to be “done”. There’s always a new framework, tool, paradigm, platform or methodology. Instead of thinking of it a constant Sisyphean “pushing a rock uphill” task, think of it as a set of challenges. Each one sharpens us for the next, and we grow through each one. It’s important to foster the morale where team members can look back and see how far they’ve come. When the focus becomes the journey, and not the destination, great things will happen.
If you’re ready to give this a (or another) shot, you’re in good company. Implementing a DevOps solution is rewarding, valuable work to undertake, and your team and firm will reap enormous benefits. Just remember to operate from a position of fearlessness, and you’ll be in great shape.
Edited for web by Jordan Platt.
