The IT Skeptic has a day job, consulting on IT topics including ITSM (not "consulting on ITIL", oooh no, perish the thought! That's not allowed without an official OGC licence and the payment of tithe). In recent times my advice to clients has been to take a more granular - dare I say "agile" - approach to ITSM. I'm rolling this out in a formal methodology called Tipu (which I am presenting for the first time today to the local itSMF chapter).
That's why it was good it is to see Elizabeth Harrin talk sense about taking an agile approach to ITIL.
I've been taking this approach with clients for over a year now. One thing I would add to Elizabeth's article is that it is about ITSM not ITIL. ITIL is incomplete: there are many other areas you need to consider. c.f. COBIT although that too is incomplete. USMBOK is about as complete as anything ever will be.
The basics of an agile approach to getting things done center around prioritizing features, and deploying things in a timely way.
Basically, in a service management environment, this translates into splitting your ITIL implementation up into chunks. Pick the most important processes first. Then set a date for when you'll have something deployed relating to that process and work to it. Breaking the deployment of ITIL into smaller pieces ensures that you can deliver some quick wins, and start seeing the benefits early.
Once you have your ITIL implementation up and running, you can add new processes using the same approach, as well as amending existing processes to improve the service. This keeps the momentum going and allows you to build organically on existing capability.
It's important to understand the processes, because in order to implement something the agile way, you need to split it up into smaller pieces. This gives you a step-by-step, iterative approach instead of a big bang ITIL deployment.
Why is small good? When it comes to making changes, it is often easier to bring people along with you when they only have to adopt small changes at any one time.
Unfortunately there is too much assumption that you "do Change" or even worse "do ITIL". It's in the core books, it is in official other books like ITIL Lite, its in most consulting models, its all over the Web.
Where I disagree with Elizabeth, and with the official ITIL books and so many other sources, is that the unit of work is not the ITIL "process". ITIL processes aren't Lego blocks. If we want to scale ITIL down to an "ITIL Lite" it should be by doing less of everything not by leaving whole practices out. I like the phrase "level of ceremony" - I'm not sure where it originates. You don't "start with incident management and then do problem". Building our efforts around discrete complete processes is a cause of ITIL adoption failure and ITIL’s bad name. You need a little of this and a pinch of that, stirred into a solution to a business problem, need or risk. To do this, we need ITSM broken up into smaller, more useful, more manageable chunks.
Tipu does that. Here's the method:
- Identify the key business requirement (need, problem, risk). Prioritise the chunks of ITSM to meet those needs, and start on a parcel of chunks that is a manageable and affordable size. Wrap that parcel into a sprint: time-bound not scope- or resource-bound.
- Address each chunk in an Agile way, which includes setting simple goals that are timebound (weeks) and iterating to get something useful. Architect the whole thing to keep each piece of work consistent. Draw on ITIL and other resources as relevant.
- Review and plan the next sprint.
It seems to me this is a far more achievable and sensible approach than monolithic theory-driven perfectionist projects whose objective and scope is defined by an ITIL book. That way lies madness and waste.
The irony of me propounding an agile approach won't be lost on those stung by my scathing comments about agile in the past. I can only say that agile is a fine approach if used between consenting developers behind the closed doors of a development environment. Where it causes alarm is in the transition to operations and the impact on a production environment. I don't take the extreme views of Bad Attitudes of Agile (in fact it is amusing to substitute the word "ITIL" for "agile" and read the article and the comments. The specific criticisms are different of course but the tone and arguments sound very like other debates between the hysterical critics of ITIL and its defenders. In another ironic twist the ITIL defenders include me at times.)
Moreover, agile's ill-discipline is of much more concern in the case of code (where only one state works and every other doesn't) than in the case of procedures and roles. I'd go so far as to say the Agile methodology suits process development far better than software development. Digital technology has only one correct state. Any other state is broken and probably catastrophic. So messing with software on fast, repeated, loosely-managed cycles is asking for trouble.
On the other hand humans are adaptable, responsive and self-correcting in the face of small-scale change. (Larger cultural or organisational change is another question entirely). The formal process description is only ever an approximation of what happens in reality - it doesn't even describe the state, only suggest one. This strikes me as a much lower risk environment in which to be churning agile changes.
Tipu takes all of these ideas and builds them into a methodology. So far, in pilot it seems to be working quite well to address the need for continuous improvement in organisations.