The DevOps movement has produced many benefits in a short time: shorter lead times, greater intra-organizational communication, smaller feedback loops and more productive teams. It has also produced many myths and misconceptions. Here’s a few that I’ve encountered recently.


Of the organizations[1] I’ve worked with that use the DevOps label, the one that works closest to the original definitions (such as this one by Patrick Debois) is foiled by being separated from all things post-staging because their production operations are outsourced. There is good communication in this organization; all the -ilities (scalability, stability, security, performa.. uh. bility?., etc.) have requirements and are measured against those requirements; feedback from operations is quickly acted on by product development and leadership teams; and all the deployment and monitoring tools in use in production are also in use in staging environments. This organization is very mature in DevOps terms (they’ve got the culture), though they’re not all the way there yet.


The DevOps team (or in small organizations, the DevOps person) is probably the most common misimplementation of DevOps. A core value of DevOps is to employ the entire organization to conceive, design, develop, release and maintain valuable software. If only one team or person is doing that, then the rest of the organization must be redundant. And more likely, if the DevOps team or person is doing only a part of that (typically, release engineering), then they are, by definition, not DevOps. No matter how well they do those DevOps-y things.


Two organizations I’ve worked with lately have used DevOps to describe the internal support role: the IT guy who provides assistance to the dev team. That’s just a misunderstanding of the term: they’re not doing anything new or trying to be DevOps, it’s just an error in labeling. In both these cases, because there was just the one person packaging releases and deploying to test and pre-production environments, there was no oversight and no drive to automation. Both organizations are ideally placed to start on the path to DevOps, yet they use the term to describe what they already have. In other organizations I have worked with (which thankfully have not yet chosen to use the term DevOps) there are entire teams of post-development internal support engineers. These organizations face a bigger challenge should they choose to work towards DevOps, since they have institutionalized the separation between software creation and software support.


In the worst case of mislabeling that I’ve heard of, the so-called “DevOps team” was formed by collocating the developers and the testers. The organization did not change its thinking, no practices were changed, no roles were merged, the path to production was not improved, and responsibility for in-production software remained with the (outsourced!) post-release support team. I suspect that a hands-off executive mandated DevOps and an expenditure-averse manager came up with this solution.


In addition to these cases that I’ve personally encountered, there are plenty of other stories of misadventures in DevOps. There are lots of examples of organizations that separate DevOps from Ops/Support (effectively renaming “Dev” to “DevOps” without changing anything substantive). Less commonly encountered these days are the organizations that allow ad hoc hot fixes direct to production (a fast road to failure!).


The many misunderstandings about what DevOps means are completely understandable, since it’s such a new term to most people. These few examples of what not to do are hopefully giving you a few ideas about what you should do. I’ll go into just a little more depth on some of the key terms associated with DevOps.


1: I’m using organization to refer to the IT and product delivery facets of a company or enterprise. This includes company leadership, marketing, finance and other facets that overlap product delivery, even if they are mostly employed in other areas of the greater enterprise.