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
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.
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.