It may sound hard to believe, but multitasking is an effective way to get less done. Juggling multiple tasks at once interrupts your focus, which can cause you to spend more time on each task than if you had completed them one at a time.
While research proves the harmful effects of multitasking on productivity, many of us still approach our work with an attitude of “do all the things, and do them right now.” It’s especially true for IT Operations teams that are overloaded with handling new requests and keeping production stable. In our experience, that describes every IT Operations team we’ve ever worked with.
Kanban seeks to minimize multitasking by employing work-in-process (WIP) limits at strategic points in a team’s process or workflow. True to its name, a WIP limit is a tool for limiting how much work can be in process at one time, thereby helping to expose bottlenecks and improve the flow of work. Here’s what IT Operations teams can learn about using WIP limits to get more of the right work done at the right time.
The Bottleneck Effect: A Case Study
An IT Operations team at a company we worked with had a workflow where the final step in the process (before Done) was Validate. There was no process at the time that allowed for timely feedback so, after they were delivered, work items stayed in Validate. The norm was to assume that everything was okay, provided no one complained.
While work sat idle in Validate, people pulled more work out of the backlog into Implement. The Validate queue grew and grew until it had close to 100 work items. The Kanban board below shows what this looked like, with the bottleneck stacking up in the Validate queue.
Above: A physical Kanban board showing a bottleneck in the Validate queue
Many of the items delivered were indeed satisfactory, but some were not, which made the downstream customers unhappy. When they mentioned the work hadn’t been delivered as they expected, the IT Operations team took a long time to respond because they were already on to the next task.
As time grew between customer feedback and IT Operations response, the unhappy customers became very unhappy and eventually gave up trying to communicate. They complained amongst themselves and to other departments: “Ops never respond,” “They’re like a big black hole,” and “What a worthless team.”
Eventually, the IT Operations team’s reputation began to slide down the drain. They were trying to do so many things at one time that they couldn’t do anything well. As Steve Uzzell says in Gary Keller’s book, The ONE Thing: The Surprisingly Simple Truth Behind Extraordinary Results: “Multitasking is merely the opportunity to screw up more than one thing at a time.”
How Much WIP Does Your Team Have?
Here’s an exercise to try: Query your ticketing system (ITSM tool or similar) to reveal the work items that haven’t been touched for a period of time (e.g., 60 days). Compare that outcome with the work that is getting finalized. Is the result discouraging? If yes, have a good, old-fashioned conversation with the team about finishing work before starting new work. Try doing it by ticket type so you can see which tickets goes smoothly and which get stuck on the way.
Above: A LeanKit board showing WIP limits in Plan, Develop:Done, and Deploy
In an effective pull system, WIP limits facilitate conversations that can shift the organization from an authority-focused, must-do-all-the-things approach to a dialogue around what-is-the-best-thing-to-do-right-now, based on a collective agreement of the real business and economic goals and the team’s capacity to do the work.
Problems Caused by Too Much WIP
In addition to creating delays in the delivery of business value, too much work in progress masks two other major problems:
- Busyness is mistaken for productivity.
- Fast feedback is thwarted.
When busyness is mistaken for productivity, everyone looks like they are busy, but tangible outcomes for delivering value to customers are lacking. Not a good place to be if you’re serious about being successful. Too much work in progress equates to saying “yes” to too many things. When you have a tendency to take on more work than you have the capacity to do, setting and adhering to WIP limits is a way to stop the pandemonium and to give yourself (and your people) permission to say, “Sorry; not today.”
When people have to wait too long before they receive feedback, the value of the feedback decreases. They move on to the next thing, and they no longer have the time to take the feedback on board. Consequently, they lose the opportunity to improve their work. The Lean philosophy is big on removing waste, but it’s hard to see waste unless you have delivered something and received feedback on it. In the Kanban world, value trumps waste reduction, and fast feedback is a great way to provide value.
The Bottom Line
It’s easy to cast aside an aging request when a shiny new request arrives in the backlog. But the cost of starting new tasks before finishing the old tasks can be high. When too much work is in progress, negative issues occur: multitasking increases, bottlenecks develop, dependencies rise, windows of opportunity slip, and holidays arrive. And, because progress is delayed, people pile more work on. This causes the work to take longer than it should and delays the delivery of value to the business. Using WIP limits can help your team reduce multitasking and focus on finishing the work that matters most.
New Guidance Paper Coming Soon: This blog post is an excerpt from the forthcoming guidance paper Using Kanban in IT Operations, co-authored by Dominica DeGrandis and Kaimar Karu. A joint effort by LeanKit and Axelos, the guidance paper will be available at the DevOps Enterprise Summit, held in San Fransisco from Nov. 7-9, 2016. Pick up your printed copy at the event, or follow us on Twitter for the digital copy release announcement.
WIP Limits: How to Journey Safely into the Unknown
Interested in learning how to start using WIP limits with your team? This three-part blog series and webinar will serve as your guide, explaining not only the common obstacles you’ll face but also how to overcome them. Start Now.
About the Authors
Kaimar Karu is the Head of Product Strategy and Development at AXELOS, leading the development of ITIL and PRINCE2. He and his team are focused on helping organizations and individuals get the most out of the frameworks and methodologies in the AXELOS portfolio.
Dominica DeGrandis teaches Kanban to DevOps enthusiasts. As Director of Training and Coaching at LeanKit, Dominica combines experience, practice and theory to help teams level up their capability. She is keen on providing visibility and transparency across teams to reveal mutually critical information.