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
August 2013