Emphasizing the Dev in DevOps

The term “DevOps” was supposed to be a method to bridge the gap between Developers and Operations and create self-sufficient, autonomous teams. But in practice it’s mostly associated with operations. When an organization is “doing DevOps”, and has employed “DevOps Engineers”, it often means they’re automating deployments and CI/CD pipelines, in addition to generally filling the role of what we used to call “System Administrators”. A cynical person might even say it has become just another marketable term to sell products and services, while losing track of the problems it was meant to solve.

What problems?

It’s all about feedback loops. When a developer builds software, they want to know several things, for example:

• Does it functionally do what it’s supposed to? And does it not do what it’s not supposed to?
• Does it perform?
• Does it scale?
• Is it secure?
• What happens if something goes wrong?

Answering these questions in a timely manner leads to continuous improvement, which in turn leads to higher quality software and happier end-users.

Notice anything else about these questions? You can’t answer most of them without some knowledge of “Operations”. If the people with operations knowledge are not part of the development team, this creates a bottleneck or even conflicts of interest. Questions, requests and problems may have to be thrown across the fence for the “DevOps team” to solve, while the developer who built the software has to wait. The DevOps team might already be swamped in dealing with issues from other teams, while themselves also not knowing enough about the software they’re operating. At the same time, a developer might not even have sufficient rights on whichever environments to investigate the issues they’re facing.

What’s often seen as the answer to these problems is automating and abstracting away any perceived gaps in knowledge. Templated CI/CD pipelines and deployment building blocks, maybe even A.I. generated these days, are used as the way to resolve these bottlenecks.

But an organizational problem isn’t solved by a technical solution. If a pipeline fails, is it immediately apparent why it failed? Is it because of a problem in the software or because of the infrastructure, or because of the pipeline itself? Does a developer have the means to answer this question? On the other end, if a problem becomes apparent in production, can whoever operates the product answer these same questions? And won’t it become something else to throw back across the fence?

So where did we go wrong and how do we solve it?

Educating and reorganizing teams is hard. In contrast, slapping a new label on an existing organizational structure is easy. We’ve seen this with Agile transitions and we’re seeing it now with DevOps. But to solve the aforementioned bottlenecks, improve feedback loops and the development lifecycle, and really do continuous improvement, an organizational shift is required.

This organizational shift can be summarized as the following:

1. Trust developers to operate their own stuff.

As is often the case with many organizational issues, trust is at the center of it. While many developers may want to learn about operations, or are already more than capable to operate their software, they may not have sufficient access rights to do so. If a developer is unable to see what’s going on in production and how end-users are interacting with the software, this hampers how they’re able to investigate and respond to issues. Also, if they don’t have an environment where they have full admin rights (i.e. a sandbox environment), this hampers creativity and innovation.

This lack of permission might be due to an overly restrictive security policy, or it could be because operations is “gatekeeping” what they see as their task. Either way, it’s something that should be improved if you want to improve the development lifecycle.

2. Put operations in development teams

A point you’ve probably heard before, but which doesn’t happen often enough in practice: put those with operations knowledge in software development teams, rather than a separate “DevOps team”. Additionally, and I can’t emphasize this enough: do not make it their sole responsibility to operate everything the development team has built! Instead, make it their task to help the rest of the team become more able to operate their software themselves. Which leads directly to the next point…

3. Encourage learning and sharing knowledge between developers and operations

If developers know how to operate software, and operations knows how software is built, this leads to quicker cycle time whenever an issue pops up or improvements must be made. This doesn’t mean everyone has to know everything, nor does it mean you have to get rid of certain roles. It does mean an environment for learning and sharing knowledge has to be facilitated. This starts with putting people in the same team, but doesn’t end there. Encourage pair programming, writing test cases (which are a great form of documentation and feedback loops) and invest in trainings and collaboration tools.

Most importantly: don’t be afraid of failure. The most useful learning experiences occur when things go wrong. Mistakes will happen and rather than pointing fingers, or worse, punishing them, should be embraced as opportunities to improve.

To conclude, ask the question: can this team function autonomously?

Or more elaborately, can this team take this software product from ideation to production autonomously? And does it have everything it needs to learn from feedback loops in the development lifecycle to continuously improve the product and themselves? If the answer to these questions is “yes”, then congratulations! You’re actually practicing true DevOps. If the answer is “no”, look to the previous points, which should help you make this a “yes” in the future.