Tuesday, 7 December 2010

Kanban for support

My last post covered 2 courses that I had attended on Scrum and Kanban in which I mentioned the similarities and differences I saw between the two.
I wanted to go into a bit more detail in relation to why I believe Kanban is ideally suited for support work so lets start with what Kanban is in software terms.


Kanban is a pull based system that focus’ on restricting the amount of work in progress (WIP) at any time, it is characterised by a large board that shows the state of work in system at any time. 
The board is very simple it consists of 3, or more, columns; the first column simply contains ‘cards’ with the work to be done in a prioritised list, the second column contains the items that are currently being worked on and the third column holds the ‘cards’ that have been completed.
The ‘cards’ for the work items may be written on index cards, post it notes, or anything else you want, with the card representing a piece of work to be done and each piece of work should be roughly the same size as all the others to enable consistent metrics to be gathered.
The image to the left shows a simple Kanban board with the 3 columns and as you can see the WIP column is limited to 2 items.
One thing that is different about this board is the addition of the extra line at the top of the board which I’ll come back to later.
That’s all there is to Kanban, as I said in my previous post it is a simple system with little or no management overhead, its one and only rule is limiting the amount of WIP.
What I’ve described here is basic Kanban, Kanban at its simplest, and often in development this will be enhanced by adding extra columns (test & deploy are common) to better capture the steps undertaken in developing software and you may also find a parked area at the bottom of WIP for work that cannot currently be worked on due to external factors blocking the tasks.
The metrics I mentioned revolve around the time it takes for a card/task/piece of work to move around the board.  So you should be able to track how long it takes from an item being added to the bottom of the ‘To Do’ column until it reaches the top, then you can track the time it takes to move across the board and get done. 
These metrics can help with some basic planning as you can then start to have a discussion with the business about when they may be able to expect any item to be done possibly even generating some SLA’s that can then also be monitored.

Using Kanban for support

So with a clear definition of Kanban why does it suit support work? 
Well the board provides a very easy and visible way to see how much support is outstanding and what is currently being worked on, if you add additional columns to the board you can also determine if items are complete and waiting for testing or deployment.
The ‘To do’ column allows you to know which items are the highest priority and should be done first; although there isn’t a rule against changing the order of items in the ‘To do’ column it will mess up the cycle time metrics so best to try to limit how often this happens.
Kanban’s rule about limiting work on progress nicely dovetails with support and needing to focus on solving one problem at a time, not trying to deal with multiple things at once.
When handling support you don’t want a process that will add a lot of management overhead, Kanban with no timeboxed iteration, task estimation, review meetings or scheduled retrospectives provides a light weight framework to deal with scheduling of the work to be done.
New items to be worked on can easily be added to the ‘To do’ list at any time and if following the normal basic Kanban rules you should be able to work out how long it will be before the item is completed.

Critical support issues

Now if you remember I said I’d come back to that extra line at the top of the board shown above, and this line is specifically for critical show stoppers, it is limited to just a single card/task/work item with the column limit set to 1 i.e. you can only do one at any one time.  This extra line allows you to handle these critical incidents without having to rearrange the whole board and is a useful visual tool so that other people know that there is a major problem that has to be dealt with now and should be expedited across the board possibly involving all members of the team.

Integration with support ticket/request system

There is one aspect of using Kanban where it falls down and that’s the physical board as it can’t integrate with any electronic systems and requires manual updating; now I’m usually the biggest advocate of physical boards as they make what’s happening extremely visible in the office, the danger of a virtual board is that if you don’t have a screen showing it in the office people don’t tend to go and look at it unless they have a specific need to do so.
For support though I believe the need to integrate the support system is paramount and the only way to do this is via a virtual board ideally with a link to your support ticket system that way you can get the best of both worlds, especially if you can get a large monitor or TV that can display the Kanban board at all times.  One such system is Lean Kit Kanban that exposes a nice REST API which you could then develop code against to integrate with your support system to enable the use of Kanban to manage the support.

So who’s doing this?

I did a little bit of research, far from exhaustive, and found some links to companies that are utilising Kanban for support:
I would suggest that you take the time to read these articles and see how other companies have implemented Kanban for handling their support work.


To sum up:
  • Lightweight process adds little or no overhead
  • Visual, easy to see how much support there is in the system
  • Rule limiting work in progress helps ensure people focus on the item they are working on
  • Physical board not a necessity , in fact probably want to use a virtual/electronic board
Hopefully I’ve shown how I believe Kanban fits in with support work and how you could utilise it to help you better manage your own support.


  1. Thanks a lot for sharing. The links to "So who’s doing this?" was useful. Pls note that only link 2 and 4 launched for me.

  2. Using the Wayback machine I've corrected those links so you should be able to get at the articles now

  3. How do you handle to flow of work which comes back from test? How do you show it's flow back through the board/system? Do you use the critical lane? You can only have two pieces of work in progress so if a piece comes back, you now have three, what happens to the work you are in the middle of working on?

    Thank you,


    1. Hi Brett,

      You won't be surprised that you aren't the first person to come across this situation and there are many different ways that this can be handled.

      First off you shouldn't use the critical lane, that lane should exist purely for things that are effectively stopping a live/prod system from working. If a card appears in this lane normally the whole team should swarm the problem to resolve it.

      Ideally the tester should come to the dev and they fix the issue together, this keeps the WIP limits satisfied and allows the work to be fixed.

      The board is supposed to show the flow of work though so if you are actually moving work say from a test team back to dev then as long as the team is happy to allow it there is no reason that shouldn't be reflected in the board.

      This is likely to break WIP so the team needs to agree what they are going to do, do you add a section at the bottom of dev specifically for these items? do you break the WIP and have the devs swarm to sort it out? its down to the team to agree how to handle it (perfect topic for a retrospective).

      For a bit more reading on this try:
      - Should we move a failed story back
      - Never Move Items Back on a Kanban board
      - The Kanban Story: Moving Cards Back

      There are numerous approaches to this, ultimately its down to your team to decide how to handle it, just be aware that this happening should be a trigger to discover why it happened and how to avoid it in the future.

      Hope that helps

  4. Hello,

    We have a process where we are supporting many applications and each application has a dedicated support person. For ex: When an issue arrives related to X application we assign it to X person, when an issue arrives reated to Y app, we assign it to Y person. So I could not figure out how I can shape the board in that process ?

    Also, wthin a day we have a continous flow of tickets coming. Should we add to the "to-do" list everytime new ticket arises ?

    Reading the explanations above were very clear but I had obstacles to fit it to the current processes. I would appreciate if you can give an advice.

    Thanks in advance.

  5. I'm going to answer your questions in reverse order,

    Assuming that you don't have hundreds of support tickets then yes you should add to the to-do list everytime that a new ticket is raised. If you have hundreds of tickets then I suspect you have a different problem to tackle.

    Ideally when these new tickets are added they should be prioritised by the business so that the team is always working on the most ticket with the most impact.

    With all the tickets prioritised by the business the support people can simply pick the highest priortity item to work on.

    Whilst having dedicated people to support specific apps I would humbly suggest that if you are able to allow anyone on the team to pick up any tickets you gain by the team as a whole being able to better handle peaks & troughs on any of the applications, with a bonus that your board stays the same.

    If you have to keep dedicated people per application then my best suggestion is to use horizontal "swim lanes" to divide the board on a per application basis so that all the items on the board for an app will live within that lane (to-do, WIP & done).

    Does that help?

    1. Hello Again,

      Thank you very much for your prompt answer. It was very helpful. First, I will try to use horizontal "swim lanes" to divide the board on a per application basis. If it doesn't work, I will try to widen our support process (if you have any, can you please send some photos)

      Since I'm a beginner on this topic, everytime I try to shape the process, I figure out a new question :) I hope you can help again.

      We are using an incident management tool called "Remedy" and make our ticket assignments from there. In that respect, should we create a virtual/ online board so that maybe coordination with the incident management tool is easier (as you suggested on your article) or do you think that a physical board can be beneficial as well ?

      Best Regards

    2. Apologies for not responding before, I completely lost track that you had replied.

      When I mentioned broadening the support process it was more around individuals skilling up on other products so that people on the team could swap between support items easily, giving you more resources to be able to work with. Doing this wouldn't require any change to the board as such more to the people handling the work to get their skills up on the products they don't work on.

      I would definitely suggest creating a virtual/online board for the data that is in Remedy and to try and make this as visible as possible. The difficulty with electronic tools is that they are often "out of sight, out of mind" and aren't used to full effect.

      I would only suggest having a physical board if you don't use the electronic system (which I would imagine would be very unlikely) even though a physical board is often better for visibility and people keeping it updated.