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 let's start with what Kanban is in software terms.
Kanban
Kanban is a pull based system that focuses 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, it's 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.
Metrics
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 SLAs 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.
Summary
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, you 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.
CodeProject
