Devops is all the rage. If you believe what you read in the tech press, devops could even be IT's saving grace. And predictably, as with most hot IT buzzwords, devops is now being used to sell everything from consulting services to cloud services to software.
But develops is not for sale. In fact, it can't be sold, because it's not a product or a service. It's a leadership thing.
Devops started as a bottom-up initiative to get development and operations personnel to work closer together in support of a more agile delivery cycle. Agile development yields better outcomes, but it also increases the burden on operations, which must keep pace with the increased volume of change agility brings. The devops approach pushes development and operations teams to collaborate and fix the organizational issues that were forcing them apart.
The devops challenge can only be addressed by aligning an IT organization's culture and performance incentives around end-to-end quality, agility, and time to market. Ultimately, the organizational issues raised by devops go beyond simply bridging the gap between development and operations.
Getting past the conflictThere's a long history of IT contentiousness between development and operations organizations. Development sees operations as an impediment to getting projects out the door quickly. Operations sees development as not being attuned to its needs for quality, availability, and ease of operations.
To bridge the divide, devops proposes roles that span both sides, such as the release manager, along with general blandishments about greater communication and collaboration. Those approaches may work well in smaller or less complex organizations, but in IT organizations that must serve the global enterprise, they often fall short. Most large companies are built on legacy technology that tends to be fragile -- and agile and fragile mix about as well as oil and water.
The devops leadership issue can only be addressed by changing the culture from a siloed mindset to a quality and time-to-market mindset across all the functions that make up IT. This must be driven through strong CIO leadership. The CIO needs to align functional leaders' goals to reduce time to market, improve quality, and break down the siloed functional incentives of the past. A decade ago these functional silos clarified accountability and had their place in the slower-paced, waterfall world of IT. Today, thanks to the consumerization of IT and today's warp speed of change, these silos now stand squarely in the way of progress.
For example, delivery leaders need to be measured by production quality, whether that's code related or system related. They need a seat at the table when quality issues are at hand, and they need to be locked at the hip with the operations' functional owner. Quality cannot be an operations issue alone. Similarly, the operations leader needs to understand the business drivers and must be incented to support the delivery of business value quickly and cost-effectively. This cannot be solely a delivery issue. If these functional leaders' compensation hinges on end-to-end value and quality delivery, then their organizations will also feel the need to align with their functional partners.
Seeing the bigger pictureSo if devops alone cannot drive agility in a large, complex organization, what can? As with metrics -- where you must measure what matters, not simply what is measurable -- to drive agility, you need to focus your efforts on where you can get the most business value from time to market rather than where agility is easiest to create.
Start with the biggest business need for improved time to market. Think in terms of customer requirements and work backward. Get creative with technical design, process design, and organizational design.
Very likely, in order to become more agile, you will need to change your technical framework to make it flexible enough to support an agile delivery model. Agility is not just about process; it's about people and technology. Agile means getting out of the box and figuring out how to impart value to your stakeholders as quickly as possible. This requires setting aside historical software development lifecycle models where appropriate. In so doing, of course, you can't afford to neglect quality and sustainability in what is being delivered.
Devops started because operations and development staffers recognized that their organizational model was not working. The basic idea is worthy. But despite marketers' efforts to adopt the term, devops is not a magic pill to cure all of our organizational ills.
Just as with weight loss, only hard work and perseverance can win out in the end. In order to free our organizations of the extra pounds of siloed thinking, which bog them down as they attempt to be agile, we must fundamentally change the ways in which we operate and do our own hard work as leaders. We have to align our organizations around the unified purpose of quality, sustainability, and time to market.
Please join me in banishing siloed IT to the history books. Together we can create far greater value for the business much faster -- and make execution much easier and more fulfilling for our employees. The way to achieve this is by exploiting our most powerful and influential tool: our leadership