Agile Service Management: Can ITSM Truly Be Agile?

It sometimes feels like the phrase “Do more, with less” has been with us since we started delivering technology-enabled solutions to business challenges and opportunities. Typically nowadays, IT departments get a small year-on-year reduction in their budget with an expectation they will do the same or more in the coming year. Often they manage to sustain this but sometimes they don’t, causing a loss of confidence in the IT department’s capabilities and business value that becomes increasingly difficult to address. In seeking to deal with this issue, one of the increasingly popular solutions is something called “Agile Service Management.” I’ve blogged on this before – in Getting Started with Agile ITSM and How ITSM Supports IT Agility, but thought it a worthwhile topic again as we prepare for the challenges of 2017.

What Is Agile?

Let’s start at the beginning (I normally find it a good place to start).

Agile is a set of guiding values or principles that originated in the software development space. A number of leading figures in software development were keen to address the common issues that they and many others were coming up against time and again. Agile was their solution and the key concepts (or values) they agreed upon were:

1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan

These four values are supported by twelve principles, which can be found at the www.agilemanifesto.org, but I want to pick up on a couple of them.

IT Service Management Through an Agile Lens

The first principle states that “Our highest priority is to satisfy the customer through early and continuous delivery,” i.e. anything and everything that you do is for the customer. It’s a question that many ask themselves too infrequently in IT service management (ITSM), but it’s one that we should ask all the time. After all, if what you are doing isn’t for customer value, why are you doing it?

The second principle is “Business people and developers must work together daily throughout the project,” i.e. IT people continually working with business people. Again, how often do ITSM people do this? Without it, how do you know what you’re delivering is good for the customer. Just as importantly, it highlights the need for the business to get involved and work with IT.

Using Agile Frameworks and Methods

To realize these agile concepts and principles, there are a number of frameworks and methods that are used, including: Scrum, KANBAN, Continuous Delivery, etc. The one that most people are familiar with is Scrum. This sees self-forming teams of three to nine people working in two week “sprints” to deliver specific items from a “product backlog” that are based on user stories and agreed with the business.

There are only three roles: (1) the Product Owner who manages the product backlog, (2) the Scrum Master who ensures the rules are adhered to, and (3) the Team who deliver potentially shippable products. They meet daily for 15 minutes to talk about what was achieved on the previous day and what is aimed to be achieved today, as well as any impediments that the Scrum Master is tasked with removing. By the end of the two weeks they’ll have a number of releasable products or increments.

So What Is Agile Service Management?

Based upon this agile approach to software development, Agile Service Management is the application of agile principles to ITSM – I imagine you had probably guessed this already. More specifically, it ensures that ITSM processes are refined and improved in an agile and incremental manner. It ensures that ITSM processes have just enough controls in place to deliver effective technology services that facilitate customer outcomes. Importantly, it can be applied to both ITSM process design and improvement.

Taking its lead from agile software development, teams are self-forming and work from a product and sprint backlog for a set sprint. The roles are similar, with a Process Owner managing the product backlog, the Agile Service Manager ensuring scrum principles are adhered to and that impediments are removed, and the Team delivering process improvements. The main difference is that sprints are typically longer (up to four weeks) because all members will also have a number of day-to-day operational activities that they must undertake.

So Is Agile Service Management Truly Agile?

The promise of doing ITSM in an agile manner is very appealing. The benefits of working closely with the business to deliver processes or process improvements are clear. You can deliver increments quicker and get faster feedback on the benefits. Nothing is worse than spending a long lead time delivering process changes that aren’t followed or are not to the benefit of end users.

However, quick and early (nothing to do with my good friend Earl Begley) wins are critical to getting the business bought in, in a similar way to getting them to buy into agile software development. If you are already doing effective continual service improvement (CSI), then the step to Agile Service Management may not be difficult at all. You will already have a cyclical approach to improving quality, and the added structure of Scrum should only give a more formal approach to your work. In addition, your CSI register is the ideal starting place for your product backlog – so you know what you are trying to improve.

If you are not doing CSI, then it can be harder to implement. Your biggest benefit, to sell to the business, is the quicker delivery of process changes and their business impact. If you can deliver some real benefits, then buy-in should be easier to come by. However, I cannot emphasize enough just how difficult continued business buy-in can be to attain. The power of good business relationship management cannot be overlooked here – the better you understand your business, the better and quicker you can deliver real process improvements.

Finally, with this new agile approach, it can be difficult to see where your existing project management capability fits in. In my experience, your company’s existing IT project managers often make very good process owners. They understand how to manage backlogs and often have a good understanding of the business. Although it is a different skillset, particularly to traditional waterfall project management methods, it is clear and easy to spell out the new skills that project managers will need. If you want a quick refresher on the differences, then please look here.

So, does your company already use agile and ITSM together (even if you don’t call it Agile Service Management)? If you do, what did you find difficult and what advice would you give to others?