3.9 10

Applying Kanban to IT Processes 2: Support Team

originally written by

Our summary and key takeaways

This is a great example of applying Kanban for typical service work - a fictional helpdesk environment, where the team was staring to do Kanban from scratch. Just before making these changes, the team was painfully understaffed, overworking themselves just to stay on top of the tickets, nevertheless making their response time way to long. After a couple of months, more people were hired and the need for huge overtime generation was lessen. The backlog of works got churned and things seemed to go back to normal - however, there didn't seem to be much improvement in the overall delivery rate and the process was just as chaotic as before.

Step one: What can be done to make a change?

First, there was an analysis of the current process. Simple fact gathering exercise - how things get done, how long it takes, who does which part. The team was getting requests from email, phone, website or else, and either dealing with them right away, or making basic notes to perform them later. Once the tasks were done, there was no follow-up to see if what they delivered met the users expectations, nor were the completed tasks recorded in any way.

Step two: Put it on a board

The key here was to start small. Rather than introducing process changes, all that was proposed was a visualization of the current process on a board, divided into Pending Tasks, In Progress, Pending Feedback and Done. Also, there was room left for horizontal lanes for each member of the support team. New requests were written on sticky notes (with preset information fields, like date and short description) and placed in the Pending column. As the card progressed through the board, everyone was aware of what the team was doing and could track down a particular item with no difficulty. At swiping the card to the Done column, a completion date was entered, making it easy to measure delivery time.

Step three: Expand the board

After a couple of weeks of getting used to the board, the team has come up with an idea to add a separate swimlane for requests, that have been escalated to next support level, development or elsewhere in the organization. Since their work on them has been stopped, but the requests are not finished, this was a great way of making sure they are still on record.

Step four: WIP limits

The next step was making this board finally Kanban-like, by setting limits to how much work can be done simultaneously at a given time. The team was allowed to work on one item each - on the board there was room made for 2 tasks queuing for one person and one "home" WIP column, indicating what this person is doing right now. Even more transparency of workflow then.

Step five: Task execution

To ensure that the team was using the pull method, another small board alteration was made: there was a shaded area added to the Pending Tasks column. This area highlights the tasks, that are fully ready to be worked on, so that the team knows the prioritized tasks from the rest.


By gradual learning to work with a visual board and then with Kanban, the team has gained great process visibility and transparency, but mainly - they streamlined the workflow immensely. Before, people were multitasking, wasting time on context switching, not giving their full attention to any of the task in process. They also gained the ability to easily monitor and perform follow-up communication with product users. Overall, the main benefits of applying Kanban to this support team were:

  • ability to monitor and measure delivery rates
  • measurable results
  • task status accessible at a glance
  • more accurate estimates
  • far better morale
  • improved productivity

Moreover, the great benefit of doing Kanban both in this particular case, as in any other, is doing it on a whiteboard - a medium, which encourages change and therefore asks for improvements. As one of core Kanban rules is continuous improvement, it's highly recommended that teams use modifiable means of process visualization, rather than print-outs.

Read an article on Kanban board examples »