Kanban for Service Desks

This content is syndicated from LitheSpeed's LitheBlog: Exploring Lean and Agile by Roland Cuellar. To view the original post in full, click here.

We worked recently with a client who wanted to apply agile principles and practices to their help desk and networking operations teams. Below is a brief case study of the situation, the methods that we employed, and some of the results.

The Situation
There are two small teams, the help desk team and the network operations team, that work primarily in support functions. Each team has two kinds of work: some planned projects and a lot of unplanned support calls.

The help desk takes support calls for a huge variety of internal issues, everything from printers that need new toner cartridges, to email outages, to software upgrades and pc problems. The networking team supports the LAN, back-office hardware infrastructure, and software infrastructure. Planning and managing in these environments is extremely challenging due to the constantly changing issues, help requests, ever changing priorities, and lots of simultaneous efforts. No traditional plan would survive even a few hours in this environment.

In addition to the constant requests for support, these two teams have some traditional project work to deliver. Project examples might be email system upgrades, network upgrades, new hardware installs, etc. The project work needs to be estimated, budgeted, planned, and delivered like any project. Trying to deliver on project plans for the planned project work is highly difficult in this environment due to the interruptions coming from the constant support calls.

We had already helped the software development teams in this company move to agile/scrum processes and the management desired a similar approach for these two support teams.

Approaches

In a typical software development environment there is often a lot of planned development work combined with some unplanned support work. But here, the situation was reversed: a lot of unplannable support work with some planned project work. The idea of scrum with its time-boxed iterations didn’t seem like a natural fit. Help desk calls, network outages, etc don’t lend themselves naturally to well delineated, fixed-scope scrum iterations and a two-week delivery cycle on a network outage is nonsensical. While we probably could have made scrum work, we decided instead to take a kanban approach for these 2 teams.

What is Kanban?






Kanban transfers in even smaller buckets than scrum


In a traditional waterfall process, we use large batches and huge amounts of work-in-progress as the planning paradigm. We do all of the requirements elaboration, then all of the design, then all of the coding, then all of the testing. These huge batches typically take months to deliver.

Scrum uses much smaller sized buckets. In scrum, we break the transfer-batch size down to two-week chunks. We do a little bit of requirements analysis, a little bit of design, a little bit of development, and a little bit of testing in order to deliver a handful of features every few weeks. By reducing work-in-process (WIP) to these small 2-week sized buckets, we can greatly accelerate delivery of high priority features.

Kanban is yet a further step towards even smaller batch sizes and a move towards a more continuous flow. Kanban eliminates the whole idea of iterations or sprints. In kanban, like scrum, we work on highest priority items but when an item is done, we can deliver it immediately, sometimes within a day or even within hours! … very small buckets indeed! This seems like a perfect fit for help-desk and support work. Requests come in, we actively prioritize them, we focus on the highest priority items, and deliver fixes often within hours. Though continuous reprioritization and continuous delivery, we can create a highly responsive organization.

In scrum, we achieve fast delivery through short 2-week deadlines of fixed scope. So how do we ensure fast delivery in kanban? We use WIP limits instead. We leverage Little’s Law which says that cycle time is a function WIP. The more work-in-progress we have, the longer it takes to deliver any particular piece of work. If we want very fast delivery, we could have a WIP limit of 1 and ask that the whole team focus on only one help-desk ticket at a time. The result would probably be very fast delivery for this one item but a lot of help-desk tickets would go untouched. If we wanted to touch more help-desk tickets simultaneously, we could have a WIP limit of 20. This would mean that the team could focus on the highest priority 20 items at a time. In this scenario, 20 items would get some attention but overall delivery time would suffer since we are juggling so many simultaneous tasks. The trick in kanban, is to find a WIP limit that finds a balance between these two extremes.

Kanban doesn’t get into things like daily standups, retrospectives, etc so it is even less prescriptive than scrum. If you want some additional structure, you could borrow from both as we did.

Our Kanban Implementation
In the end, we decided upon a mixture of both scrum and kanban. We wanted the iteration-less, continuous flow nature of kanban but we needed some additional support mechanisms to facilitate communications and continuous improvement. Our resulting process utilized:
• Kanban with WIP limits of 8 (more of this later)
• Daily Standups (from scrum)
• Retrospectives (from scrum)
• Point estimates and Burndown charts for the planned project work (from scrum)
Or to put it another way, scrum without iterations.

Each team had 4 people on it and so we decided to try an initial WIP limit of 8 and this turned out to work pretty well. This means that each person could be working at most 2 items at a time. If one item was blocked for some reason, there was another item that each person could work on. The job of team leadership was to take all of the support requests each day and prioritize them into the top 8 items.

We enforced the WIP limit through our planning board. Our planning board has a column called EXECUTING that has a limit of 8. So no more than 8 cards can be present in this column at any one time.



















Only a few items in EXECUTING but a lot in DONE!


Team members would meet each morning for a daily standup, review the priorities, and determine who is going to work on what. Periodically, we have retrospectives to see how the team is doing and where we can make improvements.

Realizations
First we set up a simple tracking board that had columns for backlog, WIP, and Done. We then asked the team to put all of the current work up on the wall. What we noticed was that there was a huge amount of work in WIP and only a few items in Done. Our goal was to turn that around. We instituted the WIP limit of 8 and within a few days, we had our WIP down to our target of 8 and we had many more items in Done! By limiting our WIP and focusing on the highest priority items, we were able to get much more work to an actual done state. And since these were the highest priority support items, we knew that we were delivering the most impactful work.

Working this way, we noticed that our team leadership needed to be more proactive about reviewing the work and assigning clear priorities. This became one of their primary functions. Daily standups have resulted in better visibility and cross-team communication, which the team has found valuable.

Finally, with this visual system in place, we noticed that our project work was falling behind. For actual planned projects such as email upgrades or hardware installs, we did typical scrum point estimates and release burndown charts. Tasks related to these projects were intermingled with the support tasks so that if there were no high-priority support-tasks, the team could focus on project work. After a few weeks, it was apparent that our project work was getting short-changed. So much time was going into support calls that there was little time left for the more strategic project work. While we had a lot of unplanned work in the Done column, and we were delivering outstanding support to our user community, our project burndowns showed that we were behind schedule for our planned projects. In other words, support work velocity was outstanding but project work velocity was falling short. Clearly, user support work was taking priority over more strategic projects. While we knew that this was probably the case, the board combined with the burndowns highlighted this problem clearly and showed quantitatively, how far we were behind on project work.

Next Steps

The obvious next step was to institute swim-lanes for the 2 kinds of work; planned project work and unplanned support work. We can keep the WIP limit of 8 since that is working well but divide it up into 2 parts. We can have a WIP limit of 6 for unplanned support work and a WIP limit of 2 for the planned project work. This means that we should always have 2 planned project tasks being executed at any particular time and this should allow us to start to make headway on the planned project work. Through experimentation with these 2 WIP limits, we can find a balance between delivering outstanding service and and delivering on the longer term strategic projects.

Team Feedback
Feedack from the team and management has been positive. The team reports having an improved system for managing support work, better visibility, and better clarity on priorities and WIP. Kanban is a deceptively simple but powerful system for visualizing and managing work. WIP limits force prioritization, focus, and delivery with minimal process overhead and high degrees of responsiveness. The kanban system has been a very natural way for these support teams to work that doesn't impose too much process overhead while still giving sufficient structure and visibility to managing the ever-changing priorities that are the nature of support work.

Leave a Reply

What is 10 + 6 ?
Please leave these two fields as-is:
Please do this simple sum so I know you are human:)

There are 101 ways to approach anything.
To find the best way, sometimes you need expert help

What People Say

“Kelly revolutionised the way our digital department operated. A true advocate of agile principles, he quickly improved internal communication within our teams and our internal clients by aligning our business and creating a much enhanced sense of transparency in the decisions the business was making. Kelly also introduced a higher sense of empowerment to the development teams...”

PETER SILVA-JANKOWSKI
IPC MEDIA

“Kelly’s a leading program director with the ability to take charge from day one and keep strong momentum at both a program and project level driving prioritisation, resourcing and budgeting agendas. Kelly operates with an easy-going style and possesses a strong facilitation skill set. From my 5 months experience working with Kelly, I would recommend Kelly to program manage large scale, complex, cross company change programs both from a business and IT perspective.”

LUKE SHARKEY /STRATEGY & IMPLEMENTATION LEADER
SUNCORP

“Kelly is an extremely talented and visionary leader. As such he manages to inspire all around him to achieve their best. He is passionate about agile and has a wealth of experience to bring to bear in this area. If you're 'lucky' he might even tell you all about his agile blog. Above all this, Kelly is great fun to work with. He is always relaxed and never gets stressed - and trust me, he had plenty of opportunity here! If you get the chance to work with Kelly, don't pass it up.”

GILES BENTLEY, DEVELOPMENT & OPERATIONS DIRECTOR
TIME INC

“Kelly is an Agile heavy-weight. He came in to assess my multi-million $ Agile development program which wasn’t delivering the right throughput. He interviewed most of the team and made some key recommendations that, when implemented, showed immediate results. I couldn’t ask for more than that except he’s a really nice guy as well.”

DAN PULHAM, DIGITAL DIRECTOR
TELSTRA

“Kelly and I worked together on a very large project trying to secure a new Insurer client. Kelly had fantastic commercial awareness as well as his technical expertise. Without him I would never had secured this client so I owe a lot to him. He is also a really great guy!”

GINA MILLARD
GLASS'S INFORMATION SERVICES

“Kelly came to the department and has really made a huge impact on how the department communicates, collaborates and generally gets things done. We were already developing in an agile way, but Kelly has brought us even more into alignment with agile and scrum best practices, being eager to share information and willing to work with us to change our processes rather than dictate how things must be done. He is highly knowledgable about agile development (as his active blog proves) but his blog won't show what a friendly and knowledgeable guy he is. I highly recommend Kelly to anyone looking for a CTO or a seminar on agile/scrum practices - you won't be disappointed!”

ANDY JEFFRIES/TECHNICAL LEAD
IPC MEDIA

“Kelly was a great colleague to work with - highly competent, trustworthy and generally a nice bloke.”

HANNAH JOYCE
GLASS'S INFORMATION SERVICES

“Kelly was engaged as a Program Director on a complex business and technology transformation program for Suncorp Commercial Insurance. Kelly drew on his key capabilities and depth of experience to bring together disparate parties in a harmonised way, ensuring the initiate and concept phases of the program were understood and well formulated. Excellent outcome in a very short time frame. ”

BRUCE WEIR/EGM
SUNCORP

“I worked with Kelly on many projects at IPC and I was always impressed with his approach to all of them, always ensuring the most commercially viable route was taken. He is great at managing relationships and it was always a pleasure working with him.”

BEATRIZ MONTOYA/CONSUMER MARKETING DIRECTOR
IPC MEDIA

“I worked with Kelly whilst at Thoughtworks and found him to be a most inspiring individual, his common-sense approach coupled with a deep understanding of Agile and business makes him an invaluable asset to any organisation. I can't recommend Kelly enough.”

PETER THATCHER, SENIOR ACCOUNT DIRECTOR
ThoughtWorks

“Kelly was a brilliant CTO and a great support to me in the time we worked together. I owe Kelly a great deal in terms of direction and how to get things done under sometimes difficult circumstances. Thanks Kelly.”

JULIE PEEL
GLASS'S INFORMATION SERVICES