We’re often told that the existence of a DevOps Team is something of an antipattern, or indeed “considered harmful”, but it wasn’t until I saw this in action that some of the reasons for this advice became really clear in my mind, and I thought I’d note some of them down here.
In the “bad old days”, the developers used to write code and “throw it over the fence” to the operations team, who were the custodians of the organisation’s infrastructure and responsible for all software deployment and maintenance. This procedure had an associated cost, of course, in paying the operations team to come to work at night or at the weekend in order to “babysit the deployment”. In order to reduce this cost, the “routine” deployment and maintenance procedures could even be outsourced to lower-paid workers elsewhere in the world.
This approach also created cultural rifts, of course, in that the developers weren’t incentivised to “own” the reliability of the product, and the operations teams had little interest in accelerating the shipping of features, preferring to devote their attention to maintaining the integrity of the infrastructure, particularly when this was the sole deliverable associated with their outsourcing agreement.
Added to this was the increase in cycle time due to the need for “hand-offs” between the various teams involved in getting a feature from MacBook to production, which was exacerbated further when the teams involved in the hand-offs had different goals and priorities, and even different employers.
The DevOps Revolution promised to solve all of these problems by aligning the interests of the developers and the operations teams in shipping features more quickly as well as more reliably.
Naturally, since shipping more features more reliably sounded like an excellent idea, many organisations decided to get a headstart on their DevOps Journey by recruiting a dedicated team to establish their DevOps Capability. The DevOps Team arrived armed with a vast arsenal of tools, and set to the task of establishing carefully crafted pipelines, dashboards with a myriad of metrics, and deployments in blue, green, and all the colours of the rainbow.
The problem, of course, is that the interests of the DevOps Team were no better aligned with those of the feature developers than those of the Ops team had been previously. So, whilst the DevOps Team were busy high-fiving, having just migrated their deployment orchestrations to the latest tool of the day, and created a brand new dashboard with every metric imaginable regarding code quality, the feature teams were still very unclear about how to deploy and monitor the features they were creating, and were reduced to throwing code over the fence to the DevOps Team.
The way to break down the fences, of course, is that the feature teams need to own the delivery and monitoring processes themselves. It’s already uncontroversial to suggest that development teams should seek to cultivate “T-shaped people”, with deeper functional expertise in one area, such as databases, testing, or front end coding, as well as a base level of understanding of all the tasks required to successfully deliver a feature. In the modern world, of course, one of these competencies is the ability to create test and deployment automation, as well as infrastructure and monitoring, or in other words the tasks that are being done by the newly established DevOps Team on the other side of the fence.