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 SituationThere 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.
ApproachesIn 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 scrumIn 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 ImplementationIn 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.
RealizationsFirst 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 StepsThe 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 FeedbackFeedack 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.
Given the road warrior life of a consultant, presenting at home is always a distinct pleasure for me. Next week, Bob Payne and I will be presenting at Agile Palooza in the Washington, DC metro area. This is my first time at an Agile Palooza event, and I'm interested in seeing how the dual tracks work out: learning agility for newbies, and advancing agility for seasoned agilists. For the advanced folks, I'll be covering scaling agile up to the enterprise with agile portfolio management.
It's been a pleasure for me to get involved with the Agile Project Leadership Network (APLN) after a hiatus of a few years. Several APLN chapters are doing well, and growing quite bit. The Houston and Bay APLN Chapters in particular seem to have the "secret sauce" in this area.
Suggest a topic
Subscribe to the RSS feed
