Last year I was asked to lead a support team after it had been through a few iterations of team size, membership and location. The team already had a few ITIL processes in place; having finished documenting and implementing further processes I felt there was an opportunity. Whilst the processes were guiding how to complete activities there was nothing giving structure to how we managed the backlog day-to-day and week-to-week. Having worked on development projects run in an agile way and seen how beneficial the methods were I felt there might be benefit to applying some agile techniques to the running of the support team.
The use of agile in general is not prescriptive; this is an advantage in the world of support where you do not know what you will face each day. There are, however, also activities which do occur regularly, for example infrastructure monitoring and patching. It quickly became clear that the mix, of both planned and unplanned work was suited to the incorporation of components of agile methods. Techniques from SCRUM and the agile principles can easily be applied to the running of the support team. Although the methods described in this article relate to our work providing 2nd and 3rd line support some of the methods described could also be of value to a team providing 1st line support.
Initially we made use of daily stand ups for team coordination but this was just the start, we soon introduced the idea of sprints and sprint retrospectives for planning. Finally, we introduced the idea of a backlog to enhance our performance as a support team and support planning. SCRUM has the idea of a ScrumMaster who acts as an enabler, seeking to solve problems faced by the team preventing them from completing their work. For our application of agile to support the team lead took on the role of ScrumMaster.
Team coordination
As the team is collocated the value of daily stand ups was not immediately apparent but showed when we had team members away or on training. The stand-ups helped us to have a good knowledge of what each of the other team members was currently working enabling us to cover absences and also to offer help and suggestions to each other. The daily stand-up also allowed us to each start the day with clear goals in mind and that really helps maintain a momentum.
Prioritisation
Approaching the task of prioritisation in an agile way is done through working in priority order to address the backlog, allowing new higher priority incidents to push lower priority incidents into the backlog, for the next day or beyond, as required. This means we avoid getting bogged down working on a first-come, first-served basis. However, working in this way we have to be careful to maintain communication, particularly to those callers whose tickets get pushed down the priority order. Today we are in a much better place, working from a ticketing system on a daily basis we have new incidents raised to us which quickly build a prioritised backlog for each team member.
Planning
We have tried different length sprints for defect fixes, from one to three weeks in length and from our experience we found that in the fast moving world of support we needed to readdress and plan the backlog more regularly than many development projects and therefore had very short sprints of just one week.
At the end of each week we hold our retrospective and planning session. We review the tasks in the plan for the week which will be anything the team has found or recurring tasks, and any incomplete tasks move to the backlog. There is also a second backlog of the new incidents raised that week through the ticketing system with SLAs. One of the biggest challenges is to create a single backlog from these two pools of work, we must also consider work across all of the applications we support in totality to determine the work that is in scope for the sprint.
Change management
Further to managing day to day work and incidents in an agile manner, our support team also handles Change Requests. We attempt to bundle changes where practical into releases. These releases are managed in an agile fashion, working with the application owner and first line support as product and backlog owners to prioritise the work with an effort to release early and often. Releasing early and often allows the feedback time to be short and gives the client greater control and confidence in the changes.
In conclusion
Using agile methods in our approach in delivering support helps us maintain momentum, and gives structure to a role which at times can feel chaotic when being bombarded with incidents and requests amongst a mounting backlog. Furthermore, using agile methods has allowed us to deliver better service to our customers through faster resolution times of the issues that really have an impact on their work and increased communication. Agile has afforded us focus on our work with enough time given to planning and time for each person to ask for help and identify issues.
We have had a very positive experience of implementing agile into the support process and would encourage you to try this within your support teams.