This month I participated in our
local itSMF branch seminar. As it was the last quarter of the year, we were
already a bit in the Christmas mood and as it is called the silly season we
tried to make the content light and entertaining. To this regard there were 4
IGNITE session. This is where each speaker has a limited number of slides (in
our case 20), which auto-forward (in our case after 30 seconds) so that the
presenter has not control over the presentation behind him/her. And by asking
the speaker to present not only in this format, but also in a more polarising
way, we kept it quite entertaining.
But in addition we also introduced
two DEBATEs. I’ve used this format in my training whereby the candidates are
either in favour or against a statement (like ‘outsourcing will make all our
problems go away’ or ‘you should always charge for a service’). This makes them
think about all the arguments in favour, but also the weak spots of these
statement and phrase there position and rebuttal accordingly.
For the itSMF seminar each team (for
or against) presented an IGNITE (although the more traditional 15 slides and a
20 second auto-forward), and then a rebuttal. The debate topics were:
- Chicken or Egg, what comes first: process or tool
- Traditional Service Management vs. Dev-Ops.
I was on the latter debate,
obviously defending traditional service management. My role was to present our
case through the IGNITE, and I’ll provide a brief synopsis of that. To this
effect I’ve shared my slidedeck HERE.
I first [slide 2] narrowed the
debate down to ITIL vs. Agile and decided that a battle of this magnitude could
only be properly debated, explained, reflected by using that other epic battle
of good vs. evil: Star Wars!
No doubt that ITIL takes the role of
the Jedi here [3]. The ancient, ruling order, steeped in mystic, historical
processes but in essence a democratic society for the common good.
Agile on the other hand has more
similarities with the Sith [4]: powerful, challenging the ruling order, using
emotional, rash decisions (over rational, risk averse ones) and attractive to
young padawans/developers.
A good example was the Deathstar [5],
a somewhat rushed project that contained a fatal flaw, causing it to blow up
with considerable damage to the customer (the republic).
So, what did they do: they build
another Deathstar, with the same flaw and put it into production before it was
even completed. No surprise then, it blew up again, with even more devastating
customer impact (victory to the rebellion).
In my opinion, a lot of this has to
do with perception [7, yes I skipped 6 which only served to further focus on an
apparent lack of planning with Agile]. You see, Dev-Ops or Agile is currently
at the height of the Gartner Hype-curve. In the minds of some people it can do
no wrong, and should be used for everything and anything.
ITIL on the other hand is done the
bottom of the curve, in the ‘through of disillusionment’. Many organisation
have tried and perhaps not achieved the results they were hoping for. Now they
are throwing out the baby with the bathwater, completely rejecting any of the
common sense best practice IT Service Management approach that ITIL describes.
To a large degree I think this is
because of the perceived bureaucracy that ITIL introduces [8]: processes,
procedures, templates, workflows, … everything needs to be documented, reviewed
& approved.
Perhaps so, but ITIL never actually
identifies how complex, wordy, lengthy or formal these procedures need to be.
Or even whether they should be written down at all.
More important is to understand WHY
something needs to be done (rather than how) [9]. PRINCE2 (from the same best
practice stable as ITIL) actually identifies tailoring as a must for every
methodology and that tailoring is not about whether to use it or not but about
how (formal) to use it. This is driven by factors of size, risk &
complexity.
Change Management is a prime example
[10]. This often becomes a bureaucratic bottleneck, because people focus too
much on the formalities, paperwork, CAB meetings etc.
The ITSkeptic told at the Australian
itSMF LeadIT conference, how one dev-ops engineer exclaimed that he could but a
new version in production, ‘before you could get an Emergency CAB together’. That
last statement doesn’t leave me with a lot of confidence, in particular if it
was a mission-critical service/application we are talking about here.
Instead we should focus on the real
goal of Change Management, which is to minimise impact. ‘Horses-for-courses’:
sometimes you can go slow and secure, other times you need to go quick, but you
better wear a helmet!
And Change Management accommodate
the Dev-Ops concept of ‘failing fast’ [11] through defining different
categories of change, each with their own level of documentation, assessment,
approval and oversight.
- The Emergency (or ‘oh-shit’) Change means we don’t throw caution to the wind, but instead apply a different, faster, less rigorous process (basically we decrease time, but increase risk)
- The Standard Change allows a cookie-cutter approach to frequent, repeatable change, which will significantly reduce overheads
- And the use of ‘minor’ Change categories will allow a less convoluted path to be followed, whilst still maintain the appropriate governance.
The key here is no to be afraid of
failure, but also not to close your eyes to the risk [12]. Mistakes are part of
everyday life, and in fact mistakes are essential for growth, improvement and
innovation. I call this the concept of making ‘deliberate mistakes’ [13].
So in our battle of Dev-Ops vs.
Service Management, we find that ITIL actually incorporates everything that
Agile is trying to achieve. But then, it does much more, allowing for both fast
and slow changes; and with a lifecycle that includes Strategy & Operations
(as well as Design, Transition and Improvement) [14]
Thus there can be only one outcome,
and the (ITIL) Jedi must win [15].
But perhaps rather than looking at
Star Wars as the fight of Luke against the Empire (and his father) of the first
(now the last) three episodes, perhaps we should encompass the whole (6
episode) series as the lifetime of Anakin Skywalker (from good to bad, and back
to good): In Anakin we find good and bad, jedi and sith, passion and ration,
similar to how Dev-Ops and Service Management attempt to achieve the same goal
(-better- value of services) through different approaches [16].
As long as the good side wins in the
end!
(May the ITSM force be with you)
the ITIL Zealot
November 2013