For those of us who handle IT change requests on a daily basis, the process can seem as onerous as a Sisyphean task. In this case, rather than a boulder rolling back down the hill, it is the backlog of RFCs that seem to grow every time you complete a request. Let’s face it - the requests are not going to stop coming. The business is trying to change faster, so they need IT to implement change faster. In the end, it is all about doing as much as you can with what you have. Following ITIL best practices and using a solid change management tool goes a long way, but how can the whole task be made less Sisyphean?
The answer may come from borrowing some of the lessons learned from application development. It turns out that many of the same agile practices adopted by programmers over the last decade can greatly improve the continuity, speed and predictability of your organization's IT Change Management – leveraging, not replacing, your existing ITIL best practices and tools.
When you view the never-ending flow of RFCs as roughly equivalent to the flow of feature requests that an application development team receives, and recognize that the goals are the same - to implement the changes as quickly as possible, as close to the user’s expectations as possible, and in a predictable amount of time - then it becomes clear there is much overlap between processing change requests and turning around new features in a software application.
Of course, some of those change requests are for application development, and those clearly lend themselves to agile practices. But as it turns out, agile methodology can help IT manage all types of requests.
It is possible to apply agile practices to the flow of IT change requests and see these same benefits. Here are some specific ideas on how to implement agile methodology without abandoning ITIL best practices or your current change management tool:
1. Use CAB Meetings to Prioritize Backlog
Take an agile methodology mindset to CAB. Instead of holding weekly or monthly CABs, have daily scrums to prioritize change requests. Place the less urgent and non-routine requests on a backlog. Let the responsible teams decide how much of the backlog they can achieve in a short period of time, say two weeks.
In your Change Management tool, create views that clearly indicate which requests are on the backlog, and which are in process.
2. User Stories with Story Points help Document RFCs
Scrutinize the change requests to ensure they are properly broken down, the same way agile software developers break down feature requests into User Stories with Story Points assigned and weighted.
Leveraging the customizability of your change management tool, re-label the Description field as User Story and add a field to contain the Story Points. For most IT organizations, the change requests are relatively short lived and independent of each other. But if your organization has enough large, complex requests that are related to a given system or project, following the agile technique of grouping them into a sprint may make sense. You may even consider forming two teams, one team that manages the shorter lived requests as a constant stream, perhaps using a Kanban approach; while the larger requests flow into a team using a scrum approach.
3. Change Manager becomes Scrum Master
The Change Manager acts as the Scrum Manager, overseeing quick daily standup meetings to talk about progress on the tickets in process. The Scrum Master’s mantra: plan a little, do a little, test a little - create a tight feedback loop.
In a larger organization, where the Change Manager cannot possibly have the bandwidth to be the Scrum Master for all of the supported services, the technical owner of a business service may need to act as the Scrum Master, with the Change Manager overseeing the various business Scrum Masters.
It is important that someone fills the role as Scrum Master in order to insure that the amount of work in process is always minimal (agile methodology is all about finishing what you start and delivering each item before you bite off another). As such, it is critical for the Scrum Master to monitor the batch of changes in progress on a day-to-day basis and be available to help clear roadblocks for those implementing the changes.
4. Continuous Improvement to Optimize Agility
By assigning a size in the form of Story Points and by minimizing the amount of work in progress at a given time, you can judge the velocity of successful changes and provide more transparency into what the bottlenecks are.
As requests are completed, the Story Points assigned to the requests represent a quantity of work completed. The average rate of delivering Story Points over time is the velocity. By charting changes in velocity over time, you can better manage your team’s bandwidth and better predict the time required to work down the backlog of requests.
Increasing the velocity becomes the challenge. Agile prescribes various approaches to eliminate the bottlenecks preventing a faster velocity. The best approach for a handling a continuous stream of requests, where they are not batched into sprints, is likely a cumulative flow diagram. However, if you are batching your requests into sprints, then a scrum approach using a burn down chart may work better.
Either of these approaches can be diagrammed in Excel by exporting the data you collect in your change management tool.
In summary, the best way to attack that seemingly always growing backlog of RFCs requires an ability to expose the bottlenecks that are impacting your ability to increase the speed and predictability by which the requests can be implemented. One way, is to borrow agile software development techniques and overlay them on your existing ITIL processes and tools.
ABOUT Russ Miller
Russ Miller is the CTO of SunView Software, Inc., an ITSM tools vendor he co-founded. He has more than 20 years of experience leading software product development from concept to delivery for companies like IBM, Compuware, Quark, and Intuit. He was an early advocate and adopter of agile software practices and has been immersed in ITIL over the last decade as part of developing the ChangGear ITSM solution.
