Deconstructing ITSM

27 January 2009

Agile Service Management

I’ve been thinking…

  1. I am not a professional software developer or data architect, but I’m very interested in these disciplines through ITSM contact with practitioners and teams. (I often feel there’s a great loss of value in the lack of mutual familiarity between service management and development/data communities.) One of the approaches I have been particularly interested over the past year or so is Agile Software Development, the Agile philosophy – see the Agile Manifesto, and some of the key practices associated with Agile development like test-driven development, refactoring and design patterns.
  2. I observe that many ITSM projects (“implementations” or improvements) suffer from issues with long timescales, inability to cope with changing requirements, lack of user acceptance, and so on. Not all, but those that do suffer tend to be blind to the causes and show resigned acceptance to such issues – or even to be blind to these issues.

Those issues, and others I haven’t listed, are very like the kind of things the authors of the Agile Manifesto were experiencing. Agile development is very successful in certain environments (though not all – and more traditional “big requirements up front”, “big design up front” methods have strong defenders). Could Agile principles be applied usefully to IT Service Management problems?

Agile Service Management

I’ll admit I don’t think that agile methods can address all ITSM needs. For example, a high-volume Service Desk probably should not be run as a self-organising team that values individuals and interactions over processes and tools. Large parts of day-to-day service management are repeatable activities that need process standardisation – and the ITSM profession has been struggling to promote process control for decades. And there should be enough commonality in request handling and configuration management needs that in-house tool development is not the right option for most companies.

But everyone requires process development. You can’t just take the processes from the ITIL books and use them. And most commercial toolsets require substantial amounts of customisation for an effective implementation. In these areas, practices like frequent iterations and focused teams including users and specialists can surely have value.

There’s something worth investigating here, and I propose to examine principles and practices, see where they can be applicable, and what kind of coherent approach we can build.

Scope

Just as software and database development build capabilities that support business processes, I think Agile Service Management will be most applicable for the disciplines and teams building capabilities that support IT Service Management. That is, developing IT for IT rather than IT for business.

Secondly, I’ll focus on modular self-contained improvements rather than building the entire ITSM capability. There is a need for architecture, massive engineering and “big design up front” in large-scale ITSM systems. (Some of the best thinking on this issue can be found at Charles T. Betz’s blog erp4it.) But every environment, even the largest and best-planned, needs continual improvement; and many organisations can get greater value, and closer alignments to requirements, by implementing in smaller steps of proven value. It’s the other end of the scale.

Compared to Agile Software Development, ITSM development usually needs to develop or improve the IT processes much more than IT develops business processes (although there’s probably a useful debate to be had on that!). In fact, there’s more emphasis on process and less on developing software. These topics need to be explored more, though.

Key Practices

In future posts I need to look at the Agile Manifesto principles, and other Agile practices, but for now I just want to touch on the key practices that I think offer potential value.

  • Short, frequent iterations (of a few weeks), each delivering a self-contained (package of) requirements. Yes, this could help with budget control and management commitment – things that ITSM teams often struggle with. But the main reason I like the idea is to support alignment with customer requirements. A six-month project developing Service Operations processes and organisational change addresses the requirements as they were understood at the beginning of the six months. A set of one-month iterations, delivering functional operating processes and business value in each iteration, not only gets value to customers more quickly, it also makes it much more likely that the changes are what the users need and that emerging requirements can be swiftly handled – and it helps with user and management buy-in.
  • Dedicated team including customer participation. Agile methods promote a team working together from beginning to end of an iteration, communicating face-to-face (including formal daily meetings), rather than separate teams communicating through formal requirements documents. I see the ‘customers’ of a service management development being primarily any IT staff, including those involved in day-to-day support (who would be users of a service desk tool, and an incident management process) and software developers (who would be users of a release and deployment process among other things). There’s a case for having the customers’ customers – ie the business end-users of IT – included as well. Having representatives of these customers in the dedicated team, continuously, would bring the same benefits as it does in Agile Software Development: aligning the delivered solution to real requirements, not to the shadow of requirements captured in some document, or the process developer’s (or tool vendor’s) assumptions as to those requirements.
  • Refactoring: Instead of treating delivered ITSM processes as cast in stone, or difficult to update, teams should focus aggressively on optimising them. The philosophy of continual improvement embodied in ITIL practically demands this; Agile principles will enable it. Continuous attention to excellence and design matter. (I need to be careful about the terminology. Strictly, refactoring is changing code to make it cleaner and more maintainable without changing the functionality. When I think of refactoring an ITSM process it will of course change the job of the user (the IT staff member) – but without changing the business objective achieved.)
  • Design patterns: I’d like to interpret ITIL as a set of design patterns: good reusable solutions to specific common problems. There is a vast amount of good material in ITIL, but not every organisation can benefit from every piece of it; a design pattern structure might help to clarify. With ITIL V2, we saw a lot of companies overlooking valuable guidance because they’d “done the basics” and were not clear on where a specific piece of guidance could help. A pattern interpretation could unlock this value. With ITIL V3, many companies are concerned that it’s too big or too complex to grasp. They are looking for modular, incremental ways of adopting best practice: presenting best practice as design patterns, stating what problem it solves (do we need this yet?) and what pre-conditions it has (are we ready for this?), is almost essential.

More to follow.

Closing thought

There are many different software development methodologies, on both the agile and the “waterfall” sides, all “best practice” and having passionate advocates. But there is only one ITIL. Why? Is ITSM simpler? Not much. Is ITSM less professionally and thoroughly addressed in most organisations? Is it because everyone does in fact develop ITSM with different approaches (all using ITIL as guidance) but it’s not treated seriously enough or understood well enough for us to promote different approaches?

About these ads

4 Comments »

  1. You’ve tackled a unique subject: Agile Service Management. The closest I have on the subject is project management and itil.

    I find this post excellent and very well written, and I would like to republish it on PM Hut, please contact me through the “Contact Us” form on the PM Hut site in case you’re OK with this.

    Comment by PM Hut — 28 January 2009 @ 02:53 | Reply

  2. Infact our development department and the operations department struggle with interface problems partly caused by different approaches.
    Because Agile has a strong management backing in our company the operations department started to adopt agile practices (some of them like frequent meetings, iterations and retrospectives are mentioned in this post).

    This blog looks very interesting. I will follow it continuously.

    Comment by Sebastian — 25 February 2009 @ 14:32 | Reply

    • Yes … interfaces between development and operations are often difficult.

      I’d be interested to hear more about how agile practices in operations are working for you!

      Joe

      Comment by Joe Pearson — 25 February 2009 @ 14:53 | Reply

  3. I don’t really know enough about agile project management to comment meaningfully as to how appropriate
    applying the entire methodology to ITSM implementations is, but I trust Joe’s expertise in this area. In my
    experience, however, every ITSM implementation I have ever worked on has suffered overwhelmingly from overlong implementation times. The reasons for this are numerous and include the delivery of a new process along with the implementation of a new application to support the process. Other factors include staff turnover during over long implementation times, thereby losing valuable IP and control and the very real danger, due to the quickly evolving nature of business today, the delivery of a product that is already obsolete.

    In many implementations, the consultant forges ahead stoically trying to beg, borrow or steal the clients time whilst the client remains ‘too busy’ doing their daily tasks and activities [doing exactly the things that they have done before that they are in fact wanting to change.].

    Using short iterations of delivery in structured work packages would certainly deliver immediate value [one of the tenets of ITSM implementation being the identification of ‘quick wins’]. Each 3-4 week iteration would be managed essentially as an exercise in process improvement.

    The first area that would benefit from a short term implementation cycle would be the immediate implementation of proper Management – this is appropriate for all process. I say this because we are not, for example, attempting to implement incident activities or service level activity exclusively, we are concerned with Management and control. Management activities must commence as soon as possible. The fact that a process or application may not be immediately available to them is beside the point. Activities are not application driven, nor I am sorry to say even process driven, they are people driven. Getting the people performing their correct activities against a process, aided by the correct tool is fundamental to ITSM. Can an organisation function without formal processes and applications to support those processes? Certainly. They will not be efficient, nor cost effective and almost definitely not be sustainable but they can function. Without people? Absolutely not. This consultant would argue that this, therefore, is the area where most effort should be applied to gain the best return in both quantitative and qualitative output.

    In the case where no formal process exists you may ask “How can I manage something that isn’t there” The answer is quite simple, every IT organisation performs the ITIL processes to some degree, most often the lack is the differentiation of the activities. The manager must begin to call the required meetings that the process requires, must attempt to get the management reporting that is required and so forth and take action based on this.

    Very often you will find, using this approach, that there is a lack of information, and a lack management
    understanding of the required tasks. This approach will also reinforce the way in which activities are
    currently executed are in dire need of improvement. Once the client becomes aware of what they should have been doing all along, through hands on practice rather than academic exercise, they will then understand how the formalisation of a process and the implementation of a good toolset improves their efficiency significantly.

    All to often the long term ‘turnkey’ methodology of project delivery is simply too overwhelming as an
    organisation [or process] is accelerated from 20 to 80 almost instantaneously. Managers are performing a
    plethora of tasks they have never used before, managing personnel in new was, who are also performing tasks
    that are unfamiliar. It is far more effective to evolve the process personnel along with the process. In this way process implementation and toolset deployments becomes an exercise in ongoing service improvement.

    Comment by Andrew Christianson — 27 February 2009 @ 15:07 | Reply


RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

The Rubric Theme. Blog at WordPress.com.

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: