What I learned at itSMF-A LEADit

Last week was the annual itSMF-A LEADit conference. Three days of presentations, keynotes, workshops, hot topics and yes, even some fun. But what did I learn in those days?

Firstly that there is nothing new under the sun: ITIL is still ITIL, no new version or revolutionary changes (perhaps AXELOS will provide those in the coming year). No new version of COBIT or any shocking development around any of the other frameworks (AGILE, LEAN, PRINCE2, ..), standards (ISO20000, …) or regulations (governance, outsourcing, …).

The ‘newest’ thing that I personally saw was a presentation on SFIA. Not that that is new, but I hadn't personally been told about a case study of a company actually using it. Great example of mapping less tangible skills (capabilities in ITIL Service Asset terms) onto people and roles, and then managing the gaps.

What was new though, or rather more prevalent than the previous year, was the tendency to do some ‘ITIL-bashing’. In more than one presentation, including a keynote, ITIL was described as old-fashioned, overly rigorous (read bureaucratic) and no longer fit-for-purpose.

Aale Roos in his keynote spoke about ‘unlearning ITIL’ and highlighted several of the idiosyncrasies of ITIL (including the ‘silly’ ITIL v3 Service Strategy publication). He proceeded to explain how the use of the ever-increasing number of processes in ITIL can lead an organisation to be lethargic. He used Nokia as an example and how it failed to quickly respond to the iPhone and smartphone market.

I think Rob England had the right idea by illustrating how ITIL is now at the bottom of the hype-curve (the 'trough of disillusionment'). He lamented that rather than being skeptical of, he found himself in recent times more often defending ITIL.

He continued the picture by showing how dev-ops is currently at the peak of the hype-curve (the 'peak of inflated expectations'). In fact various presentations during the conference highlighted both the need for rapid change, as well as the methodologies that supported this (dev-ops, AGILE .. note NOT ITIL). Case studies for Amazon and Netflix showed their large number of changes and their ability to not only absorb this, but also deal with unfragile systems (not robust, but not fragile either).

This was epitomised by the remark (again from Rob) that it was quicker for dev-ops to put a new version\patch in, than for ITIL to convene an Emergency CAB.

As self-appointed zealot I need to come to the defense of ITIL as in both cases (Aale’s and dev-ops’) it is not so much unlearning or bypassing ITIL, but rather applying it in a practical way. As I have said many times: nowhere in the ITIL publications does it speak about procedure-manuals and how many pages they ought to be. Instead it describes the activities to be undertaken and suggests some rigor to make sure these activities are performed repeatable (for the best outcome).

And the fact that ITIL has more processes now than ever before, doesn't mean there are more activities required (or people, or tools), but it allows each process to be managed separately (from an accountability and reporting point-of-view). If not required, these processes can be easily ‘collapsed’ into a single process(-manual).

It is all about how much rigor  documentation is required, which is dependent for each organisation or even each service. Personally I refer to PRINCE2’s definition of tailoring, which is not about deciding on WHETHER to use any of the theory but on HOW to use it. The level of documentation is then dependent on the size, risk and complexity of the project\organisation\service.

Little side-note: I thought it was comical to, in one of the sessions, see Rob England try to avoid ‘dead cats’ by having an Operations function getting involved in design & test; (i.e. more rigor  and then straight after, on the big stage in a keynote, he is searching for KAMU: a middle-ground between ITIL stability and dev-ops responsiveness (i.e. less rigor).

This is not immediately contradictory  but also not congruent. However I kind of see the point of and agree with both: using Ops-involvement (and sign-off) is great for medium/major changes (on critical services), whilst some of the dev-ops & AGILE principles are more aligned with how Change Management deals with minor or standard changes (with devolved authority and less formality).

So, Aale, we don’t have to unlearn ITIL. And dev-ops and AGILE are just utilising fast-tracked ITIL processes. The basics (of ITIL, of the service lifecycle, and the process-activities) are always applicable, whether you call it ITIL or not (that’s the definition of Best Practice: Common Sense, written down).

ITIL may be at the bottom of the hype-curve, but this is perhaps the time to push it back up to a ‘normalised’ level (the ‘plateau of productivity’), where we can see it for what it is: guidance on how to structure and organise IT activities, in order to deliver value through services to the business. Not a silver bullet but certainly also not old-fashioned.

And here lies the task for AXELOS (and the wider ITSM community) to work towards an ITIL that is more readily applicable. Because I do agree with Aale that some of the sections in the book are ‘silly’, inconsistent and perhaps too open to interpretation. ITIL is never going to be prescriptive, but it would be nice if the next version (4?) was a bit more practical, perhaps with more templates (RACIs etc.) and quick-starts.

And maybe next year there will be more to learn at the conference!

the ITIL Zealot
August 2013