Applying Agile Techniques to Help Desks

Scrum, Kanban, and a host of less well-known agile processes have taken over (and improved) software development recently. Just which parts of Scrum and Kanban can be beneficial for a help desk team? Let’s look at nine agile practices that can help.

Retrospectives

A retrospective is a meeting for all team members to discuss how they could have improved outcomes since the previous meeting. A retrospective should typically be held every one to two weeks. I would not recommend doing it less frequently, as that makes the meeting longer and also harder for everyone to remember all they want to raise. Also, more frequent meetings mean more frequent chances to improve!

This is the best place to start adoption of agile processes, as it provides a place people can discuss how those practices are working (or not) and propose changes. Running good retrospectives is tricky. However, here are some pointers to get you started:

• Open by writing up suggestions from the team as to things which went well and not so well since the last meeting. During this phase, try not to discuss things too much and just get them written down.
• Then, let the team discuss how they might address those concerns over the next few weeks.
• If there is something the team needs from outside of the team, make sure it gets logged and actioned asap. If you are expecting them to work to improve their processes, you need to show that you as a manager will resolve issues out of their control immediately.
• Make sure everyone is open and contributing, as this should be a chance for the team to collaborate on improving their processes, not for a manager or strong personality to dominate the discussion.

Making Work Visible

All too often work continues after the call (or email) is answered. Making that work visible is an excellent practice from agile processes which lets outsiders get a view into the team and understand just how much is going on (even if everything seems calm on the surface).

This is where Kanban or Scrum boards can come into play. I recommend setting up a Kanban board for any projects you deem long running enough to put on it. Here you have a couple of options, whether you use a physical board on a wall or an electronic one online. If you are all located in the same room I would recommend a physical board, as it is easy to see everything in one go, and anyone popping into the room from the rest of the business can easily see it too. If you are not all together, an online one will work better (Trello is a good place to start for free).

Building a Kanban board is as simple as creating a few lists next to each other with titles such as “To Do,” “Doing,” and “Done.” You can then start adding tasks, often as index cards with blu-tac attached (if using a physical board), to the lists. The first card in each list is the highest priority one, to be worked on next, and so on down the list to the lowest priority. When work starts on something, drag it into “Doing,” then into “Done” when it is finished. Having pictures or avatars for team members so you can stick them to the card they are working on is a good way to show who is working on what projects.

Optional extra – Show your full process: Instead of just having a single “Doing” list, split this up into the steps in your process, such as “Investigate,” “Implement,” “Waiting on Dev,” “Validate,” etc. This gives you a view into how work travels (and gets stuck) at different parts of your process.

Creating a simple Kanban board for your team’s projects can be a great way to get some quick insights into just how much work the team has on-the-go at any one time. You might be surprised how many tasks are ongoing at the same time. And if you aren’t, it can be a great way to flag that up to others who don’t see how much your team is trying to get done all at once.

Manage the Interfaces to the Team

An idea I like from Scrum is how the interfaces to the team are carefully specified, rather than how the team itself operates (which they are left to define themselves).

It is hard to come up with options for all possible teams here. Look at the ways work can come in to your team and decide if you are happy with how team members get assigned things to work on. Should it go through another step first? What is the interface into your team? And what are they expected to deliver at the other end?

For a help desk, this can mean one person being the only point of contact for incoming tasks and projects. In reality, others on the team may initially create the task as a result of a call, but then this point person decides how to prioritize the work and puts it on the “To Do” list in the appropriate priority. Or if it is simple, possibly they just do it there and then. What would work best for your team?

Pull-based Scheduling

Instead of a process which pushes work onto people, agile processes and Kanban in particular adopt a pull system. In this way, no one (and no team) is assigned work until they pull it into their process. As they have capacity for something, they decide to take it on and pull it into the process.

This is a valuable practice, as it allows teams and team members to work at a pace they can sustain rather than constantly be stressed out that they have umpteen things on their to-do list they will never get around to. It also allows others to help out by pulling tasks themselves which otherwise would have been assigned to someone else. This shares knowledge and skills amongst the team and gets work finished sooner than would have been the case otherwise.

If you have created your Kanban board, the team only commits to something when it gets pulled into “Doing” from “To Do.” This should make it clear what has been started and what is yet to be worked on. If someone really wants the team to action something from the “To Do” list, they can determine if something in the “Doing” list needs to move back to “To Do,” temporarily.

Swarming

Something it took me a while to understand but which was a major revelation when I got it was that agile teams operate as teams rather than collections of individuals. Previously, my team had work assigned to individuals and if one person got stuck others could “lend a hand” but wouldn’t really focus all their energy on the other person’s work.

After the change, the whole team was responsible for delivering any work in progress before pulling more work from the “To Do” lists. If anyone could help anyone else, they always did. Work started getting done faster, team morale improved as people collaborated on tasks all day long, and knowledge was being constantly shared amongst the team.

This can be a major mindset change, and not all tasks lend themselves to being worked on by multiple people. However, it is worth seriously thinking where you can apply swarming on your projects to share knowledge and skills as well as deliver work faster.

Work in Progress Limits

WIP limits are a concept from Kanban that says you should limit the amount of work in progress at any given time, and actively avoid pulling more work in if you are at your agreed limit. Typically you might set this at the number of team members (maybe minus one for your ‘point man/woman’), or less if you often have more than one person on each task.

The idea here is that one person working on two one-week tasks at the same time will deliver them both at the end of two weeks (ish). However, if they work on one then the other they deliver the first after one week, and the second after the second week. They can also change direction after the first week if something more important comes up, and delay the second task. In the original scenario, they could change tack after one week but would leave two tasks ½ done. Given your team may well have more than one task per member right now, implementing a WIP limit to aim for would be an interesting experiment. Once it is reached, you can discuss in your retrospective if it has helped things or not. If you are using Trello, you can get the Free Agile Tools power-up to set WIP limits on your boards.

A tweak to the WIP limit for help desk teams is to leave some scope for the unexpected. For instance, for your team of six, you may have a WIP limit of two for planned work and a WIP limit of four for unplanned work that needs to be expedited.

T-shirt Sizing

Some teams are happy to have tasks without any estimate of how large they are. Others want to quantify that some are larger than others. A simple practice from Scrum and Kanban teams is to use “T-shirt sizing,” in which tasks are sized as Small/Medium/Large. Anything larger than that can often be logged as a project and split up into multiple T-shirt-sized sub-tasks.

Using this method avoids too much focus on assigning timescales or dates to work, which often leads to unproductive pressure to deliver work in a certain time frame (rather than to a certain level of quality). It can, however, be used to get an idea of how much work is outstanding if need be, and can be useful for the team to understand their upcoming work.

Daily Standups, NOT Daily Status Updates

This is something which a lot of agile teams still get wrong. The idea of a daily standup meeting is so ubiquitous now, however, there is one improvement worth considering.

Daily standups all too often turn into a daily status update with everyone reporting to the manager in the room. Ask yourself, would this meeting make sense if the manager wasn’t there? If not then you have a daily status update and are probably wasting most of the team’s time. Instead, if you focus on the work the team has on that day, walking down the Kanban board “Doing” list, you can discuss how they will move those tasks on that day. Each task usually has someone who is leading it that can say where they are at and if they need any help today. Others can offer help if asked, or possibly if they just see a way they can help get something to “Done” sooner than without their help.

An alternative might be to look at the outstanding projects and ask “What is stopping us moving this into “Done” today?” Then see how that can be resolved by the team that day. If anyone is talking about starting a new card, check first that there isn’t anything they can do to get something currently in progress closer to being finished. This can be a mindset change for people at first, but I find they often get the hang of it pretty fast.

Continuous Improvement

One of the best parts of agile processes is the focus on trying to continually improve the process. This ties back in to the first point about retrospectives but is worth repeating here. If you decide to adopt any of these practices, I hope you and your team adopt the idea of continuous improvement as one of your core values. The idea should not be to adopt a new process which will be better than your current one, but on adopting a focus on continuous improvement which can take inspiration from various places and lead to a better team next week, next month, and next year.