Greetings!

In this article I will be looking at Agile Service Management® (ASM) and how it can be practically implemented. This will be based on the real world experience I gained in my 12 years as a Service Architect.

What is ASM and where did it come from?

ASM is an approach to developing and maintaining ITSM processes. It was developed by the DevOps Institute® in response to the perception that ITSM can be a blocker to the speed and agility of delivering benefit to the business.

So ASM is essentially using the Scrum, but instead of developing software you are developing processes. The following diagram compares ASM to pure Scrum and identifies key differences in terminology and cadence.

So, as you can see, the key differences are;

• Scrum Master = Agile Service Manager
• Product Backlog = Process Backlog (or CSI Register if it is a mature process)
• Product Owner = Process Owner

Example Implementation: Developing the Service and Support Model

This example of implementing ASM is where I was working with a client, who were creating a new business application using SCRUM to manage the software development, and there was a need to align the development of the service management and support model in alignment with the sprint planning and cycles.

This new application was going to be supported by a well established and mature support organisation. This meant that I didn’t have to look a standing up new processes, rather that I needed to analyse what needed to be designed and implemented to support the smooth transition from project to live service.

What I ended up with, as an output of the analysis, was a number of Epics, spanning the various processes, functions and tools, each of which had a number of high level User Stories.

These User Stories were classified as either Enablers, which meant they needed to be completed before further work could be undertaken, or Functional, which were delivering specific elements inline with the delivered output from the software development sprints.

Then I brought all of the key protagonists together for a Backlog refinement and initial sprint planning session. This turned out to be invaluable as we were able to refine some needs, re-align others and produce the Sprint Backlog for the enabler sprint and the first functional sprint.

These sprints went well, or at least better than I was expecting given how new the approach was to all parties, and the project was delivered successfully.

The following actions / activities certainly paid dividends;

• Establishing the Minimum Viable Product (MVP) is less straight forward in a well established ITSM model than if you are building some thing new, so allow time for this, listen to opinions but never be afraid of challenging the “norm” as, just because something is done in a certain way it doesn’t mean it is the best or most efficient way
• Engaging with the local process owners early on, and taking them through the ASM&asm; approach, and listening to their concerns helped to smooth the path to adoption
• Working closely with the software Product Owners and Solution Architects enabled early identification of challenges and producing collaborative responses
• Acknowledging that issues arise in live operations, that may require the “service development” teams focus, and allowing a reasonable allowance in the Sprint Plan worked well and allowed us to meet expectation
• Stabling the correct routes of escalation, so that blockers can be removed as soon as possible, is essential to maintaining the cadence of the team

Moving Forwards…

In my opinion the ASM approach can be very useful when you need to deliver and maintain an ITSM model for a software product where SCRUM, or another form of Agile, is used. However, as with any tool, it is not a one size fits all answer, so give serious consideration to the environment in which you want to use it.

I recommend that you go to the DevOps Institute site and read about ASM further.

If you decide that you want to use ASM then there are a couple of certification courses that you can attend, both developed and licensed by the DevOps Institute.

These are Certified Agile Service Manager (CASM) and Certified Agile Process Owner (CAPO). I have attended both of these courses, and gained the certifications, and see there is a lot of content that is repeated so attending one or the other, depending on what role you will be in, should be suffiicient to get a good baseline of understanding.

I hope that you found this article useful and I wish you good fortune in your ITSM journey.