ITSM’s own “DevOps renaissance” won’t come from copying DevOps

In his book Toyota Kata, Mike Rother described the bemused reaction of Toyota executives to his repeated study visits to their manufacturing facilities:

Toyota opens its factory doors to us again and again, but I imagine Toyota’s leaders may also be shaking their heads and thinking, “Sure, come have a look. But why are you so interested in the solutions we develop for our specific problems? Why do you never study how we go about developing those solutions?”

I often feel ITSM community is prone to making the same error with DevOps.

For instance, let’s consider a common starting point for ITSM organisations that are seeking to align better with DevOps practices: the optimisation of the change approval process. DevOps has actively reduced the risk and distrust of changes via its relentless focus on test and deployment automation, and through is practice of making small, incremental updates. Many ITSM functions have taken the opportunity to embrace this inherent trust, and have reduced or removed their demands for change validation. This has smoothed the path for DevOps, and that’s no bad thing.

However, once this step is taken, Change Management still exists, fundamentally, as it did before. It might be leaner, and the improved practices of others are unobstructed, and maybe even augmented. Nevertheless, can this truthfully be called a transformation?

The DevOps movement, like Toyota before it, solved its own problems by creating a wholly new vision, and a new set of practices and tools to deliver it. To get there, it first needed to develop the capability to do so. DevOps was a deconstructive movement.

Building on the radical foundations of the Agile movement, DevOps painstakingly dismantled and reinvented software’s journey from inception to development to production. This needed cultural change to drive trust, collaboration and autonomy, accompanied by a major retooling of the production line to drive the necessary advances in testing and deployment.

This is a stupendous achievement, because history shows us that breaking industrial norms is as difficult as it is rare. In his excellent book “Making Light Work”, the technologist and work psychologist Peter Johnson describes the phenomenon of Social Constructionism:

“An idea or viewpoint becomes so deeply embedded in a culture — a society, organisation or industry — that is accepted as fact… Where there is limited availability of opposing ideas, individuals within a society may view the constructions as self-evident truth”

Software production was full of these constructions, and breaking them can not have been easy. DevOps certainly did not find unanimous support. At the 2018 devopsdays conference in Kiel, a startup founder told me of the problems he had experienced when embarking on his DevOps journey. “This is not professional”, was the constant retort from his newly hired senior engineer, schooled in the Computer Science syllabi of previous decades. Incremental changes rather than monolithic design-and-build? “Not professional”.

But nevertheless, less than a decade after Patrick Debois made his now iconic Agile Infrastructure presentation, DevOps had become a fixture even in large enterprises. And even though its progress into the larger enterprise is sometimes awkward, the fact that the DevOps movement itself is built on the establishment of new capabilities (and the radical reshaping of the workplace around them) makes it well placed to succeed.

But where is ITSM? There are major initiatives up and running, and each is impressive in certain ways, but none are radically deconstructive. IT4IT brings credible new thinking with its value chain analysis, bringing a broader encapsulation of the real business objectives surrounding what ITSM does. VeriSM is very well put together, but is openly designed to incorporate practices such as DevOps, and to optimise service management around them. ITIL Practitioner was a clear (and perhaps surprising and refreshing) example of service management building on many of the learnings of the Agile and DevOps movement, with good effect. ITIL itself is also getting a significant rebuild, but will this be truly transformative? When will ITSM successfully tackle its Social Constructionism?

The ITSM community has itself embraced many of the learnings of the DevOps movement, often with enthusiasm. There has been wide acceptance of the need to be more agile (perhaps itself a new social construction!), to iterate and automate and break silos. Much of this will be beneficial. But in only going this far, ITSM is not developing its own new knowledge: it is merely applying the findings built on the acquired new capabilities of others.

However, it is my contention that IT Service Management has not yet embarked on its “DevOps renaissance”. Alignment is an interim measure at best. Perhaps it is now time for ITSM to tear up its norms and learn new ways to rebuild from the rubble. Doing so from its established position in the enterprise, however, may be more a tougher challenge than that faced by the pioneers of DevOps.