It can be dispiriting when we see the IT Industry take genuine attempts to solve problems, and turn them into vacuous marketing opportunities, or ways of disguising IT cuts on essential services. If a codified set of practices gets a name, and visibility, troubled organizations often clutch it as a panacea for deeper problems of inter-departmental conflict. However, a set of practices that is a tonic for a healthy organization can be a poison for a ‘sick’ one.

The DevOps movement, for example, aimed to highlight and explain a simple set of practices for improving communications between the operations and development teams. It encouraged practices that had existed for decades, but had never been promoted widely. This was as much a business concern as a technology practice, instilling at all levels the need for a culture of collaboration, by removing rigid team structures, and have specialized staff working side by side, cooperatively. Each person brings individual skills to the tasks of automation, feedback and metrics, in order to improve the speed of software delivery, and the reliability of that software.

Unfortunately, an organization can’t reliably heal itself by ingesting Agile or Devops in the same way a person can take an antibiotic. These practices only work in an organization with an adaptive ethos and shared values. For experienced system administrators, or systems-oriented developers, who find themselves working at the forefront of the “revolution” in a new DevOps team, but in the wrong type of organization, it can be a painful experience.

In organizations that have wider problems, DevOps can mean nothing more than “configuration management in AWS”. It becomes a byword for automating away release, QA and other operational processes, as well as the operational and staff costs that go with it, presumably. It has little interest in tackling the age-old issues of lack of communication. Code and requirements still get “thrown over the wall” at the last minute. All of the old misperceptions remained in place.

The result of adopting the wrong medicine for the wrong reasons can be even worse, with some development teams, sensing that their applications now drive not only the business, but also the infrastructure, being all too ready to demand their own access to systems if they cannot get what they want, when they want it. The Ops teams wake up to the sight of Dev tanks on their lawn.

Perhaps, when ideas intended to promote cooperation and increase productivity are instead used in this way, it is time to study the group psychology of the organization, instead of attempting to bolt on more adaptive development practices.