How Multitasking Guarantees Low Customer Satisfaction

Two Hours of Waiting, an Hour and a Half of Waste, and a Burrito

One day last week, I took what was supposed to be a quick lunchtime ride to my local bike shop to have a faulty bike computer fixed. Unfortunately, it turned into a two hour illustration in how multitasking harms lead time, predictability, and customer satisfaction.

I arrived at 10:15, just after the store opened. I explained my problem, and they immediately assigned a mechanic to put a new computer on the bike. I asked how long it would take. “10 or 15 minutes,” he said. So I went out to a bench to work on email.

Twenty minutes later (allowing for some estimating error), I went back to pick up my bike. They were still working on it. But now, instead of just my bike on a repair stand, there were three more. I watched them start work on two more as customers brought them in over the next few minutes. That’s six bikes being worked on. Or, more accurately, six bikes on repair stands—there were only three people working in the store, and at least one of them needed to be available in the retail part of the store for sales.

I waited in the store for another 20 minutes or so. A few small repairs went out and a few more came in, but my bike still wasn’t done. My granola bar breakfast was wearing off, so I gave up waiting there and crossed the street to get a burrito for lunch. When I came back 40 minutes later my bike had just been finished.

What happened? Was the mechanic just bad at estimating the job? I don’t think so. Installing a bike computer definitely can take longer than you might expect—it’s hard to get the cable length just right. But if he’d focused on just that job, he’d have finished in 15 or 20 minutes, certainly within a half hour. Instead, he bounced back and forth between my bike and three or four others. Everyone’s repair took longer than it should have and longer than he estimated. By multitasking, he undermined his ability to predict completion times. Who knows what jobs would come in while he was working on mine? In exchange for that lost predictability, he gained the appearance of responsiveness as he started each job quickly.

It’s Not Just Bike Shops

Software organizations do the same thing. In fact, I often tell teams that if my job was to destroy a team’s productivity, the first thing I’d do is find ways to get them multitasking, to increase work in process (WIP). Increasing WIP is well known to increase lead time, even with immediate switching between tasks. The time required to switch tasks in knowledge work like software development makes the problem even worse. It doesn’t take much WIP before more time is spent switching tasks than actually completing them.

Agile approaches like Scrum and XP help somewhat; they get teams working on prioritized, well defined chunks of work. But I often see organizations in which key resources like system engineers or DBAs are assigned to many projects. As these people multitask across several projects, their availability to each individual project becomes unpredictable. Then, when work on a feature hits a dependency on one of these scarce resources who’s not available, the team moves onto another feature, increasing their own WIP. I’ve seen teams with shared resources frequently reach the end of a sprint with every sprint feature in progress and none complete, all either waiting on a dependency or with too much work to complete after the dependency was resolved.

How Do You Fix This Problem?

  1. Start with a presumption against multitasking. Use an approach like the 5 Whys to dig into why someone needs to be assigned to multiple projects.
  2. Reduce dependencies on shared resources. Look at the tasks they do and consider which tasks really have to be done by that person and which could be done by other team members, perhaps after some training.
  3. If you can’t fix it now, make it more visible. For example, modify your task board to feature the task area where things get stuck. Or put up a big number representing the current stories in process. (More on these options, including examples, coming in a future post.)
  4. Get some help. Sometimes, it takes an outsider to point out to management that they’re sabotaging their results by forcing their team to multitask. It often seems like half my work as a coach is saying the things everybody knows but nobody can say.

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *

Richard Lawrence

Is co-owner of Agile For All. He trains and coaches people to collaborate more effectively with other people to solve complex, meaningful problems. He draws on a diverse background in software development, engineering, anthropology, and political science. Richard is a Scrum Alliance Certified Enterprise Coach and Certified Scrum Trainer, as well as a certified trainer of the accelerated learning method, Training from the Back of the Room. His book, Behavior-Driven Development with Cucumber, was published by Addison-Wesley in 2019 (for more information, visit bddwithcucumber.com).

Connect

richard.lawrence@agileforall.com Twitter LinkedIn Subscribe to RSS Feed Blog posts by this author