How not to do DevOps: our expert tips

No one said doing DevOps was easy. But if you can avoid these common catches, your transformation will stay one step ahead of the game.

DevOps can mean the difference between slow, hoop-jumping processes and a fast, autonomous culture where continuous product flow is the norm. From development and testing through to operations and deployment, this fail-fast framework is challenging outdated ideas and ushering in a new era of software development.

But it’s not without its challenges. Unprepared and unsupported, teams facing the following pitfalls could find themselves halfheartedly pursuing DevOps moving forward, never fully realising the benefits, or worse still eschewing it altogether. Here, we take a look at six stumbling blocks likely to cause issues and suggest ways to stop them in their tracks.

Sadly, this is not a simple case of ‘if you build it, they will come’. It won’t be enough to declare your organisation DevOps-determined and then sit back and hope everyone figures it out for themselves. You’re going to need people with specific skills to get DevOps off the ground – either relying on upskilled team members or new hires. As adoption increases across the organisation, make sure you’re on the front foot to ensure all employees have the skills to keep things moving.

Consider the benefits of a DevOps training program to help everyone become familiar with the new tools and processes. Appoint DevOps cheerleaders across the organisation to help bring people onboard and knowledge-share. And tailor training so that people don’t feel overwhelmed by having to learn more than is necessary for their role.

One of the key facets of DevOps is keeping track of progress through relevant measurements and then adjusting processes and tools accordingly for optimal results. If you fail to do this, you’re essentially stumbling around in the dark with no data to base decisions on. Of course, different stakeholders will have different priorities and goals – and as a result what they want to measure will vary. It’s vital that you bring everyone together to agree on big-picture metrics before you design a dashboard.

While ‘DevOps’ conjures up visions of automation and slick technology, don’t be fooled into thinking it has nothing to do with people. Its success rests on a seamless synergy between the various teams and processes that it comprises. Sure, tools and tech are vital components, but nothing happens without effective communication, collaboration, and cooperation – not to mention a unifying culture that enables DevOps to thrive. 

Don’t get carried away implementing processes and integrating new tools without bringing your people onboard for the ride. Make sure roles, responsibilities, and the reason behind all these decisions are understood, both on individual and team levels as well as among leadership.

Some developers will sail through their transition to DevOps, but many will be prone to burnout as they are forced to work faster and keep up with the unrelenting pace of delivery deadlines. Mitigate this by keeping your eyes peeled for the warning signs: fatigue, impatience, stress, and a rise in the number of bugs identified. Consider employing a team of site reliability engineers who can act as a channel between developers and ops teams to help alleviate the stress.

Automation plays a huge part in successful DevOps transformation, but if you’re a large organisation, dealing with legacy technology and systems, multiple departments, and siloed thinking, it can be hard to know what to automate first. While smaller, more agile companies will be able to implement continuous integration and delivery from the get-go, if you’re dealing with a more traditional IT set-up, the transition will have to be more gradual. 

Don’t make the mistake of switching flawed manual processes over to flawed automated ones instead. They might be faster, but they’ll still be problematic. Instead, take stock of your current processes, figure out and fix bottlenecks, and then identify the best areas for automation. We recommend focusing efforts where things change quickly and new features are common. Choose a relatively isolated project as a starting point to minimise disruption before rolling automation out across the wider organisation.