Agile Change Management Proccess in Practice

Change Management can be a rather rigid and long-winded process. Do you want to make your change implementations more agile? There are different ways to go about this.

In this blog I’ll talk about how to implement a single change in an agile way, as well as how to make all your department’s changes more agile.

Agile Service management vs Change management

We’re continuing our exploration into Agile Service Management – to find ways you can make your Service Desk operations more speedy and less rigid. So far, we’ve looked at how ITIL and Agile can work together, drilled into Agile Incident Management and also published a whole e-book on the topic.

Most recently, we’ve been exploring Change Management from an Agile perspective. Let’s continue exploring that topic. How does it work in practice?

How to implement a single change the agile way

Let’s start with how to make the implementation of a single change more agile.

Only describe your goal and preconditions

In an ideal world, you don’t fill out a full change request form when you’re first submitting your request. Your description only contains basic information. The most important things you need to include are your goal and preconditions.

Here’s an example: You often get multiple calls about a coffee machine breaking down or email servers being slow. You’d prefer not to get a bunch of calls about the same problem, so you want your customers to be able to see whether a problem has already been reported. Your goal is: showing customers which calls have already been submitted. But you also want to make sure your customers don’t get to see private information of other customers. That would be one of your preconditions.

Apart from the goal and preconditions, there’s not much you really need to know when you get started with a change.

Check regularly if your change is still meeting the preset goal and preconditions

Are you still implementing changes according to the traditional waterfall method? Then there’s always a chance that when you’re done, your solution turns out not to meet the customer’s needs. Because the waterfall method assumes that you directly execute the plan you’ve drawn up, without alterations along the way. There’s no room to adjust to new situations. And your situation can change. You may find out new information about what your customer really wants, or there might be new technologies on the market that provide a better solution.

So, while you’re designing and implementing a change, regularly check the following questions:

Does what we’re doing right now still contribute to the original goal?
Are we still meeting our preconditions?

Is your solution no longer sufficient? An agile process lets you make adjustments along the way. But maybe you’re already past the point where you could have changed course. If that’s the case, don’t be afraid to pull the plug on your change. Pulling the plug may be a hard thing to do, because you’ve already invested time and energy into it. But quitting on your change is still better than working on a solution that isn’t going to help anyone.

Get other experts involved with your change

Once you’ve got an idea of how you want to implement a change, have different experts take a critical look at your plans. What’s the impact of your change on other applications and hardware? Will the change lead to security risks? Traditionally, this sanity check would be done by members of the CAB when they evaluate a change request. According to the agile philosophy, it’s much better to let your team come up with their own solution. But if your team figures everything out for themselves, who will do the sanity check?

Freedom comes with responsibility. Don’t just give your team the freedom to come up with a solution, but also make them responsible for consulting with relevant experts to check whether their solution will work.

How to handle all changes in a more agile way

Your IT-department rarely works on just one change at a time. Even a small IT-department with just 6 to 8 people will often be dealing with 10 to 20 changes at a time. But that’s too many.

Run as few changes as possible at the same time

The solution is simple: limit the number of changes you’re executing at any given time. It’s easier said than done, of course. But it’s worth the effort. You kill multiple birds with one stone:

It becomes easier to predict the duration of changes. Working on fewer changes at once means you’re working with fewer variables, so you can better predict when you’ll finish a change.
The quality of your service becomes higher. If you’re able to focus more on the change you’re currently working on, you don’t make as many mistakes.
Working on changes becomes more fun for your team. You’re able to focus on your work and you see results quickly. Research shows that visible progress is one of the most important factors that determine happiness at work. Getting things done in time is much more motivating than feeling like you’re always working on a hundred different things and nothing is ever finished.

Changes vs. incidents: make a clear choice

How do you make time for changes when there’s also a constant flow of incidents coming in? Make a conscious decision about your team’s priorities.

Do you want to guarantee a maximum duration for changes? Then you have to dedicate a set amount of time that each team has to spend on changes. Which means you have to accept that incidents may be on the shelf a little longer sometimes.

Do you feel it’s more important that tickets get solved quickly? In that case you need to accept that changes sometimes take a little longer to implement. And that your team won’t be able to pick up new changes very quickly.

Has your change process become overly complicated? This is how to simplify it.

Explore more about Agile Service Management

Agile Change Management is still in its infancy. Have you experimented with it? Find out more ways to make your Service Desk be more efficient through Agile with our Agile ITSM e-book.