How to solve the DevOps vs. ITSM culture clash

Declare a truce between ITSM and DevOps within your organization by learning these lessons.
135 readers like this.
a handshake
Image by:

opensource.com

Since its advent, DevOps has been pitted against IT service management (ITSM) and its ITIL framework. Some say "ITIL is under siege," some ask you to choose sides, while others frame them as complementary. What is true is that both DevOps and ITSM have fans and detractors, and each method can influence software delivery and overall corporate culture.

Clash of cultures

More DevOps resources

The heart of the DevOps and ITSM culture clash comes down to ITSM being process-intensive, to the point of hindering business when organizations build more people- and technology-intensive processes to launch products and services. Small to midsize enterprises sometimes drown in the minutiae of ITSM, while large enterprises can overbuild when the bureaucracy ham-fistedly puts ITSM before customer delivery.

DevOps brings promises of agility and velocity for software delivery that are attractive to organizations of all sizes. The theme of continuous delivery paints a nice picture of internal transformation and rejuvenated customer focus for organizations still slogging through clunky and outdated waterfall and waterfall-derivative software development lifecycle (SDLC) processes.

Resolving the culture clash

It's important to declare a truce between DevOps and ITSM, when you can, by doubling down on visibility into software development, operations, and support. Steer away from the "old vs. new" or "fast vs. slow" arguments that invariably erupt when teams argue over the virtues of DevOps and ITSM.

Reining the conversation to the project, software delivery, and the team can be difficult, depending on the personalities you're dealing with. In those cases, it's time to take the religion out of the conversation by focusing on collaboration, monitoring, and reporting. These are the principles that support product and services delivery, whether you follow ITSM or DevOps.

Taking a consultative approach to making process changes is key to avoiding culture clashes. Seek participation and input from your development and operations teams about any process changes you intend to make that might alter the way they work.

Lessons learned

While some recent articles have endorsed the coexistence of ITSM and DevOps, many of us have moved past the conversation about ITSM because of the growing need for agility. Some ITSM principles outside of the service desk will remain, but they will be subsumed into DevOps delivery processes. In the IT industry of 2020, it's increasingly important to be agile and able to pivot to counter market demands. DevOps is built to pivot. ITSM doesn't have a reputation for pivots.

There are some important lessons to learn from the great ITSM and DevOps culture clash, including:

  • Information and reporting about the software development process continue to hold critical importance for developers and other stakeholders across companies.
  • DevOps cultural transformation remains a challenge for those familiar with ITSM, and it raises the stakes for culture change inside some enterprises.
  • ITIL's slow development from v3 to v4 gave DevOps, GitOps, AIOps, and others room to advance in a way that organizations began to adopt.
  • Collaboration should be the rule of the day in modern software development. DevOps tells a better collaboration story than ITSM.
  • Both DevOps and ITSM require a professional and consultative implementation approach.

What are you doing to solve the ITSM vs. DevOps culture clash inside your organization? Please share your strategies in the comments.

What to read next
Tags
DevOps
Agile
Will Kelly
User profile image.
Will Kelly is a product marketer and writer. His career has been spent writing bylined articles, white papers, marketing collateral, and technical content about the cloud and DevOps. Opensource.com, TechTarget, InfoQ, and others have published his articles about DevOps and the cloud. He lives and works in the Northern Virginia area. Follow him on Twitter:@willkelly.
More about me

4 Comments

Avatar
Timothy Shaw | March 2, 2020
No readers like this yet.

Actually, we human are responsible to set boundaries and afterwards not following this completely. A big concern in IT companies are Jargons which we heard in different departments. It's better to develop an open platform where people share their ideas.

Avatar
Adonis Tarcio | March 2, 2020
No readers like this yet.

I think a big problem between DevOps and ITSM is that for security ITSM is better for compliance and accountability which ties to the long and boring processes involved on that.
It's important to be Agile and fast delivery and stuff until something goes wrong and fingers need to be pointed at and find a culprit. Unfortunately most people don't want to take responsibility and having processes in place helps with the matter.

Avatar
Luke Rawlins | April 20, 2020
No readers like this yet.

ITSM is better for accountability. However, it's unfortunate that in many ways "Change Management" is really just another term for "Blame Management". I use a lot of "DevOps" tools, but much of the DevOps culture seems a bit too Wild West for me to be comfortable with it, so I hold onto and try to incorporate ITSM where I can.
I guess there are problems either way when people insist on one or the other.

Related Content

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.