Yes, Agile DevOps initiatives sometimes fail
Why do DevOps initiatives sometimes fail, and how can they be more successful? Gene Kim, author of The Phoenix Project, admitted that most of the stories that get told and retold about DevOps transitions are glowing successes. This survivor bias means that the fiascos don’t get all the attention they deserve. Glossing over the disasters makes it hard to assess the overall state of DevOps. Some degree of failure is actually very common on the road to DevOps. Kim admitted, “That may actually be a more telling indicator of the movement than the ones that actually survived.” Of course, there have been enough problems for experts to have a good idea of what typically goes wrong.
What makes DevOps implode?
Scott Wilson, Product Marketing Director of Release Automation, touched on why and how DevOps initiatives fail during his presentation. Despite the idealistic notion of Dev and Ops traipsing through a meadow hand in hand in a united utopia, the reality is quite different. The primary reason DevOps fails is because Ops gets left out. Dev is very Agile and has all the cool tools and processes. But they are still throwing code over the wall for deployment. According to Wilson, “We need to focus on making Ops more Agile.” Failing to respect and invest in the role of Ops is a fatal error. When Dev gets all the attention, “You reinforce the wall, especially if Ops is using different deployment tooling or automation mechanics.”
Open source addiction is also to blame
Another key reason that DevOps can fail in a typical enterprise that does Agile or Scrum is because of an enthrallment with open source. It’s easy to become dependent on open source in the DevOps world because it is such an integral part of the overall culture. But the DIY effort and security failings that come along with open source don’t always make it a good fit for every business model—even in an era where “every company is a software company.”
In practical terms, “If you are an insurance company, you generate revenue by selling insurance policies. Do you really want to install a bunch of open source software that you have to maintain, that you have to write the glue for and do the API plugwork and then make certain to update to the latest libraries to shield against vulnerabilities?” Scott advocated a balance of open source and vendor supplied code to relieve some of this unnecessary burden on internal DevOps teams.
Predictors of success in DevOps
Although getting teams to “buy in” and support this type of transition is important, popular enthusiasm is clearly not sufficient to effect change at the enterprise level. Wilson pointed to Heather Mickman’s account of transitioning to DevOps at Target. “The real progress was when the new CIO came in.” This senior executive had the clout and vision to roll out DevOps across the entire organization. This seems to be a typical story.
The IT Skeptic, Rob England, agreed. As a consultant, he has noticed that it usually takes some kind of moment of reckoning for upper management to step in and claim ownership of change. Then, Rob recommended pointing to the DevOps efforts that have been happening in small teams at the grassroots level as an example of how to do things better on the big stage. “You can use those quick wins to drive change.” For the enterprise, DevOps may start at the bottom, but it gets its staying power only when it gains support from the top. When an enterprise fully commits as an organization, that’s when things really start to work.