Tag Archives: multitasking

Multitasking adds to the task list (while diminishing avialable productive time). No wonder it’s trend!

Keith Ray posts this snippet of conversation:

Ron Jeffries posted his email conversation with Jon Eaves on XP mailing list in “Bug tracking vs user stories”

[ jon ]

“Projects that have developers working on multiple simultaneous projects have a 30% higher defect rate than projects with developers assigned specifically to it”

[ ron ]

Fascinating if true.

[ jon ]

I don’t remember the actual number, this is again from a previous life, but there was a higher defect incidence rate. We stopped this practice (or at least attempted to minimise it) and life was better for everybody.

Ok. So context switching uses tons of time, reducing productivity, and it also leads to higher defect rates.

Either those defects get shipped, or the poor harried programmers use their few remaining shreds of productive time to fix them. (It would be interesting to see what the Fault Feedback Ratio is in cases like this). How do folks make forward progress?

The other day I overheard a conversation between an overworked developer and her manager. The manager had just added on another task to the developers overfull plate. When the developer protested, the manager said “Well, you’ll just have to multitask!”

I cringed. Directing staff to multitask rather than setting clear priorities and focusing on the most important initiatives is an abdication of management responsibility. Period.

(And the manager may not have known:

— how to prioritize

— how to determine what the top priorities are

— how to say “No”

— how to get out of fire fighting mode

— how to sequence work

— the costs of multitasking.

But that’s another story.)

Advice for the Interupt-driven

Two recent posts (Focus, Focus, Focus and Breakthrough Thinking on Worker Productivity) talk about the effects of multitasking and interruptions. Spread a person across 4-5 tasks and interrupt her with phone calls, drop-ins, emails, beeps, and meetings and pretty soon no real work is accomplished.

Some people – managers and technical staff – try to compensate by coming in early or staying late, when they hope for quite, uninterrupted time. Unfortunately, for the success of the stay-late-come-early strategy, people end up doing both: they come early and stay late. Some work from home or come in on weekends. This adds up to longer hours. And prolonged overtime is a killer. Tired people simply make more mistakes.

Many corporate cultures tacitly or explicitly encourage long hours.

How can we break out of the pattern?

Don’t spread people too thin. The TOC folks will tell you that projects using the same resources actually finish sooner when they aren’t run in parallel. If you have doubts, see the data on context-switching (March 21). Or look at this paper on Frank Patrick’s site.

Ban overtime. An occasional short stretch of 10-hour days won’t hurt anyone. Prolonged overtime has a high price. Work hard for 40 hours a week and then go home.

Establish a Meeting Free Day. Some groups agree that they will not schedule or attend meetings on a particular day of the week. The Meeting Free Day is for heads-down work, and heads-down work on.

If you can’t pull off a day, establish office hours. Let people know when you’ll be available and when your door will be closed. When people know that you’ll be available from 8-10 and 3-5, in most cases they can hold questions. You may want to let people know what the exceptions are, too: fire, emergency, system crash… you choose. This goes for management and technical staff.

Make meetings effective. I see many organizations where people are in meetings for 5 – 8 hours a day. Usually they report that not much is accomplished in these meeting. So when they meeting ends without a resolution, the group agrees to meet again. When do people get work done? Make sure your meetings are productive. Productive meetings have a purpose and an agenda. Only the people who must be present to achieve the purpose of the meeting attend the meeting. No hangers on. And unless there is a direct on-call responsibility, turn off beepers, pagers, and cell-phones when the meeting starts.

Get rid of status meetings. Try daily 15-minute stand-up meetings to report on progress, obstacles and plans for the day. Problem solving can happen as needed, with only the people needed after the stand-up meeting.

Now try it. Breath. Close your door (if you have one, otherwise put out your Do Not Disturb sign). Think.

Focus, Focus, Focus

Bouncing off the evils of multitasking, C. Keith Ray (who just started his own blog) has this to say about how pair programming can counter some workplace interruptions:

Two effects pair programming has on tasking… in my experience…

It keeps the people focused on a single task (less likely to be distracted by emails, web-surfing, phone calls, people walking by, red herrings, trying the wrong design, bugs).

When one member of a pair does switch out of task to deal with a question or whatever, the other member can not only continue with the task, but also help the first one get back into the task, making switching (for a short period of time, like 5 or 10 minutes) less painful.

Still… I’d rather work on one project at a time, with the help of pair programming.

Other people report that people joining a project get up to speed much faster when pair programming, to the extent that “drop-in” programming is possible. In theory, this might allow some people to stay focused on one project (maintaining its continuity), and other people to switch projects frequently — I don’t know if this idea has been tested yet.

Keith makes a good point. It’s not just the number of tasks that wreak havoc. Interruptions from calls, drop-ins, meetings, announcements, loud music, questions, pagers, beepers, the latest crisis — can have the same effect on concentration and the same context-switching overhead.

Knowledge workers need periods of uninterrupted time to do their work — thinking. If people can’t find peace and quite in the cube farm, they’ll find it by searching out a deserted conference room or an unused storage closet. And if they can’t find a conference room or storage closet, they’ll come in early, stay late, or work on company holidays, because it’s the only time they can really achieve flow.

Breakthrough Thinking on Worker Productivity

I found a reference to this article in my morning stroll through blogland: Multitasking makes you stupid, studies say.

The article, by Sue Shellenbarger of the WSJ, points to evidence that multitasking doesn’t really save time.

A growing body of scientific research shows that one of jugglers’ favorite time-saving techniques, multitasking, can actually make you less efficient and, well, stupider. Trying to do two or three things at once or in quick succession can take longer overall than doing them one at a time, and may leave you with reduced brainpower to perform each task.

“There’s scientific evidence that multitasking is extremely hard for somebody to do, and sometimes impossible,” says David Meyer, a psychology professor at the University of Michigan. Chronic high-stress multitasking also is linked to short-term-memory loss.

Yet we’re clearly engaged in a long-term trend toward doing more of it. Some 45 percent of U.S. workers feel they are asked or expected to work on too many tasks at once, says a study of 1,003 employees by the Families and Work Institute in New York.

The effect on knowledge workers is huge. Jerry Weinberg wrote on this topic in QSM 1, Systems Thinking (Dorset House, 1992).

# of tasks = 1 – Time spent on task = 100%

# of tasks = 2 – Time spent on task = 40%

# of tasks = 3 – Time spent on task = 20%

# of tasks = 4 – Time spent on task = 10%

# of tasks = 5 – Time spent on task = 5%

# of tasks = more than 5 – Time spent on task = random.

Notice that when someone is working on four tasks, he is spending 10% of his productive time on each task. That adds up to 40% of his time. Where does the other 60% go?

That missing 60% goes to:

–breaking concentration on the task A

–picking up task B

–organizing materials related to task B

–remembering where you were last time you worked on task B

–establishing concentration on task B

–overcoming emotional inertia

–recreating the train of thought that got you to the current point on task B….

and so forth and so on.

The cost can be higher if the level of tasks is different — going from high-level design work, for example, to detail coding.

Here’s what really surprised me about the current reporting on the cost of context-switching: it shows up in Work/Life balance pages. It should be on the business pages — as breakthrough thinking on improving worker productivity and driving down costs!