The four most common pitfalls of DevOps – and how to avoid them

Traditionally, contradicting objectives of developers and operations specialists have caused conflicts between the two groups. The developers’ objective is to create new features, which naturally causes distress for operations specialists who are responsible for keeping the services up and running with high availability. The seemingly separate objectives have caused the two groups to dig their silos while blaming each other for making working towards the objectives troublesome. 

DevOps has emerged to address this age-old contradiction. On one hand it has gained significant traction in recent years, but on the other, it has also been fundamentally misunderstood in many implementations. We have gathered the most common pitfalls of DevOps adaptation together with tips on how to avoid them in your organization.

Pitfall 1: Rebranding existing teams to “DevOps” teams

Typically, an easy first approach in implementing DevOps is to rebrand existing teams to DevOps teams and maybe setting up recurring meetings between the development and operations teams. This would seem like a logical step to take, but that’s very far from actually implementing DevOps. As DevOps is all about a mindset shift and while rebranding team names might be a small part of a successful implementation, it's mostly a cosmetic thing to do and does not change anything in itself. 

The real change must happen at the level of organizational culture as new ways of working need to be tried and evaluated together. By keeping the old processes and blaming culture, while adding fancy new names for the teams, the management is just avoiding the potentially painful process of learning by trying and failing. This latter process is, however, vitally important for successful implementation.

Pitfall 2: Creating separate DevOps teams

Another similar pitfall is to assign a separate DevOps team, which is fully responsible for the implementation, while the rest of the teams will continue working with the previous processes. DevOps is not the sole responsibility of some group of individuals who are responsible for doing the “DevOps stuff”. To succeed in adopting DevOps, you must consider DevOps as your core culture and it must be present in everything you do. It can’t be something that a separate group of DevOps people do in a dark basement.

Pitfall 3: Pipelines, pipelines, pipelines

DevOps is often considered to be a synonym for a bunch of tools – mostly different kinds of automated CI/CD pipelines. Yes, it’s true that it’s impossible to do DevOps without any automated pipelines, but there’s much more to DevOps than just that. For example, if you have a pipeline building the codebase from every commit, but you are still creating releases every 3 or 6 months with heavy change advisory processes, you are not doing DevOps. If this is the case, you have to ask yourself what’s keeping you from releasing in shorter cycles.

DevOps is all about shortening the feedback loop between creating a change and receiving feedback through monitoring actual production use. Market leaders are shipping releases multiple times per day, so if your processes prevent you from getting to the market, the competition will soon outperform you.

On a side note, it’s also crucial to take a while in selecting the right tools for the implementation as well. Wrong tools that do not support the processes well, or do not smoothly line-up with the teams’ ways of working, might compromise the whole implementation. Taking some time to investigate different options is well worth the effort. Luckily, this is quite easy nowadays as all major cloud providers offer DevOps tools as well. To give an example: if the team is already building on AWS, it’s quite straightforward to take CodePipeline into use.

Pitfall 4: DevOps equals NoOps

Another misconception that is quite common in the industry, is that by combining Dev and Ops together as DevOps, you do not need operations specialists at all, since developers will be managing the operations duties as well. However, this is not the intention of DevOps. Being a good developer does not mean that one is a good operations specialist as well, and vice versa. Because these two professions require different kinds of skill sets and different mindsets, operations duties can’t be fully offloaded to developers. Also, if developers are busy with the operations activities, it tends to result in more firefighting and less features shipped. 

This is exactly the problem the DevOps approach is trying to address. A better approach to organizing operations activities is to have separate professionals with necessary specialized skill sets. They need to work in close collaboration with the developers, so that they can both focus on their own areas of responsibility, without creating silos and barriers tp communication. 

Keep calm and nurture a collaboration culture

In conclusion, DevOps is not a silver bullet that would magically solve all problems of long development cycles and blame culture. Just adding new tools on top of old processes without actually changing anything, can make things even worse. So when adopting DevOps, you must be prepared for a major cultural shift. The path surely won’t be painless, and many mistakes will be made, but doing things properly and not cutting corners will eventually result in impressive results.