How many times have I read in a CV “good multitasking skills”. Sorry but that is not a good selling point to me. In this article we are going to go through why you should avoid multitasking at every level, as an individual but also as a team, for logical and physiological reasons. We’ll also give you techniques to avoid multitasking and even a very simple serious game that can help you demonstrate the concept to your team.
We covered Little’s Law in articles before and it has a very central place in the ideas behind Kanban. It tells us something very simple: adding more Work in Progress without increasing the efficiency will always increase the Lead Time. In other words, if you work on multiple tasks at the same time, it will take you longer to finish these tasks than to do them individually.
Lead Time = WIP / Throughput
Okay, maybe applying this to an individual a slightly convoluted… But it becomes very clear when applied to a dev team!
The human brain is terrible at context switching. It takes us about 15 minutes get passed “the Wall” and start really focusing on a task, to be “in the flow”. But even the smallest perturbation (a notification, an “urgent” email to answer, …) will move our focus and force us to get through the Wall again. If you work on multiple tasks at the same time, you eventually never even enter the “flow” state and you are never as efficient as you could be.
Now that you have an idea why multitasking is bad at team and an individual level, here are solutions.
If you haven’t heard of this already, there is a lot a literature about it and I encourage you to at least try it for a couple of days. This idea is simple: pick a task, set a timer for 25 minutes and get after it. This means no distractions whatsoever, no notification, no looking at Slack, strictly no interactions other than your task. After 25 minutes, you take a mandatory 5 minutes break from your task. Stand up, stretch your legs, get a coffee, answer desperate messages on Slack, … Now, start a new 25 minutes cycle. Every 4 cycle you get a 15 minutes break. Check out the amazing Pomofocus web app, it will make it dead simple.
This is a very efficient technique to get things done. It is also an amazing way to quantify and plan ahead (after 1 cycle you can roughly estimate you’ll need n more and plan accordingly) but also to do every recurrent tasks that are never really finished. For instance I like to do my tech watch this way, by putting 1 Pomodoro a day to read articles. It forces me to spend 25 minutes straight on it, instead of using it as an excuse to not work on what is important.
But I am digressing… Now, for your team to focus:
Okay, in a nutshell: use Kanban! The most important principle is to finish stuff before starting new ones, specifically to prevent multitasking. I have already written an article touching on that.
Note that most Agile frameworks are based on this principle in a way or another. For instance Scrum forces the Team to narrow down each Sprint to a specific Sprint Goal and a finite number of User Stories. The fact that each Sprint has a goal forces the team focus on one aspect of the product.
No matter if you are Scrum Master, Product Owner, Developer, Project Manager or Tech Lead, you can try this serious game by yourself in 5 minutes and I encourage you to propose it in your next retrospective to demonstrate how bad multitasking it. No matter what your practice of Agile is, if every team member gains 5% of productivity for 10 minutes invested during a retro, your company is lucky to have you!
This game is called “The Multitasking Number Game” and it exists a lot of different variations, all based on the same principle:
Take a piece of paper;
Divide it in 3 columns: one for numbers, one for letters, one for Roman numbers;
Open the stopwatch app on you phone or in your browser and start it;
|Write the numbers from 1 to 10, row by row (ie. “1||One||I”, “2||Two||II”, …);|
At 10, stop the stopwatch and record your time;
You should notice a significant difference between the two rounds. This is a very clear demonstration that context switching is your and your team’s worst enemy.