Over the years we’ve tried a few different ways to run our dedicated client support service. For a while now, we’ve used a daily rotation where two different developers ‘hotdesk’ over to work with the support team every day.
While this model works well, it has some limitations. For example, we sometimes found that tickets raised needed longer than a day to resolve, developers didn’t have sufficient time if they picked up a ticket late in the day or had to take time to relearn problems outlined in tickets. Project commitments could mean that an item completed within support time was picked up by a different developer, leaving fragmented responses and an incomplete trail.
Having a daily rotation also meant there wasn’t as much time to foster a strong team dynamic. Different personalities, limited time, pressure from project commitments, time lost due to meetings, Monday mornings…. It was also difficult to scale the team up/down according to demand.
To help resolve these problems, and streamline our processes, we’re now following the Agile principles of inspecting and adapting according to the needs of our clients. What we have decided to do is run support as one week sprints. We still use a rotation and have all the benefits of the previous model; however, we now give our developers longer to resolve tickets, which we believe will provide our clients with an even better service.The sprints involve the typical elements you would expect from any Agile project. There is a dedicated team, a prioritised backlog of tickets, a planning meeting, daily stand-ups and a review meeting which includes a retrospective. There are however some key differences.
Support by its nature is volatile; priorities shift quickly, new tickets are added daily and it can be chaotic. To respond to these unique challenges, we’re using Kanban to manage the workflow of tickets, and it’s the number of tickets in progress that’s the constraint, rather than time boxes as on a traditional Agile project.
To manage demand, we run the sprints in two modes: “Blitz” and “Sustain”. “Blitz” is used to scale up the team to increase our velocity when we have more tickets than usual; whereas “Sustain” is used when we need to keep things ticking over. In the future, we’re considering an additional rapid-response service, which we can use to fast-track smaller scale client work and change requests.
We’ve decided to swap out our “Flight Control Wall” for the excellent trello.com, linking this with our support site to automatically create backlog tickets through its comprehensive API. Now our developers are able to join the support team more completely as they can track their items through to deployment, with a dedicated release day at the end of the sprint. The reduction in desk swapping is a boon but the sense of belonging is doubly so. Equally as important, we can plan for the rotations more easily; we’ve already generated calendar entries for the next year but could take this further.
If you are providing ad-hoc support, a structured sprint practice is something we highly recommend you consider. The additional time spent will pay for itself many times over in the improved service you can offer clients, and the increased ownership of quality throughout your organisation.