For organizations with existing hierarchies and processes the shift to a DevOps mindset can be a challenge. The traditional departmental roles and separation of duties is anathema to an efficient DevOps culture. When it comes to DevOps there’s no room for finger-pointing—every team and individual is equally responsible for making sure everything is firing on all cylinders.
Gene Kim, coauthor of The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win and the upcoming DevOps Cookbook, took part in a podcast earlier this year and shared that two-thirds of the DevOps success stories he has seen are actually from established businesses with existing infrastructures and processes as opposed to “greenfield” projects that embrace DevOps from the start. In those situations, the drive to embrace DevOps has to come from somewhere, but in order for DevOps to work the organization has to overcome the urge to place the entire burden for the success or failure of DevOps on that one team or individual.
There is a reason that the word “culture” plays such a central role in any discussion of DevOps. Without a shift in the mindset of how teams and individuals communicate and collaborate a DevOps initiative isn’t much different than any other IT project in the organization. One team or person can use DevOps tools, but that’s not really a functional implementation of DevOps.
That doesn’t mean that DevOps is an all-or-nothing game. It’s possible for different departments or elements within a company to embrace DevOps without the whole company jumping on board. There has to be a quorum of sorts, though—a broad enough consensus between teams and individuals to cooperate and collaborate in a different way than how it’s laid out on the company org chart. An important part of that shift is for everyone to accept responsibility for the outcome and work together toward a common goal.
There’s a phrase that goes something like “When all you have is a hammer, everything looks like a nail.” Developers understandably view the world through the filter of developing. IT operations people look at projects from the perspective of operations. QA looks at things from the point of view of testing and quality assurance. Accounting considers projects from the financial angle. Security personnel tend to focus on the security aspects. You get the idea.
Kim shared an excerpt of the upcoming DevOps Cookbook with me. In the book Kim talks about the need to move from functional-oriented teams optimized for cost to market-oriented teams optimized for speed. He talks about the challenges and bottlenecks created when some teams or elements are moving at an accelerated pace while others struggle to keep up.
Part of optimizing for speed is shifting the perception of responsibility. Smaller, market-oriented teams are more agile and can deliver value to customers—both internal and external—while reducing or even eliminating reliance on other teams. Kim explains, “Taken to its extreme, market-oriented teams are responsible for not just feature development, but also testing, securing and deploying their code into production themselves, as well as being responsible production operations and availability.”
In order for DevOps to work effectively, everyone needs to forget that they’re a “hammer” and view the project as a more comprehensive toolbox instead. DevOps teams need to strive to break out of the traditional roles and silos and make a conscious effort to see things in terms of the common goals or greater good.
