I found this gem recited in an email a while back and saved it, without really remembering who wrote it. If you know, please feel free to help attribute it. It quotes Goldratt's /Critical Chain/:
There’s a lovely example of the evils of multitasking in Goldratt’s Critical Chain.
Suppose you have three things to deliver: A, B and C. Suppose they all take, I don’t know, 2 days each to complete. If you did them one after the other, A will be finished by day 3, B by day 5, and C by day 7. AABBCC.
Now suppose you want to satisfy the people who commissioned B and C that you’re paying attention to them, and you decide to multitask. So you decide to split things up, and work on them in one day blocks, ABCABC.
The result is that now A is delivered on day 5, two days later than before, and B is delivered on day 6, one day late, and C is delivered on day 7, no earlier than it was before. You’ve potentially pissed off two people for no benefit.
If you work through the example with shorter and shorter timeslices you can see that the more finegrained your multitasking, the later all the tasks become.
Of course it’s worse in the real world because of the overhead of context switching, something computer scientists know all about.
I find that when I allow myself or my team to be overwhelmed with tasks, we lose all effectiveness to get any of them done. I have vowed to never interrupt a task in progress other than if 1) I don't want the task to be completed at all, or 2) ordered to do so by a superior. I think that law is easy to work with, and it helps a bit. It is hard to defend, because people want everything imaginable to be done or at least in-progress. But that's not lean, not agile, and not even reasonable.
Make value, not inventory. Don't spread the workers' attention thin.