Gene Kim's 7 secrets of DevOps success
When Gene Kim and fellow co-authors Kevin Behr and George Spafford published The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win in 2013, DevOps was seen by many as the domain of a chosen few organizations with the luxury of building their IT and engineering organizations from scratch. But when Kim, his team at IT Revolution, and founding partner Electric Cloud launched the first DevOps Enterprise Summit a year later, they quickly demonstrated that the movement to make development and IT operations more collaborative—and productive—was taking hold in large, complex enterprises across industries.
"We've got some of the largest brands in every industry vertical presenting stories about how they've increased the agility of their organization while providing world-class availability, security, and stability," says Kim. "Large, complex organizations that have been around for decades and even centuries are getting the same amazing outcomes."
Among those who have shared their experiences in leading widespread DevOps change efforts in large enterprises are IT leaders from Raytheon, U.S. Citizenship and Immigration Services (USCIS), Nordstrom, Disney, and Bank of America. More than 700 IT leaders showed up for the first conference, and attendance doubled the next year.
It's clear that DevOps is passing into wider acceptance. "And we've learned a lot about what drives these transformations," says Kim, co-author of The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security In Technology Organizations. In a recent conversation, he called out some clear commonalities among those businesses that successfully make the DevOps transition on a large scale.
1. Change often begins in operations
Most people presume that software development leaders spearhead the shift to DevOps. The assumption is that beleaguered development groups—the same ones that rebel against sluggish IT operations by doing their own provisioning in the cloud—are leading the change.
Not so, says Kim. While the majority of audience members at the typical DevOps Enterprise Summit are developers, most of those sharing stories of successful DevOps transitions on stage work in operations. "For early adopters, it's operations leading the charge, followed by architecture," Kim says. "These folks have the full end-to-end view of the value steam and can see the problems that need to be solved."
2. DevOps transformations start small—but not too small
When beginning the shift to DevOps, the scope will get ignored if it's too small and doesn't solve big enough business issues, Kim says. If the span of transformation is too large, however, the transition can jeopardize organizational performance. The sweet spot is somewhere in between—cases in which DevOps is introduced to solve a very specific business problem with clear, anticipated benefits, like shorter lead times or increased reliability. That, he says, is why DevOps initiatives are often driven by second-line managers, like a director of operations in a business unit.
3. Business-savvy technologists take the lead
The leaders most likely to recognize the "just right" opportunity to introduce DevOps are engineering or IT professionals who are close enough to the business to appreciate its biggest challenges intimately but have a clear understanding of the technology in play.
4. DevOps change agents take risks
"All of these DevOps leaders are given some degree of air cover, but they go beyond that to the point that it puts them in some personal jeopardy," Kim says. Why risk their careers? "They have a level of certainty that the capabilities they are creating for the organization are needed not just to win in the marketplace, but to survive."
And if these DevOps leaders are successful, they're often rewarded for their bravery: One quarter of previous conference presenters have been promoted, once or more, since speaking. "That tells us that DevOps has created such visible organizational value that they're being asked to make the improvements not just in their business unit, but across the entire organization," Kim says.
5. DevOps demands a culture of trust
When it comes to successful DevOps transformation, culture is key. In fact, it's one of the top three predictors of DevOps performance, according to five years of analysis conducted for the annual State of DevOps report, whose co-sponsors include Kim's IT Revolution and Hewlett Packard Enterprise. Power- or rule-oriented cultures are not well suited to the type of collaboration and information sharing that DevOps requires.
"The most successful DevOps organizations exist in cultures of high trust," he says, "and those cultural norms set the tone required to enable knowledge sharing and blamelessness among teams."
6. DevOps expansion requires leaders to evolve
The introduction of DevOps at the business-unit level opens up the possibility to expand DevOps practices across the enterprise. Kim says that can sometimes be difficult for DevOps leaders who are used to being hands-on in the change. When solving problems at the business-unit level, these tech professionals have a high degree of control over the transformation. As they get promoted, they have less overt control and must learn how to lead through influence. "That's much more challenging," he says.
7. CIOs are key enablers of DevOps
So far, just three CIOs have presented at the DevOps Enterprise Summit: USCIS CIO Mark Schwartz, ING CIO Ron van Kemenade, and former Clorox and HPE CIO Ralph Loura (now the CTO of Rodan + Fields). Kemenade spoke about how dysfunctional ING's largely outsourced IT organization had been and how insourcing and introducing DevOps in 2011 transformed IT's performance and reputation. While not every IT executive will be as directly involved in the introduction of DevOps in their organizations, CIOs play a key role in removing obstacles and setting up DevOps teams for success. A director of mobile app development at ING proposed the DevOps approach, but van Kemenade recognized its value and nurtured the wider transformation.
This article/content was written by the individual writer identified and does not necessarily reflect the view of Hewlett Packard Enterprise Company.