Monday 2 May 2016

THE NEW STEADY STATE IS CONSTANT FLUX

A few weeks ago I read Mark Smalley’s‘Kill DevOps’ on the back of a year of increasing interest in Devops, in particularly when compared to the slow-and-steady ITIL.

Mark finished his article with ‘The only desirable steady state is a constantly evolving state of mind.’ And thus rejecting basically any system or methodology, including DevOps which embraces change like no other.

And that got me thinking: do we need stability (for which we often strive)?

Human nature often makes us conservative (maybe along the lines of ‘better the devil you know?’).
A majority of people prefer the status quo, the familiarity of the existing practices, the security of knowing how to do something.
From an organisational point-of-view stability is also preferred. Very few business models welcome surprise and change and are normally based around a status quo (which can be expanded, enhanced or sometimes just maintained).
Even CSI, which is in essence continual change, is based on improving SOMETHING that is more-or-less stable, that can be benchmarked and baselined; and from there to improve efficiency & effectiveness of the status quo.

In fact many of the best practice concepts around Service Operations, are based around BAU (or Business As Usual). By thorough design and testing we avoid any surprises in operations, thus enabling us to deliver a dependable, repeatable (, measurable), guaranteed service … day-in-day out … the same every time.
Based on the renowned Ivor McFarlane I often explain the Operations is supposed to be a boring place to work and that as an Ops Manager, if your staff gets excited … you should get worried!
Or I use a fast food chain as an example of a process based organisation, where everyone (almost regardless of past experience) can create the same quality food (using the term lightly), anywhere on this planet!

But those later ones are certainly not attractive examples of stability: boredom and fast food do not rank particular high on most people’s wishlist.
And thus despite our preferences, we are looking for change, for excitement, for new experiences, new horizons … a bucket list to work through before the eternal stability of death reaches us.
DevOps advocates rapid change and Disruptive Technology hardly preaches a dull and secure application.

So, which one is it: the security of stability or the excitement of change.

As per usual the answer lies in the middle, a bit like bi-modal IT, merging DevOps and ITIL, having your cake and eating too, having the best of both worlds.
I think chaos is change without a solid foundation, thus neither improving nor deteriorating the situation (which BTW makes chaos a constantly changing status quo … ooh, that’s deep).
Stagnation on the other hand is stability for the sake of stability causing dogmatic, micro managed often overly-bureaucratic organisations.

I can accept that change is inevitable and that potentially change is a good thing (as good as a holiday I’m often told!). But not all change and not change for change’s sake.
I see benefit in distinguishing improvement (the same but better) and innovation (different) and both will need a place in a mature Service Management organisation.
It is true that ITIL does not really deal with innovation (a bit in CSI, a bit under ‘new technology’ in Capacity Management), but neither does DevOps (or COBIT or pretty much any best practice that I know of). And where DevOps supposedly signifies the death of ITIL, Mark poses that ultimately DevOps needs to die as well to keep changing/improving/innovating/evolving.

Ultimately everything must or will change, including ITIL and DevOps, but I don’t think we need to actively euthanise either of them (just yet).
Rather (and as always) we need to apply the common sense guidance of either methodology (, framework, or whatever you want to call them) where and how it applies best; and make sure you have the right objective in mind (, business goals, value, again many terms that can be applied here). If there are ‘blindspots’ (like innovation) than make sure you augment your organisation with the necessary structures to fill these in.
For innovation specifically ‘Google time’ comes to mind (20% of time spend on ‘personal’ projects, which got abandoned in 2013), or something I picked up as 7x7x7: 7 ideas are given $7,000 to work on for 7 weeks. This keeps the wildly creative and anarchical innovation within defined time (7 weeks) and budget (7x7=$49,000) constraints and cycles.

So, let’s embrace change but makes sure we have a clear understanding of the direction of this change. After all ‘let’s go left’ only makes sense if you know where you are and where your destination is!
And let’s not blame our ‘system’ or methodology for the lack of innovation but instead make sure innovation is covered within the system (and yes, that includes innovation OF the system).

Onwards and upwards!
(to boldly go …)

the ITIL Zealot
May 2016

No comments: