Does successful change management require DevOps?
DevOps offers organizations valuable change management principles and practices — but it’s not the only solution when it comes to change management. Organizations should feel free to learn from DevOps best practices to boost change enablement, without being married to a specific framework.
Around the world, digital product providers are looking to reduce dysfunctions that impede business continuity and accelerate value creation. Most have turned to DevOps, or are in the process of turning to it. Business leaders prize DevOps for its ability to facilitate rapid change management with minimal risk of disruption. For example, high-performing DevOps organizations can deploy code 208 times more frequently than low performers.
But is DevOps the only way for organizations to adapt to an accelerating business environment increasingly defined by change? Not necessarily. There are many ways to approach software, platforms, and digital services that aren't technically DevOps. Moreover, there is a lot of disagreement on what exactly DevOps is.
However, organizations should recognize DevOps’ strengths vis a vis change management. Any alternative approach should offer similar strengths. Short of that, IT leaders interested in product stability and continual value creation should look to the technical aspects of DevOps practices to influence their own.
You don't have to call what you have 'DevOps', but you should seek to correct the problems DevOps solves — which are what prompted so many to embrace it in the first place. What is most important is not only having the DevOps-offered controls in place. It is also the best practices that encourage collaborative value creation, while establishing a continuity of accountability, that breaks down organizational silos.
How DevOps helps enable value creation through change
The chief value embodied by DevOps is a collaboration between development and operations teams — it’s in the name! The classic sideways eight diagram illustrates that each process follows the next. The two teams are intertwined, helping to both facilitate and create change, all while sustaining its value. The collaborative DevOps approach removes common bottlenecks, and also demonstrates that developers have a stake in IT operations concerns, especially when it comes to production errors and defects.
This guide to DevOps illustrates the types of issues DevOps can solve:
- "Dev is often unaware of QA and ops roadblocks that prevent the program from working as anticipated."
- "QA and ops are typically working across many features and have little context of the business purpose and value of the software."
- "Each group has opposing goals that can lead to inefficiency and finger-pointing when something goes wrong."
Integrating processes both conceptually and technically prevents situations where a change failure or deployment bottleneck seriously jeopardizes value creation and business continuity.
Such a situation is easy to imagine: A bug is identified, and ops says that dev provided them with faulty artifacts. Dev points out that everything worked well in the test environment. Debugging fire drills begin, with ops spending all night fixing production issues since the production environment isn’t development’s and QA’s responsibility.
DevOps helps avoid this situation. Joining the efforts of the two silos and encouraging the use of feedback generated by operations promotes accountability and improved product quality.
DevOps also addresses the shortcomings of older approaches like ITIL. While ITIL puts specific roles and processes in place, it doesn't always efficiently address persistent problems. Critics of ITIL note that it creates “the illusion of control that results in [the] organizational delusion that IT is efficient and manageable.” Silos persist in this framework, along with “‘not my problem’ attitudes.”
Difficulty assigning accountability isn't inherently an ITIL quality, but the reality of many ITIL-focused organizational structures is that they are preoccupied with repeating established processes rather than committed to improving them. The work itself becomes the goal, whereas in DevOps, the goal is continual product improvement enabled by the most efficient processes available.
Is DevOps in the eye of the beholder?
Ultimately, removing divisions between dev and ops makes sources of negative value (e.g. problems, delays) more visible. It also helps reveal how problems should be solved and who should solve them.
But while the ideals and goals of DevOps are universal, no two DevOps organizations look alike. Each one has its own optimized process in place at every stage. Furthermore, differences in product and goals will mean that one organization's use of DevOps will vary dramatically from another's. Yet many business and IT leaders would look at the two and declare that both are using some form of DevOps, given specific qualities that indicate so.
It’s also important to remember that adopting DevOps in principle is not the end-all and be-all of getting rid of waterfall-style bureaucratic management. Many business leaders still regularly implement cumbersome change management processes within a DevOps framework.
Given this trend, project management and ops teams might argue for keeping a tight grip on software development processes to avoid bad code in production, as Diginomica notes. But in fact, implementing more controls within the DevOps workflow often results in “bottlenecks, delays, and backups — all of which lead to bigger, less frequent, and higher-risk releases that contribute to higher change failure rates."
Further, as the 2019 State of DevOps reports notes, "those that use heavyweight processes are 2.6 times more likely to be low performers."
Any DevOps vs. no DevOps debate may be considered a red herring, given how many variances exist within the DevOps world. Being “DevOps” isn’t an end unto itself. What matters is focusing on the goal of change enablement and adopting practices to facilitate it as efficiently as possible.
Some organizations and products might not benefit from DevOps
There has been plenty of contentious debate about which kind of organizations or products might not benefit from DevOps. A common assumption is that innovative applications need DevOps, with very few exceptions. "The general consensus is that organizations that are using software — particularly the development of apps — to innovate in their sectors, should be looking at implementing a DevOps culture," as one journalist wrote a few years ago.
Tech pundits do offer some examples of outliers, however. For example, a PaaS supporting other software companies might be improved through DevOps because it mitigates bottlenecks. A CIO at insurance company AVIVA argues that DevOps is a must for small startups, while big organizations may want to hold off on adopting the approach. “Smaller companies and startups have no option,” the CIO writes. “Fungible roles, extreme automation, and everyone pitching in is the norm. This is how they get features into the hands of customers at pace. But that organizational agility is something that large companies struggle with.”
However, when considering whether DevOps might be "right" for your organization, it’s important to avoid an all-or-nothing mindset. Any organization can consider key DevOps concepts, workflows, and best practices in isolation — whatever best suits the business’s goals.
What's not really up for debate is having clear processes, accountability, and automation whenever possible. Priorities include rapid creation, integration, and deployment of stable value-producing changes.
For change enablement, learn from DevOps best practices but don't feel controlled by them
Because of fluid definitions and real-world use cases, DevOps isn't one fixed "thing," just as agile isn’t one fixed thing. Rather than being all about specific practices, DevOps is at its core a “cultural change towards accepting the norms of agile software development, paving way for continuous development cycles, keeping in mind the cross-functions, responsibilities, and goals shared with IT operations," as one writer puts it.
IT leaders can remember to prioritize the effects of DevOps in practice, rather than an adherence to a set of highly specific principles. When evaluating whether a system offers practical change enablement, look for the signs of successful continuous delivery — such as "teams being able to deploy changes on-demand to production, the deployment of quality feedback is made available immediately, and teams can then quickly act on that feedback to improve the next cycle of deployment."
Another positive sign is developers checking into the version control system regularly. “[T]hat event should automatically kick off a build and a battery of automated tests,” according to TechBeacon. “If the build or any tests fail, the team should be alerted immediately."
Evaluating a process based on the data it generates and metrics that indicate fluid change enablement can allow IT and organizational leaders to optimize their working system over time.
The bottom line: maintain visibility, and have all stakeholders informed of roadblocks to value creation. Data analytics can help with this goal, but organizations need a conceptual framework to base practices and workflows around — whether it's called DevOps or something else.
For more information on DevOps and change management, watch our recent webinar: "DevOps & AI: Do we still need ITIL change management?"