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.

However, organizations should recognize DevOps’ strengths regarding change management practices. 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.

Why is DevOps so popular for change management?

DevOps is a popular framework utilized by businesses the world over. An early 2021 survey found that 74% of organizations have adopted DevOps or are in the planning stages. Business leaders prize DevOps for its ability to facilitate rapid change management with minimal risk of disruption. High-performing DevOps organizations can deploy code 208 times more frequently than low performers.

One major reason DevOps facilitates fluid change management is that it is structured as a cycle. New changes are, ideally, committed through an ongoing process of continuous integration and continuous deployment (CI/CD). Process optimizations reduce friction between team handoffs, helping to decrease change lead times. Operations data also informs release priorities, potentially addressing the factors that tend to lengthen QA and other pre-deployment reviews.

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.

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.

DevOps enables value creation through constant change deployments

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.

Our guide to DevOps illustrates the types of issues DevOps can solve:

• Development becomes more aware of the issues that delay QA and deployment
• QA and operations departments become more-aligned with the business purpose and intended customer value created by the release
• Development and operations cease working at opposing goals, which can otherwise lead to inefficiency and finger-pointing when something goes wrong.

Integrating processes between development and operations prevents situations where a change failure or deployment bottleneck seriously jeopardizes a release timeline. 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 change management 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.

Some companies or products might not benefit from using DevOps for change management

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.

Tech pundits do offer some examples of outliers, however. For example, a PaaS supporting other software companies might improve its change frequency by using 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 adopt 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. Regularly updating products with value-producing changes is the priority, so the process of rapid release creation, integration, and deployment should reflect this.

Many change management processes leverage DevOps principles (even if they don’t call it DevOps)

Ultimately, removing divisions between dev and ops makes sources of diminished value (e.g. problems, rework, delays) more visible. When development and operations teams collaborate, they will also be forced to formalize the process for 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 the specific qualities of their process.

It’s also important to remember that adopting DevOps in principle will not automatically hasten change deployment velocity. Many business leaders still regularly implement cumbersome change management processes within a DevOps framework.

In this case, project management and ops teams keep 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.”

Remember that, whether implementing DevOps or another methodology, what matters is focusing on the goal of change enablement and adopting practices to facilitate it as efficiently as possible.

For change enablement, learn from DevOps best practices but don’t feel controlled by them

Because of fluid definitions and differing use case environments, DevOps isn’t one fixed “thing,” just as agile isn’t one fixed concept. 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 change management 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. One positive sign is when teams are “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.