OK, so the title is provocative, but bear with me here. Recently I spent a mind-expanding day at DevOpsCon in Israel – I presented the first keynote, which aimed to set the scene for why DevOps is a necessary reaction to some broad organizational and technological changes. What was really interesting however was to hear a range of presentations from different people, all reflecting on what DevOps means for organizations. And there truly was a cross section of people – from dyed-in-the-wool operations practitioners, to development leads, from business users to CIOs, the day ran the gamut of the vested interests involved in the broader operations arena.
And at the end of it I was left with a slightly nervous feeling that in advocating the rise of DevOps, we run the risk of removing one archaic and broken system, only to replace it with more of the same.
The worrying thing was the hallway comments from people who were attending the event in order to formulate a plan to “implement a DevOps team” within their organization. That entire aim missed the point of DevOps as an organizational trend. I spent 45 minutes or so talking about how broken current approaches are – siloed teams, each with differing motivations and areas of focus doesn’t deliver consistency. Neither does the fact that these teams are generally talking in different languages, at cross purposes and with wildly different priorities.
To simply rip this out and replace it with a siloed DevOps team doesn’t help that at all. DevOps isn’t about particular toolsets and neither is it about implementing a black ops team to go around operational turf protection. Rather DevOps is a humanistic movement, one which should be almost completely focused on communication, on bridge building and on the identification of common interest. My frustration was lessened somewhat after reading a post by Jez Humble on the subject. Somewhat confrontationally entitled “There’s No Such Thing as a “DevOps Team”, the core thesis of the post was that
the Devops movement addresses the dysfunction that results from organizations composed of functional silos. Thus, creating another functional silo that sits between dev and ops is clearly a poor (and ironic) way to try and solve these problems. Devops proposes instead strategies to create better collaboration between functional silos, or doing away with the functional silos altogether and creating cross-functional teams (or some combination of these approaches).
In this modern world, where the delivery of agile solutions on an ongoing basis is a non-negotiable requirement for success, organizations need to set themselves an objective to cross functionalize as much within their organizations as possible. This is part of the reason that every step up the stack delivers incremental benefits. Automating infrastructure deployment does much to build bridges between application operations and systems operations teams, and creates common goals where formerly they were hard to identify. Similarly the move from infrastructure up the stack to PaaS all of a sudden means that development and operational tasks are developed and achieved with commonality.
Individual functional silos increase the occurrence of problems. Why? To revert to the previously mentioned post:
…functional silos often get created in reaction to a problem (which they inevitably exacerbate). At the beginning of an interview with Elisabeth Hendrickson I posted recently, she discusses working at a product company which was suffering a series of quality problems. As a result, they hired a VP of QA who set up a QA division. The net result of this, counterintuitively, was to increase the number of bugs. One of the major causes of this was that developers felt that they were no longer responsible for quality, and instead focussed on getting their features into “test” as quickly as they could. Thus they paid less attention to making sure the system was of high quality in the first place, which in turn put more stress on the testers. This created a death spiral of increasingly poor quality, which led to increasing stress on the testers, and so on
Functional silos (and a standalone DevOps team is a great example of one) decouple actions from responsibility. Functional silos allow people to ignore, or at least feel disconnected from, the consequences of their actions. DevOps is a cultural change that encourages, rewards and exposes people taking responsibility for what they do, and what is expected from them. As Werner Vogels from Amazon Web Services says, “you build it, you run it”.
So a “DevOps team” is a risky and ultimately doomed strategy. Sure there are some technical roles, specifically related to the enablement of DevOps as an approach and these roles and tools need to be filled and built. Self service platforms, collaboration and communication systems, tool chains for testing, deployment and operations are all necessary. Sure someone needs to deliver on that stuff. But those are specific technical deliverables and not DevOps. DevOps is about people, communication and collaboration. Organizations ignore that at their peril.