The Evil of Multi-Tasking

Multi-tasking is an evil that reduces our effectiveness. We think that if we are doing two tasks at the same time, we give both 50% of our time. Well, it can be the time that we split 50% for each. But we don’t split our performance 50% for each, it is much lower than 50%. Probably it is only 45% or even low as 40%, and 10-20% of performance is simply lost to the evil of multi-tasking. The more we multi-task, the more performance is lost to the evil of multi-tasking. Every time we switch from context to another we waste time and that makes multi-tasking expensive. Also our brain can’t focus because some part of it is thinking about other ongoing tasks.

It is not just an individuals’ problem; multi-tasking within a team is also a waste of effectiveness. I once was in a scrum team where each member had their very own (big) features that they coded alone. Unfortunately, not a single feature finished successfully on time. At that time I didn’t clearly understand that we wasted our time for the evil of multi-tasking but later on I’ve realized why we didn’t succeed. Multi-tasking was the team’s biggest mistake.

But is multi-tasking really that bad? Isn’t it effective if we do many tasks simultaneously and finish them earlier? The answer is clear: multi-tasking is waste, just don’t do it. I will explain this more in this blog post. By multi-tasking we just start those tasks earlier but we finish them later.

Newsletter Mailing Simulation – You Finish Later by Multi-Tasking

In The DevOps Handbook by Gene Kim et. al. there is a newsletter mailing simulation that explains why we finish later if we multi-task. The task is to send five newsletters. Sending one newsletter has four steps: folding the paper, inserting the paper into the envelope, seal the envelope, and finally stamp it. Each step will take the same time. We simulate mailing newsletters with two different strategies: large-batch and small-batch strategy.

In the large-batch strategy, we do one step for all five newsletters before moving to the next step. First, we fold five papers, after that, we insert those five folded papers to the envelope, then seal each envelope and finally stamp all five envelopes. The first impression might be that this is a good strategy but surprisingly it isn’t.

On the other hand, in the small-batch strategy, we do all steps to one newsletter and finish it before starting next. We will first fold one paper, insert it immediately to the envelope, then seal the envelope and stamp it. After stamping the first envelope we will start processing the second newsletter etc. At first, this strategy feels like not using all available capacity, but it turns to be better than the large-batch strategy.

Look at the image below. It is the visualization of both strategies. With the large-batch strategy, we get the first newsletter ready after 16 steps. While with the small-batch strategy the first newsletter is ready after just four steps. That is a huge difference! The second newsletter takes time 17 steps versus 8 steps which is also a big difference.

Consider yourself as a customer waiting for a newsletter. Which strategy would serve you better? Four out of five you will be happier with the small-batch strategy because you will receive your newsletter much earlier. Only as the last receiver both strategies are equal. The message is clear: working with the small-batch strategy is much faster than the large-batch strategy.

But what is the above simulation’s relationship with multi-tasking? Think of each newsletter as one task. When we try to multi-task and work with many newsletters at the same time, we are using a large-batch strategy. We think we are efficient but the truth is that each task has to wait for much more to finish. Whereas working only one task at the time there is less waiting and we finish our tasks quicker.

Quality Issues Make Large-Batch Strategy Even Slower

In the newsletter mailing simulation, we didn’t yet pay attention to potential quality issues. Unfortunately, the reality is that there will be quality issues and errors while working. The earlier simulation assumed that everything goes fine without any problems. When we insert some problems there, we will find that the small-batch strategy will even knock out the large-batch strategy.

Assume that we have a problem in the last stamping step but at the beginning, we don’t know it yet. We will notice this when we stamp the first envelope. And we will fix it immediately.

In the large-batch strategy, the first stamping steps are done in the 16th step. So in the large-batch strategy, we have done useless work of 15 steps before we realize the problem and we have to make a fresh start. In this case, we use the first 16 steps, then fix the problem, and redo all 20 steps before sending all newsletters. That is a total of 36 steps + fixing the stamping problem.

While in the small-batch strategy we realize the problem much earlier because we make the first stamping step at the beginning in step 4. Then we fix the problem and have to redo only one newsletter. Compare this to the large-batch size where we had to redo five newsletters. With the small-batch strategy, we use the first 4 steps, then fix the problem, and then do again 20 steps. That is a total of 24 steps + fixing the stamping problem. The small-batch strategy wins the large-batch strategy with 12 steps! We could’ve sent three more newsletter at the same time compared to the large-batch strategy.

This example is more about delivering small updates regularly versus one big release after a few months. If we wait for the release longer we don’t detect our problems early and we deploy bad software. And fixing that problem will be more expensive later than at the beginning of that feature. In contrast, if we deliver small updates often, we can find problems sooner, and fix them faster. In the newsletter stamping problem example, we had to redo all five newsletters. In the worst case, this could happen to our software if we delay deploys to big updates.

Reduce WIP in the Team and Get More Done Faster

Dominica DeGrandis introduces the five thieves of time in her book Making Work Visible:

• Too much work-in-progress,
• Unknown dependencies,
• Unplanned work,
• Conflicting priorities and
• Neglected work.

We have explored parts of the first one: too much work-in-progress (WIP). In the previous newsletter mailing simulation, we saw how bad effect does multi-tasking and too much WIP have to our throughput. We simply finish much later if we try to multi-task and have too much WIP.

To be more effective, we should keep our WIP low. That is valid also for teams. If every developer in the scrum team is working with separate features, it is a sign of too much WIP and multi-tasking. Look again at the newsletter mailing simulation image and imagine this situation. When is the first feature ready if everyone has their very own features to work with? After 16 steps (if there aren’t any problems!). What if the whole team works together by pair/mob programming with one feature and finishes it before starting to work with the next feature? In theory that would take 4 steps, but practically it would be little more because of some overhead. In any case, we will have our first feature done sooner and can make a customer happy by delivering that feature faster.

When we start a new task before finishing an older task, our WIP goes up and things take longer to do.

Dominica DeGrandis

We should work more as a team and not a group of individual developers. That is the way we get stuff done, not just starting to develop new features that won’t finish. Work in progress does not add value to the customer. The finished work does! By working together we can do it better.

Conclusion

In this blog post, we’ve seen how the evil of multi-tasking makes us work more slowly, not faster. That is true also with teams, not just individual developers. The newsletter mailing simulation (the image in this blog post) illustrated to us how much better the small-batch strategy (low WIP and not multi-tasking) is compared to the large-batch strategy (much WIP and multi-tasking). We also looked at how not finishing tasks reduces our throughput and we don’t deliver new features to our customers on time if we have high WIP. To conclude my message in this blog post I want to say:

Beat the evil of multi-tasking by following this rule:

Stop starting, start finishing.

Sources

• Making Work Visible by Dominica DeGrandis
• Single Piece Flow by Stefan Luyten
• The DevOps Handbook by Gene Kim et. al.