Getting Started with Agile ITSM
Before you pick up a tool, you need to know what you plan to use it for. That’s just common sense, isn’t it? So naturally there’s a common belief that you have to define your IT service management (ITSM) processes first, and then search for tools that you can customize to meet your exact requirements. I suspect this approach was popular when organizations were prepared to pay teams of consultants to invest many months of effort to define custom processes, and were also prepared to wait for up to a year before their ITSM project delivered any value. But the world has moved on since then. Nowadays we cannot afford to wait. We need quick wins with a rapid return on investment, and minimal tool customization.
So would you now be better off buying a new ITSM tool and then forcing your process to fit the tool? I don’t think so. You need a different approach to getting value from investments in ITSM, one that makes sure the process meets your needs, but does not require huge investments of time and effort in defining and customizing processes and tools before you can get value from them.
Many IT organizations have started to use agile as a basis for developing applications. The agile approach is based on creating value in small increments (called Sprints), with each increment building on work that has already been done. Critically though, each sprint delivers some value so you get a rapid return on investment very early on in the development of a new service. Agile has proved to be a great way of developing some types of application, and this has led to endless debate about the benefits of agile in different contexts.
I would argue that agile can be used to develop your ITSM solution in exactly the same way as it can be used to develop an application, and I have never seen a situation where agile ITSM is not an improvement on old-fashioned legacy approaches with long projects that deliver no value until many months have passed.
The Key Steps to Getting Started with Agile ITSM
Define Your Vision
If you want to try using agile to develop your ITSM then you must start by defining a vision for ITSM. This is to ensure that all your development work is focussed on a clear goal. If you try to define incremental activities without a clear vision then you can end up with a “drunkard’s walk” type of development which constantly veers off in new directions.
Identify Requirements for a Product Backlog
You need to talk to stakeholders to identify what they need from your ITSM solution and capture these ideas into a list that can be prioritised. This list is described by agile practitioners as a product backlog and it will be used as a source of ideas for inclusion into sprints. An agile product backlog documents all the requirements that you might want to include into your solution, even if you know you will have to wait a while for some of them.
Identify a Minimum Viable Product
Your sprints will not work if you try to include every possible feature from the product backlog into them. Instead you should think about the minimum you can create that will be able to deliver real value to your users. Ideally this should allow you to create a sprint that will take about two weeks to complete.
Many years ago I was involved in very early trials of internet shopping for a large supermarket chain. Their minimum viable product included a form where customers could select groceries, and payment processing so they could pay for them. When the user submitted their order this was actually sent by email to someone in the head office, who printed the email and faxed it to the local store. Somebody in the local store picked the document up from the fax machine, collected the shopping and delivered it to the customer’s house. This minimum viable product allowed the marketing people to understand whether customers would use online shopping, what categories of product would be popular, how much customers were likely to spend and many other useful things, without having to invest in development of expensive back-office order fulfilment capabilities.
You need to apply similar thinking to identify the minimum viable product for your ITSM solution, this could be based on modifying (or replacing) existing tools, processes, communication channels or any other aspect of your ITSM where you want to improve. It’s likely that you already have something in place, so this is more a “minimum viable improvement” than a “minimum viable product”, but the same thought process should apply.
Run Your First Sprint
I don’t have space in this blog to go into how you run a sprint in any detail. During this short period you should do everything that you associate with any other application development, or ITSM improvement, project. Define detailed requirements, design, implement, test and deploy the solution. Then evaluate the sprint in a retrospective, to ensure you learn from your experiences.
Keep Defining and Running More Sprints, and Continually Improve Your Solution
As you finish each sprint you should review and add to your product backlog, and then identify the minimum viable product for the next sprint. Each sprint should create real value for your customers, and should build on the value created in previous sprints. If you keep your vision in mind, and ensure that every sprint takes you towards this vision, then you will achieve rapid improvements in your ITSM capabilities.
Summary
I started this blog with the question “Which Comes First, the Tool or the Process?” and I am now in a position to offer an answer. Neither. What comes first is the vision. Use this vision to guide your ITSM improvement journey, making incremental improvements to tools and processes on the way. During this process you may find that you need to completely replace a process or a tool, but only do this when you understand the value it’s going to provide to your users.
