Let me give you an example of one of the costs of multitasking—the "switching cost." You've probably heard about it before, but this simple little exercise will help make it real. Go grab a friend who has a second hand on his watch and ask him to time you. Trust me, it's better to do this than just read it. It only takes a couple of minutes to complete.
Take a blank piece of paper or a whiteboard and draw three columns.
You are going to execute three projects, first using multitasking, then not. Your friend will time you for each.
The three projects are as follows:
Project 1: Write the letters A to J in the first column.
Project 2: Write the numbers 1 to 10 in the middle column.
Project 3: Write the Roman Numerals I to X in the third column.
The end result is three columns filled like this:
A | 1 | I
B | 2 | II
Etc.
Start with the multitasking scenario, which involves completing one row at a time. You need to complete the three columns, working row-by-row across the page, starting with A then 1 then I in the first row, working down the page until all three projects are complete.
Note your time.
Now start the non-multitasking scenario, which is where you start one project, complete it, then start the next project. In other words, you should start with column 1 and write down the page A to J, then move to the second column and write 1 to 10, then move to the next column writing I to X. Don't forget to time yourself.
Unless you are some freak of nature then you should see that you were faster when you didn't multitask—even though you did that scenario second and would presumably have had some benefit from having completed the exercise once. Go on, confess: You didn't even need to look at the timings did you? Multitasking just felt slower. Did you make any mistakes when you multitasked? I did. But perhaps I'm not the best example here—I have to turn the radio down when I go through traffic lights.
Yes, I know, this example is contrived. But isn't real-life multitasking worse than this? Have you ever been in the situation where you've switched back to a task you were working on a few days or weeks ago, looked at it, and asked yourself, "What on earth was this about?" Our wee human brains aren't great at remembering huge amounts of detail. Can you remember what you had for dinner last night? How about the night before?
One of the key reasons why the agile approaches work is that they allow people and teams to "single task." That is, agile forces us to focus on doing just one smallish thing at a time. Iterations limit the amount of features a team can start, and most teams quickly discover that it is far easier to have each person working on one task at a time. Well-run maintenance teams tend to work on just a few small tasks at one time. Working in small batches is the key innovation of lean manufacturing and lean and kanban software teams. It's a lot easier to get one smallish thing right at a time than it is to get one large thing right or many small things right.
Run through the exercise one more time, and have your friend time just how long it takes to complete each project (column) in the two scenarios. Now imagine that, instead of it taking a few seconds per digit, it takes you a month per digit, and imagine that you get paid at the end of each project. Once you've done this exercise, take your numbers to your accountant and ask him which business is going to be the most profitable, have the happiest customers, and last the longest—the one whose projects finish quickly or the one where team members multitask and each project takes roughly three times longer to complete. That kinda makes the productivity loss from task switching seem small.
