Over a million developers have joined DZone.

Cost of Delay Due to Multitasking, Part 2

· Agile Zone

Reduce testing time & get feedback faster through automation. Read the Benefits of Parallel Testing, brought to you in partnership with Sauce Labs.

In Cost of Delay: Not Shipping on Time, Part 1, I introduced you to the notion of cost of delay. I said you could reduce the cost of delay by managing your projects: have shorter projects, using release criteria, or selecting a lifecycle that manages the risk.

Sometimes, you don’t have short projects, so projects get backed up, and your managers ask you to work on several things at once. Or, the managers can’t decide which project is #1. Somehow, you end up doing several things “at once.” This is the multitasking problem, and this is the cost of delay in this part.

You know me, I hate multitasking. The costs are significant. But those are just the costs of multitasking on the work you are doing now. That has nothing to do with the cost of delay to your projects.

In Manage It!, I have this nice picture of what happens when you try to multitask between two projects.

Two Tasks or Projects

Two Tasks or Projects

Imagine you have two projects. Each of them should take a week. Hey, they’re short projects. I’m trying to illustrate a point.

You can deliver one of them at the end of the first week. You can deliver the second one at the end of the second week.

But, imagine you have to multitask between them. Instead of being able to deliver anything at the end of the first week, you can’t deliver anything at all until the second week. And, depending on how much context switching you do, you might not be able to deliver anything until sometime during the third week. The blue boxes show the time lost due to context switching.

Effect of Multitasking Delay to Delivery

Effect of Multitasking
Delay to Delivery

This is a huge cost of delay due to multitasking.

How do you calculate this?

“Big” is not quantitative enough for some people. This is where using some of the tools from the people who do this for a living might be good.

I’ve always drawn a picture like this and explained, “I don’t know how to estimate the time in the blue boxes. The blue boxes are the delay times. I can’t estimate them, because everyone else is delayed by multitasking on their projects, too. Sometimes, it takes me an entire day to get an answer to a question that should only take me an hour to get an answer. All I know is that “ideal” time is irrelevant to actual time. And even calculating using relative estimation is hopeless. That’s because we are multitasking. All of our estimations are out the window because we are multitasking.

“The amount of time we spend working on a project might be accurate. It’s the wait time that’s killing us. I don’t know how to estimate that.”

What I’ve done before is take a two- or four-week window, and ask people to write down their predictions of what they thought some task would take. Then, I ask them to write down, as they spend their time on each task, how much time they actually spend on each task. Now you can compare the prediction to reality.

Remember that all of the context switching and wait time is the time you need to remove from the maximum sales revenue, had you released the product.

This is very difficult to do. It saps the morale of the people doing the work. They quickly realize how often they go back to the same thing, over and over and over again, making zero progress, trying to realize where they are. Do not do this for more than a four-week window. If you must do this, label this an experiment to obtain data. Explain you are trying to obtain actual work time, context switching time,  and wait time. Let people label the time as they will.

The managers will be astonished by how little time the technical staff spend on real work. They will be amazed by how much time the technical staff spend on context switching and wait time. This is why managers think technical staff are bad at estimation. Who can be good at estimation when they are multitasking?

The problem is this: the cost of delay due to multitasking is real. It’s invisible to most people, especially management. It’s not just the cost of the blue boxes in the picture above. It’s the fact that nothing gets out of your organization until the end of Week 2 or later. Remember the back of the napkin in Part 1? Even if you use that calculation, you can see you are losing revenue left and right due to multitasking.

Remind the managers: Remember that all of the context switching and wait time is the time you need to remove from the maximum sales revenue, had you released any of the products.

Can you use this as an argument for your managers to end the multitasking and manage the project portfolio?

Cost of delay due to multitasking is real. What would you need to know to calculate it in your organization?

The Agile Zone is brought to you in partnership with Sauce Labs. Discover how to optimize your DevOps workflows with our cloud-based automated testing infrastructure.

Topics:

Published at DZone with permission of Johanna Rothman, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

SEE AN EXAMPLE
Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.
Subscribe

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}