Balancing Change Management, Its Complexity and Agility

Change management can be a cumbersome, even clumsy, practice that might even be classified as rigid. Add in an Agile mindset and the process seems at odds with each other. Interested in maintaining an Agile environment while navigating change management? Well, then, the following will help us intermingle the two approaches for managing change requests.

Is Agile for Standard or Non-Standard Changes?

Agile tends to be a better fit for non-standard changes given its fluidity. An Agile environment is always in development, always changing according to the needs of the project or the organization. Agile helps to attack work that’s unpredictable and effervescent. Standard changes, of course, are usually moved along in as predictable a manner as possible and can be slow and plodding.

Want a quality example? Of course. A simple laptop you support is a good example: you take a laptop from your stock, install the required operating system plus the 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.

What’s the Problem With Traditional Change Management?

ITIL change management is designed to regulate the processing of changes in your IT infrastructure and helps you prevent a network from going down whenever you replace a server. Therefore, there are many checks and balances built into the framework. Each of these checks are useful, but they are incredibly complex when dealing with non-standard changes. As you can image, complex processes have a number of downsides:

Submitting a request for change is a lot of work. Think of the technical solutions, perform impact analysis, gauge risks and predict costs – it’s a lot of work. Even then you’re not even certain that the change will ever be executed or if your information is still accurate when the change is implemented.

The change advisory board spends a lot of time approving requests for changes. In some organizations the change advisory boards meet to review every change, big or small, urgent or not. This can mean that six to eight of these board members spending time talking about a relatively simple request, which can be a waste of time.

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 here slow down the change process. Maybe everything is ready to start implementing a change, but suddenly you realize that you are still supposed to have the change advisory board review the latest changes, but they won’t meet in the near term, which slows everything.

Change Requests without Unnecessary Tasks

Review processes and checks are not unnecessary but it’s a good idea for organizations to work with request for change forms. Having some form of impact analysis prevents problems with the implementation. Do you need to use these forms every time a change must occur? No. It’s really about finding a balance between minimizing risks and trusting your IT department to make the best choices in their work. An Agile approach to change management can help you find that balance while keeping the organization free for being able to respond to the change.

The Change Manager: Product Owner of The Change Backlog

The role of the change manager and the change advisory board will change the most. Traditionally, the change manager is likely a process manager. If you move to an Agile process, this individual’s job will likely become more social and focused on the core of a project. The following are the primary tasks of an Agile change manager:

Collect and prioritize stakeholders’ wishes. To do so, place change requests on the change backlog then prioritize the changes that are most likely to address the most pressing issues within your organization – straight-forward insight. Next, investigate the different requests and compare overwhelming interests and necessary problems to address, using the comparison to prioritize and review your list regularly; for example, a cadence of every two weeks or so is good.

Clear descriptions of requests for change. There’s no need to complete change forms for each request; just make sure that all of the information need to prioritize changes is logged and available. Note which problems the request for change is meant to solve. List the possible solutions. Note the estimated scope of the request. There’s no need to fill in all the details, such as plan of implementation and budget.

Include detailed descriptions of top 5 requests for changes. The lower priority of something on the backlog, the fewer details need to be noted in the request. Provide details for requests that’ll be working on soon. These are the only requests you’ll need to send to a change advisor board for approval of those requests.

The Change Advisory Board: From Technical Details to The Strategic Level

If the change manager spends more time collecting and prioritizing change requests, there’s going to be less for the change advisory board to address. Therefore, its role may need to more fully determined. So, if the boards are made use of, they can still play an important role in the change management processes that are likely more focused at a strategic level. If that’s the case, these might be some of their tasks.

Approving the most important change requests. The board must determine which requests are complete and required, and, ultimately, those that may even need to be rejected. The change board then should focus on change requests that are top priority for the organization – ultimately saving time and keeping organizational efficient.

Approve the prioritization of the backlog. The change manager has already prioritized all requests for change, so members change approval board must determine whether they agree with the priorities of the changes on the backlog. Thus, if the change manager does this job properly, members of the board usually will not ask for a lot of adjustments to it.

Give the green light or hold the phone. 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.

While change management efforts can be cumbersome, there are ways to reduce the rigidness of the process while maintaining a certain amount of agility when navigating change.