ITIL, DevOps and The Karate Kid
Being in the field of ITSM for over 11 years, the shift towards a more Agile DevOps culture seemed troubling to me. My own experience with ITIL and applying those rigid yet valuable processes to well.. everything in Service Management was now in direct conflict with the new kid on the block that rebelled to break the “wall of confusion” and #MakeChangeGreatAgain — yes, the hashtag was intentional; it makes DevOps sound cooler and millennial!
Organisational change swept through and ITIL processes such as the good old Change Management via CABs (Change Advisory Board, not the big yellow taxis) were given the cold shoulder. Blasphemy! The end is nigh! Or so I thought until I came across DevOps’ use of Kanban and Continuous Improvement through Kaizen. Now where have I heard that before? Of course! It was a lesson I partook several years back: LEAN CI (Continuous Improvement) in IT.
Now if there was one thing that shook me in the LEAN seminar, it had to be the fact that I was made to understand nearly 90% of the work I used to do (and maybe still do) was all a WASTE! Yes, you heard that right. LEAN calls anything that does not benefit the customer or the Voice of the Customer (VoC), Wasteful effort. So what about all the processes that ITIL demanded? Were they all just hurdles to reduce an organisation’s change velocity? What value did they add to the customer eventually? You can see how my world was crumbling down. My world of 11 years in the ITSM space, delivering and further enhancing ITIL for a leading global Telco was synonymous with a House of Cards — Kevin Spacey included (pun intended)! The more I thought about this, the more resistant to change I became. I pretended DevOps was a farce; an entitled kid screaming for candy from every passing shop. Until I recalled this:
There came a moment in my career (recently) where I had to prepare an entire DevOps approach for a response to an ITT (Invitation to Tender). Regardless of how much I tried to force standard ITIL for ASM (Application Support & Maintenance) into the response, my seniors were not having it. I mean, I was a demigod (look at me being all pompous) at ASM and anything Ops related. I built accelerators and frameworks to uplift our entire ASM practice. We bagged multiple projects courtesy of our cutting-edge ITIL processes and accelerators. And now, to be told that vanilla ASM was just so.. vanilla?! (OK, I like vanilla as a flavour on ice cream, not on my life’s work!) This could not be happening to me! So I took a day to introspect and give DevOps a chance. The more I deciphered the slogans it preached, the more intrigued I grew — That machine gun was starting to look a little shinier than my sword and it caught my eye.
The behavioral changes required to become truly agile and continuously deliver good product caught my attention. I started seeing the “wall of confusion” with ITIL; the “it’s someone else’s problem” notion that kept bugging me with team silos. I started comprehending the concept of a Tribe, a Squad, a Guild.. I love medieval fantasy by the way and this lingo seriously struck my inner chord. A few days later, my DevOps proposal was done. Did I eliminate ITIL entirely in favor of a cutting-edge DevOps solution? Not in the slightest. I ended up drawing up a proposal to introduce ITIL’s archaic policies into a DevOps CI/CD pipeline — Face-palm! A week later, I had to create an entire presentation for a CIO on.. you guessed it — DevOps! I took it to heart and studied the topic further. Why do I keep going back to ITIL? Finally, when I was done with my masterpiece, I had a long cold stare at it. I noticed a change. Nothing major, however just the slight brush of deviation from my previous proposal. I had factored a few key elements of ITIL such as Event Management (now termed Continuous Monitoring) and Major Incident Management into the DevOps workflow. Even more captivating was the fact that I managed to fit in the accelerators I architected for ITIL into the DevOps world. Have I created a blasphemous hybrid creature like in one of those horror flicks?
Today, I realise that little changes gradually improve the overall product — This takes me back to the Karate Kid scene: Wax On, Wax Off. Just like the iterative development and Fail Fast approach it introduces, I have begun my own iterative journey towards DevOps. A little bit of the new approach rubs onto me with every little swipe I take at it. What about ITIL? There is no way I can ever let go of it nor is there a need to. DevOps and ITIL can co-exist. ITIL forms the strong base to spring forward into a DevOps culture. ITIL principles such as Incident Management for example, provide squads with guidance towards a “best practice” to follow during times of in-life disaster. A best practice — now that rings better. After all, ITIL was always meant to be a best practice with an aim to Continuously Improve as opposed to a rigid process imperative.
I shall write about the specifics where I draw parallels between the two in future publications each time I come across such situations. I guess I am on my own journey to #MakeChangeGreatAgain. Are you?
