Agile ITSM

ImageThe 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.

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.

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.

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.



Growing list of free Tipu resources for all the ITSM philosopher

There are now a number of free resources available on my Tipu website including

  • Executive summary
  • Why Tipu?
  • The Tipu Framework

All the ITSM philosophers who follow this blog will be interested in the last one: the Framework attempts to be more complete than ITIL or COBIT. I started a new post so you can all comment there

A Tipu book will be out before Christmas!

Don't try to change the culture

Tipu's #2 is unrealistic. One consulting project will not change the culture. That will not work and I don't think you really mean it. Companies have their culture and that will not change even if you change the way they work. A successful, cheerful, creative company will have successful, cheerful and creative processes. A pedantic, careful, formal company will have pedantic, careful and formal processes. Both solutions may work quite well but they will be different.

I suppose you really mean that you need to try to change some bad habits. That is a hard but realistic goal. For example; many countries have banned smoking in public places. It has worked surprisingly well and many people have quit smoking but it has not changed the culture of the countries or of the people.


bad habits

Good point. It depends what you mean by "change". Yes you cannot readily transform a culture but you can make minor adjustments - as you say, correcting bad habits.

Agile ITSM

I don't know why I didn't search "Agile ITSM" when I first wrote this post, but I didn't. I'm not trying to "own" that phrase. Anyway I finally did, and found a DITY newsletter I had missed first time round, from David Nicholl, where he has this to say

Adapted for ITSM, its guiding principles are:

Continuous delivery of improved processes
Working processes are delivered frequently (weeks rather than months)
Working processes are measured by achievement of desired outcomes
Changes are incorporated as they come up
Communication is primarily face-to-face
Process implementations are built around motivated individuals who are proven to be trustworthy
Continuous attention to good design and professional capabilities
Self-organized teams
Regular adaptation to changing circumstances

Yup, exact match to Tipu!

And I found a post from Charles Betz on his ERP4IT site which had me worried that we were going to agree to disagree again when he said

Agile IT Service Management: Why it's an oxymoron

uh oh! But in fact he was not writing about implementing ITSM using agile methods. He was referring to ITSM used to manage agile software development, where he and I are in complete agreement

Complex systems are prone to emergent chaotic dynamics, and change is the enemy (whether labeled "Agile" or not). That is invariant in any systems engineering, with theoretical foundation in Turing's proof of the insolubility of the Halting Problem along with much other math & science. Test-first development, while an excellent practice, does not solve the Halting Problem. You cannot test all paths, and the more extensive the testing harness, the more invested in it, the less the agility. Re-factoring, while another excellent practice, cannot be construed as risk-free. Any new execution path has increased probability of failure. And no reliability, no service, no Agile ITSM.

Coda to that post

Hi Rob,

That post generated some discussion

and I've had some second thoughts about it as noted in the comments. In particular I'm thinking a lot about the DevOps challenge that change and stability are not zero sum and to reduce the risk from change, you should practice it more.

Charles T. Betz

cute phrase

I'm aware of that principle "to reduce the risk from change, you should practice it more.". I'm reminded of some of the exciting new discoveries and principles cute phrases from other radical movements bubbles which all boil down to "the old rules don't apply any more". Almost invariably they do and a crash ensues.

One old rule is that the faster the rate of change the harder to keep the system stable. Think automatic trading systems.

And in all those bubbles, there are case studies that apparently defy gravity. Like all magician's levitations, there is more to them than meets the eye and they don't stand close examination which is not provided. I wrote vendor case studies and business cases for years. I know how easy it is to create an illusion, especially one that the audience want to believe.

P.S. sorry Charles I didn't mean to misquote you - I should have read down the comments. What I do in that case is [update] the original post to flag the comment.

good subject to empirical testing

Well, this would all be quite suitable for empirical testing, if we could get at the data we need. Either change is perfectly negatively correlated with stability, or it isn't. If it isn't, perhaps there is a dynamic model that would bear further elaboration.

I didn't feel you misquoted me.

Charles T. Betz

Like any social science, IT

Like any social science, IT is hard to empirically measure.

Companies are performing the experiment but both sides will claim success

After 20 years we still can't agree ITSM is a good idea.

Makes perfect sense

First thing I thought of when reading this was "try something different to get a different result / definition of insanity thing".

This seems really well thought out, but you're (we're) going to have detractors who are threatened by the accountability that is implied or directly stated in the outline. Do ITSM SW vendors really want their customers putting some science & accountability behind value, risk and return? Do ITSM consultants want customers taking charge of their own destiny and chip away gradually?

The 12 principles are excellent.

For what it's worth, I think that CMM measurement isn't completely useless. It can provide some common language, ask some pointy questions, get some discussion happening and should flesh out where the focus is on the "usual suspect processes" (Incident, Problem, Change) and reset towards a more balanced view - with the business at the centre of the ITSM universe. Maturity improvement is not a bad thing in itself, so long as some arbitrary CMM score is not the end game. How "mature" is mature enough? Well I guess revert back to value/risk/return as your non-negotiables.

I'm a firm believer that CSI drives a better culture and vice versa - funny that it is a bookend on what most people learn on their ITIL training. Presenting on that belief @ ITSMFA in Perth next month. Curiously, one way I've tried to get this moving is to draw on Problem Mgt techniques and focus on human issues/opportunities, with customer at the centre. Am glad that some threads of thought in the other comments are in the same ballpark as mine.

But, goodness, it is very hard work. Kotter's "Buy-in" book/blogs are good sources of encouragement with the occasional "Oh crap - I went about that the wrong way". Live & learn.

Might still be inside-out

Tom, Skep, correct me if I have misread the program. But using CSI and focusing on dismantling 'processes' into bite size chunks both invite inside-out thinking. As I commented below - I encourage everyone to abandon ITSM/ITIL 'projects' and move gently to a continuous improvement program approach with as Tom suggests problem management SKILLS at the core. Not ITIL's problem management - it does not work, subject to Edition 2011 updates. There are three major flaws I will not go into here. Forget processes - they are offline specifications to reference. Focus on customer situations and your response.

Find out how you help customers succeed and what they do that causes your work effort. Enough said, else I'll be basically doing an advert and explanation of my six step program for Enable Outside-In Service Management! Doing fewer processes or less of each process are both inside-out. Good luck Skep - steps in right direction.

Quite the opposite

"Doing fewer processes or less of each process are both inside-out. " Not they're not. Quite the opposite.

The value we are asked (or propose) to produce is A
Therefore the business goals are B
Therefore the IT outcomes required are C
Therefore the outputs to be produced are D. These outputs come from processespractices E F and G, specifically the following bits of those practices....

By breaking it down into ONLY the bits that compose a solution to deliver to a customer-focused business value, rather than working on a whole practice for its own sake, we are doing exactly what you preach: starting on the outside and drilling in, focus on demonstrable value.

"abandon ITSM/ITIL 'projects' and move gently to a continuous improvement program" what's that if it isn't CSI?

With respect it is... agree to differ

If you are focused on the service, process, practice, infrastructure, procedures, policies and so on - you ARE inside-out - period.

Outside-in thinking STARTS and stays with the customer/consumer side of things.

So doing less of anything I listed and any other words generally NOT in the customer lexicon, is inside-out unless it has been previously determined it will improve the customer's lot and is driven by a customer reason. To your equation...

The customer wants to achieve outcome "A"
The customer performs an activity in pursuit of A, termed "B"
In performing the activity the customer uses products and services provided by "C"
The customer interacts with the product/service and/or "C" and drives work effort within "C"
The customer experience interacting heavily influences their level of satisfaction regardless of the result "D"

Problems define issues with any and all of the above, improvements recognizable to customers must affect "A", "B", "D"
Improvements that are positioned against "C" alone are vulnerable.

CSI is inside-out as it has the word service embedded within in and by the widest of ITIL definitions is focused on the service lifecycle stages.

What we need to focus on is generic continuous improvement principles, more in line with 70 year old concepts and methods well known to the business rather than introduce an IT (ITIL) sponsored term...


I agree that the process is the cart, not the horse, but Good Process can underpin/support good Work Practice. Process should connect work practices. Maybe we're just talking about semantics here - violent agreement...

process vs practice

We are just talking semantics. I hate the word "process". A process has inputs, outputs and a defined repeatable sequence of tasks. The outputs are predictable given the inputs. That describes a tiny subset of service management activities. ITIL and COBIT abuse the word horribly.

I unilaterally use the term "practice", as in Incident Management Practice (and as in "best practice" and "good practice" and...). A practice includes policy, plans, goals, roles, responsibilities, activities, yes processes sometimes, metrics, tools...

Agile ITSM

I have been working in IT for more years than I care to remember! My father was a programmer in the 1950s and in the latter part of his career he was an Ops Manager. He was one of the first to write Ops Procedures that really worked for his computer centre. I have been working in the area that is now called ITSM since the mid-1980s and developed lots of good practice way before ITIL appeared. I kind of liked the first publications (although too focused on public sector, rightly so as that was the first thrust). The second version was really getting there and so were its associated qualifications. V3 and probably ITIL TNG encompassed not just ITSM, which is primarily operating/managing services, but also the Strategic and Tactical layers of the service lifecycle. V3 (and its qualifications) was flawed as it did not focus on realworld needs. It has lots of detractors but a lot of the stuff in it has survived since the first publications because it works.

Preamble over!

I basically agree, from all my experience, with what you say. Ultimately KISS, focus on real needs and real business (not just IT) benefits, work with your customers and suppliers in an open and constructive way. Also deliver in manageable chunks (time boxing) and checking that what is delivered means requirements, tweak where needed. So use bits of ITIL (incidentally it's a library of publications so is already implemented), MOF (nicely written and copyright free), COBIT, Lean, Six Sigma and all the other methodologies as needed. Finally, key for me is clear, committed, persistent leadership at all levels (walk the talk). Also required is an appropriate level of skills to deliver and operate so training is key, not just technical but also in general management techniques. Always aim for perfection so continuous (not continual) improvement must be part of the culture of the organisation.

Maybe 'Agile ITSM' should be called 'Nimble ITSM', but that could be confused with a brand of bread!

Nothing new under the sun


To be honest, that is just what some of us have been doing for years. You can even trace it back to the Stadia model used by Quint Wellington Redwood when I was with them many many years ago

In my experience timeboxing is the critical thing to enforce.

The missing element needed to make it work is the management of the stakeholders and, for goodness sake, don't let a conventional project manager anywhere near it.

But I heartily agree it is the most effective approach to take.

BTW I presume sheer coincicdence that TIPU = The Invisible Pink Unicorn and it isn't meant as a comment on the number of ITIL "implementations" seen in the real world ?
James Finister



Welcome. For a while now I have been using a very simple customer focused program to help IT organizations define a problem, and make it go away. Timeboxed to a 30 -day cycle as Jim endorsed, it forces IT folks to think customer, and respond in bite size responses.. The problem management skillset if vital in defining the problem in such a way as to get support for change. I too regard smaller silo/process styled 'implementations as flawed and naive. They are inside-out and will fail the customer.

The more of us that trumpet the need to focus on what the customer recognizes and places value in - their ability to perform vital mission activities (USMBOK), and for a service provider to unde3rstand how they support that effort, and to apply improvements where these two meet, is vital to the very survival of the ITSM brand name.

Good luck with your program.

Syndicate content