Devops Anti-Patterns

While I’m collecting Devops Protocols which highlight healthy patterns in your organization, let’s take a quick look at the opposite: Devops anti-patterns. Would you be able to spot the warning signs when your team starts to slip in the wrong direction?

Committed is “Done”

It’s a good and trusted agile practice for a team to create a “Definition of Done”. It helps each team member understand exactly what’s necessary to truly finish a task. But watch out! Your Definition of Done might lead you down a thorny path or even cause short sightedness within teams. How could a Definition of Done do this? Let me explain.

Short sightedness within your team happens when each member only cares for their contribution to a task. They assume if they’ve finished, everything is fine. For a developer, this is thinking “committed is Done”; for a sysadmin “My script is running and I can understand it”. Sad to say it folks, but this isn’t Devops!

Every developer must think of the end user. Committing a piece of code is far from being done. It needs to work in all kinds of weird use cases. And it’s not only QA’s job to find all the bugs. Good developers want to ensure that the new features are not only coded, but tested and ultimately released to their users. Only then the task is really Done.

The same is true for sysadmins. Having a nice script on your own box is not enough. Every sysadmin needs to make sure it’s possible to re-create each part of the infrastructure at any time. When that slick, new script is under version control, written in a way others can understand and modify it, is their task really Done.

My Responsibility Ends Here

Another pattern I frequently see is the dreaded line in the sand: “My responsibility ends here”. A developer might think it’s not his job to see a feature through to release, a sysadmin might think that if the code breaks it’s not his problem.

They’re both wrong. To really create a high performing organization, able to rapidly deliver real customer value, individuals need to take broader responsibilities: everyone needs to care about getting valuable features into the hands of their users. No matter if there’s a code or operations problem, everyone should feel responsible and help find a fix. A team must pro-actively find ways to contribute to the solution of any release blocker, no matter where the fire is burning.

Take caution: if your team’s vision stops at seeing only themselves instead of the other parts of the organization needed to actually get their created value into users’ hands, then they have not taken full responsibility. Only taking complete responsibility will help foster the growth of a true Devops culture.

They should

A stronger form of the “my responsibility ends here” anti-pattern is the “us vs them” syndrome. It might start as soon as you move a few tables a bit farther apart. Suddenly, there’s a physical gap and people start thinking in “us vs them” terms. This thinking gets stronger the further people are separated. Different rooms, locations, and departments create islands of “us” and hinder collaboration.

If you start seeing “us vs them” emerging in your organization, fight it. Make sure people understand everyone’s contribution to the overall success of your organization and provide more interaction between these islands of “us” to improve communication. Only a feeling of belonging together will foster collaboration and lead to a Devops culture.

There are quite a few Devops anti-patterns: a flawed “Definition of Done, the stubborn “my responsibility ends here” or, even worse, “us vs them”. These are bad things you need to watch out for. If you see such patterns pop up around you, act immediately because they’re indicators that your team is on the path to short sightedness, sub-optimization, and blaming wars instead of growing a healthy Devops culture.

Have you seen such anti-patterns in your organization? Let us know your story in the comments below…