By Samuel Greengard
It’s no secret that agile IT has emerged as a mantra for the digital age. But behind the massive buzz, organizations are discovering that the concept makes sense … and maximizes dollars. One area attracting a lot of attention is DevOps, which introduces a more collaborative and iterative approach to managing tasks at the intersection of IT and operations. Nearly six in 10 organizations now use DevOps in one form or another. Nevertheless, many enterprises continue to struggle with the concept. Here are six key lessons:
- DevOps is a philosophy. One of the common mistakes business and IT executives make, says Cameron Haight, a research vice president at Gartner, is viewing DevOps as a body of knowledge or thinking of it in the same way as an IT infrastructure library. “There’s no prescribed set of things to do and there’s no pre-established roadmap,” says Haight. “It’s not something generated by a committee. It’s a way of thinking that revolves around innovation and experimentation. Release management and change management are key focal points. It’s all about agility.” Adds Damon Edwards, cofounder of DTO Solutions, a consulting and integration firm specializing in DevOps, “It’s not all that different than how the lean movement turned certain manufacturing companies’ ability to deliver into a strategic weapon. The DevOps movement is following that same arc, it’s just in a pure digital context this time.”
- The CIO isn’t the primary driver. In most cases, DevOps begins with those in the trenches of IT. “They are tired of receiving phone calls at 2 A.M. so they’re interested in finding a different—and better—way to work,” Haight explains. As a result, the basic structure of the initiative should come from actual developers and IT staff. However, a CIO must be involved at some level. “There’s a pretty significant culture change required and, within the agile manifesto, there’s a need to prioritize and rank things. There’s also a need to establish metrics, KPIs and governance models.” A CIO can play a key role in orchestrating and overseeing the initiative.
- DevOps is more than a tool for the IT department. At the vast majority of companies, DevOps is viewed almost entirely as something to be used within the walls of IT, Edwards notes. “Far less attention has been paid to the effects of DevOps across the broader company. Almost no attention has been paid to the effects of DevOps outside the walls of the company.” Unfortunately, the lessons and principles of the concept are applicable beyond the IT department. “DevOps can turn IT operations into a sustainable competitive advantage,” says Edwards. Nevertheless, he cautions that a cookie-cutter approach doesn’t work. “Don’t just copy the tools or move around the org chart to look like someone or something else. That doesn’t work,” he says. “There’s a long history of that not working in the lean manufacturing world and there are plenty of early examples in the DevOps movement of that being a failing strategy.” Instead, Edwards suggests examining a high-performance culture and understanding the why behind its tools and processes.
- A shared ownership approach is critical. One of the problems with conventional development is that different departments, groups and teams establish different metrics and goals. However, one group’s metrics may have nothing to do with another group’s metrics. Or worse, it may actually undermine them. Things also break down when handoffs occur. In some cases, there’s a strong “cover your ass” component to completing tasks and phases of projects. Unfortunately, “changing the metrics may not solve the problem,” Haight points out. “You really have to create a system with the right incentives so that you encourage collaboration and cooperation.” Edwards points out that it’s about more than simply breaking down silos. “If you don’t address the organizational and political issues that cause your silos, then you are just going to be chasing your tail trying to fix symptoms.”
- Rolling out and expanding a DevOps initiative requires ongoing planning. One thing that makes a DevOps initiative both exciting and scary is the fact that people must be comfortable working without prescribed boundaries. Consequently, it’s important to identify people with the right mindset and personality for DevOps. Moreover, it is important to use these evangelists to seed the concept further into the enterprise. Once a company has established a level of success using DevOps, a scrum-to-scrum approach can pay dividends. It may also be necessary to categorize and prioritize an application portfolio based on the volatility of the project, the governance required and the potential impact.
- Communication will make or break the initiative. Since communication and collaboration are at the heart of successful DevOps, it’s critical to build a framework that supports the free exchange of ideas. “The focus,” Haight says, “must be on breaking down the silos and removing conflicts based on ownership.” It is critical that operations teams or operational tech leads attend daily scrum standup meetings “so they know what’s coming through the pipeline.” Similarly, “there needs to be more ‘Dev’ people attending ‘Ops’ meetings, including post-mortems that avoid the blame game. The focus should be on solving problems and ensuring that an incident or problem doesn’t occur again. The focus must be on the problem, not the people.”
About the Author
Samuel Greengard is a contributing writer for CIO Insight. To read his previous CIO Insight article, “Five Things to Know About Remote and Virtual Teams,” click here.
