Let’s begin with some of the key coordinates in the recent trajectory of DevOps growth as reviewed by various industry analysts and studies.
For one analyst, 2017 was the year of DevOps as the concept achieved “Escape Velocity”, implementations hit 50% and the conversation finally shifted from “What is DevOps?” to “How do I implement at scale?”.
Then there was a 2018 survey from Harvard Business Review Analytic Services that found that nearly two-thirds of respondents used DevOps and around a similar proportion corroborated the key benefits of the approach in terms of speed to market, productivity, customer relevance, innovation, and product/service quality. However, only 10% of respondents claimed success at rapid software development and deployment, an outcome that 86% deemed important.
By 2019, the proportion of elite performers had almost tripled, to 20% according to the State of DevOps 2019 study from DORA/Google Cloud. But the gap between the leaders and laggards was widening; in comparison with low performers the elite group was shipping (106 times) faster, deploying code (208 times) more frequently, recovering from incidents (2,604 times) quicker and achieving a (seven times) lower change failure rate. The report also featured a stark warning for engineering organizations - Excel or Die.
SOURCE: DORA/Google Cloud
If that wasn’t grim enough, there then came a Gartner prediction that 75% of DevOps initiatives would fall short of expectations through 2022.
DevOps has been a practice with so much perceived and proven potential that it has since sparked off a flurry of portmanteaus extending the concept to BizDevOps, SecOps, DevSecOps and even NoOps. So how did all this potential get eclipsed by such dire predictions of conditional mortality and large-scale failure?
Most DevOps studies and expert opinion pieces over the years, including the ones cited here, have counseled that DevOps adoptions cannot simply be treated as just another technology project. For instance, Gartner emphasizes the prioritization of people-related challenges over technology and HBR advocates a catalog of changes - to staffing, organization structure, performance management and culture - that essentially transform an organization.
Here, then, are some of the most common non-technological drivers of success (or failure) for large-scale DevOps adoption in any organization.
Defining the business value of DevOps
As with every new technological methodology, it is easy to mistake the deployment of DevOps tools and automation as a proxy. It is true that these tools can significantly transform the pace and quality of software delivery in most organizations. It is also true that, generally, adoption of more toolsets across the full lifecycle yields more progressive outcomes.
But businesses need to identify, anticipate, and deliver DevOps outcomes and value in quantifiable business terms. Every DevOps initiative has to be backed by a clear definition of the value it will bring to both employees and customers. At the end of the day, tools are just enablers; the ongoing focus has to be on the value that these tools can deliver and their impact on business performance. To quote Gartner, leaders who decide to do DevOps for DevOps' sake risk failure.
Managing organizational & cultural change
According to a 2019 DevOps research report from analyst firm EMA (Enterprise Management Associates), the primary reason for decreasing or static DevOps productivity was the demands that the methodology placed on cultural change.
SOURCE: Enterprise Management Associates
DevOps success will be defined by an organization’s capability to enhance communication, collaboration and coordination across a diverse set of stakeholders including software developers, operations, QA and business executives. This involves a radical cultural shift that has to be initiated based on a clear understanding of the processes that define the development and delivery of software as well as the intergroup dynamics between all the stakeholders.
The primary challenge of effecting cultural transformation is the resistance to change. People are inherently resistant to any large-scale change that substitutes tried and trusted processes with a radically new approach. Business leaders need to communicate the need as well as the value such a transformation will have on employees, customers and business performance. Change management strategies should also focus on providing employees with a clear path to the new state and offer new learning opportunities that move them forward.
Promoting cross-functional collaboration
The primary challenge here is to realize and streamline productive collaboration between the development and operations teams. DevOps success, however, is not just determined by the quality of interactions between these two core groups. A failure to partner with the business can also have an adverse impact on the DevOps value over the long-term.
Today, every company is a technology company. Technology teams, therefore, shouldn't just be aligned or integrated with the business; they are the business. It therefore makes sense that DevOps is evolving into BizDevOps, DevSecOps etcetera as more and more businesses recognize the need to integrate various thus far isolated functions and domains under a unifying mandate to enable better business outcomes for the organization.
According to findings from the EMA report, less than half of all DevOps interactions are currently seamless, with 15% even being classified as “confrontational.” The important takeaway, however, is that organizations that have achieved seamless or even near-seamless interactions are more likely to be successful in terms of delivery, performance, and value.
Mistaking velocity for value
A big-bang training-on-Friday-launching-on-Monday approach to DevOps adoption is a recipe for failure, especially in large organizations. Rather than trying to implement an end-to-end solution from development to production, companies need to focus on launching with one first mover application that has buy-in from all stakeholders, represents and promises adequate value.
Similarly, any approach that prioritizes velocity or time-to-production as the key performance metric runs the risk of letting quality fall by the wayside. Speed and quality are both essential DevOps values, and, as the DORA/Google Cloud highlights, metrics such as speed, reliability, stability and availability have to be seen as outcomes that enable each other rather than as trade-offs.
Done right, DevOps can facilitate improvements across all key metrics. However, achieving that grade of performance requires a level of DevOps maturity that not many businesses can claim to possess. Currently, most DevOps teams tend to measure velocity, with business value in second place. However, this ranking is forecast to be reversed this year as business value takes precedence over other preferred metrics.
Managing DevOps expectations
Implementing DevOps will not automatically eliminate information silos, transform organization culture and recalibrate the SDLC. Unrealistic expectations, currently ranked last on the list of factors that slow down or stall DevOps productivity in the EMA report, can have a significant impact on success, not to mention team morale. Expectation management, therefore, has to be a central component of any successful DevOps transformation strategy.
The first step to managing expectations is to agree on a set of concrete, measurable goals that can demonstrate whether the transformation is adding value. These expectations will also evolve over a time alongside DevOps-related goals.
The EMA report identifies a number of characteristics that define successful DevOps transformation. For instance, factors such as diverse stakeholder involvement, DevOps decentralization, robust ITSM/DevOps integration and wider deployment of APM solutions, etc. all have strong correlations with DevOps maturity and success. However, none of these factors will really matter unless a DevOps transformation strategy is founded on high-level values such as seamless collaboration, managed cultural transformation, focus on business value, choice of relevant metrics and realistic expectations.