As most who work in service management, on an IT team or as a member of the service desk understand that change management can be a rather rigid, shall we say, still process. Do you want to make your change implementations more agile? There are different ways to go about this. In this piece, I plan to discuss how to implement a single change in an agile way, and how to make all your department’s future changes more agile. Let’s first begin with how to make the implementation of a single change more agile.
Describe Your Goal and Preconditions
Ideally, when necessary changes are required, you shouldn’t need to complete a full change request form when submitting the request. The description should only contain basic information regarding the change. Most importantly, what must be included are your goal and the required preconditions.
Here’s an example: You receive multiple calls about a coffee machine breaking down, or an email server running slowly. As a service desk representative, you’d likely prefer not to receive and handle a bunch of calls about the same problem, but you do want your customers to be able to know whether or not a problem has already been reported and is being dealt with. Your team’s goal, then, is to show your customers that a ticket already has been submitted for the problem and that you are working on it, but you also want to make sure your customers don’t get to see the private information of other customers—that would be one of your preconditions.
Apart from your goal and preconditions, there’s not much more you need to know when you get started with a change.
Check Regularly if Your Change is Still Meeting the Pre-Set Goal and Preconditions
Implementing changes according to the waterfall method can mean there’s a chance that, when done, the solution doesn’t meet the customer’s needs. The waterfall method likely means you want to execute your plan without alterations along the way. Under this model, there’s no room to adjust to new situations even if you need to make changes. You may find new information about what your customer really wants, or there could be new technologies on the market providing a better solution to your perceived problems.
So, while you’re designing and implementing a change, regularly check to see if what you’re doing right now still contribute to the original goal, and whether you’re still meeting the pre-conditions. As you know, agile processes lets you make adjustments along the way. But perhaps you’re already past the point where you could have made a change. If that’s the case, in an agile workflow, you can change course and simply work the change.
Involving Others in Your Change
Once you’ve got an idea of how you want to implement a change, make sure to include your team’s experts so they are able to take a detailed look at your plans and determine the impact of the change on other applications and hardware. Additional points to consider include analyzing any change that may lead to security risks.
When following the agile philosophy, it’s better to let your team come up with its own solution, but if the team figures everything out for themselves, you want outside members to perform the quality check. As the saying goes, freedom is not free. For IT teams, the freedom to come up with a solution means they also must be responsible for determining whether the solution will work as planned.
Run As Few Changes As Possible at the Same Time
IT departments almost never work on more than one change at a time, even those that are small. Unfortunately, there can be too many changes to the handle. To keep the number of changes in check, limit the number of changes that need to be undertaken at any given time.
Doing so makes it 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.
Also, the fewer tasks in operation, the more likelihood of the service being higher. If you’re able to focus more on the change you’re currently working on, you don’t make as many mistakes. Finally, with fewer tasks you’re able to focus on your work and quickly generate results. Visible progress is one of the most important factors that determine happiness at work and getting things done in a timely manner is more motivating than constantly toiling on a number of different things with nothing ever getting finished.
Managing Changes vs. Incidents
When there’s a constant flow of incidents coming in, your service desk employees must make the decision about your team’s priorities and what they are going to be. For example, do you want to guarantee a maximum time for required changes? To meet outcomes and objectives that are set by this team, you must dedicate a set amount of time that each team has to spend on said changes. This means you must be able to accept that some of your reported incidents won’t be addressed immediately.
Alternatively, if it’s more important to solve incidents quickly, you need to accept the time required to implement these changes, and an understanding that your team won’t be able to handle new changes as quickly as you might hope to. Change requires time, even if time to solve incidents is your biggest priority.
