Agile Change Management - is it viable?

A classic Change process can be long-winded and rigid. Can you make the process more agile? In this post in our agile blog series, we’ll discuss Change Management and a more agile approach to it. Does it work? When doesn't work? And what works and what doesn't work?

Is Agile for standard or non-standard changes?

In my video on Agile Service Management, I was quietly skeptical about the benefits of agile for Change Management. But I've been more and more convinced that it has it's place. 

Agile tends to be a better fit for non-standard changes. The idea is that it helps you with work that’s unpredictable, while standard changes are usually designed to be as predictable as possible. A laptop you support is a good example: you take a laptop from your stock, install the required operating system plus standard set of applications, and you deliver the laptop. So no surprises there.

But in non-standard changes, agile can actually make all the difference.

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

What’s the problem with the traditional ITIL-prodecure?

ITIL-style change management was introduced to regulate the processing of changes in your IT infrastructure. It helps you prevent the whole network from going down whenever you replace a server. So there are a lot of checks and balances built into the framework.

All these checks are very useful, But they have made the process for non-standard changes incredibly complex. And a complex process has a lot of downsides:

• Submitting a Request for Change (RfC) is a lot of work. You have to think of technical solutions, perform impact analysis, gauge risks and predict costs. And you’re not even certain that the Change will ever be executed. Or whether your information is still accurate when the Change is implemented.
• The Change Advisory Board (CAB) spends a lot of time approving RfCs. In some organizations the CAB discusses every changes, big or small, urgent or not urgent. This can mean that 6 to 8 CAB members spend time talking about a relatively simple request.
• The change process is a one-way street. Before you submit a Request for Change, you have to plan everything out. After approval, the only thing left to do is execute the preset plan. Come across new information? It’s not so easy to adapt along the way.
• The change process takes longer than it should. All of the control mechanisms mentioned above slow down the change process. Maybe you’ve got everything ready to start implementing a change, but you suddenly realize “we were still supposed to have the CAB check the latest changes, but they won’t meet until next Wednesday”.
•  

Change requests without unnecessary tasks

Now I’m not saying that processes and checks are unnecessary by nature. On the contrary: I often recommend that organizations work with RfC forms. Having some form of impact analysis prevents big problems with the implementation.

But do you need an RfC form every single time? I don’t think so. Find the right balance between minimizing risks and trusting your IT department to make the right choices in their work. An agile approach to change management can help you find that balance.

> Why your change process is too slow – and how to fix it

The Change Manager: Product owner of the change backlog

The roles of the Change manager and the CAB will change the most. Traditionally, the change manager is first and foremost a process manager. If you go agile, the change manager’s job will become more social and more focused on the core of a project.

These are the tasks of an agile change manager:

• You collect and prioritize your stakeholders’ wishes. Put RfCs on the Change backlog as Change requests. A backlog is basically a prioritized list of work that needs to be done. If you want to prioritize well, you need to be aware of what’s going on in your organization. You investigate the different RfCs and compare interests and problems. Use this comparison to prioritize, and review your prioritization regularly, like every 2 weeks for instance.
• You make sure RfC descriptions are clear. You don’t need a complete form for each RfC. Just make sure you have all the info you need to prioritize. For example: What problems is the RfC supposed to solve? What are possible solutions? What is the estimated scope of the request? You don’t have to fill in all the details like a complete solution, plan of implementation and budget right away.
• You make sure the top 5 RfC have more detailed descriptions. Stick to this rule of thumb: the lower something is on the backlog, the less detail you need in the request. Only provide a detailed briefing for requests you’ll be working on soon. And you only ask CAB approval for those requests as well.

The CAB: from technical details to the strategic level

If the change manager spends more time collecting and prioritizing change requests, the question arises: what will the CAB’s role be? They still play an important role in the process, but it’s on a more strategic level. These are the new tasks of the CAB:

• Approve the most important RfCs. This tasks remains largely the same: the CAB determines whether requests are complete, and it may reject some RfCs. The main difference is that the CAB only looks at the RfCs that are near the top of the priority list, so that saves a lot of time.
• Approve the prioritization of the backlog. The change manager has already prioritized all RfCs, so the CABs job is to see whether they agree with the priorities on the backlog. If the change manager does this well, the CAB usually won’t ask for a lot of adjustments.
• Give the green light (or stop sign) at pivotal moments. During traditional implementations, the CAB gives the green light before the go-live, during testing for instance. In agile change management, the new service is usually rolled out piece by piece, so you no longer have a ‘big bang’ moment of truth. So, when does the CAB give their approval? The answer to that question is different for every implementation. The IT-team and the CAB decide beforehand at which stages of the implantation the CAB should get involved.

More Agile Service Management

Curious about more ways to go Agile? Check out our Agile Service Management e-book for an all encompassing guide to what Agile can mean for your Service Desk.