The ability to adapt to change and market evolution is an important added value of Agile management of IT projects. To ensure that we respond effectively to our customers and their complex issues, it is essential to combat the pet peeve of any IT developer or project manager: context switching. Find out what it is and how to fight it.
Context switching is the mechanism used by a computer to handle multiple tasks simultaneously (what is more generally known as multitasking). The term also applies when we simple humans try to do the same thing. Unfortunately, the human brain is far from being as efficient as a computer.
According to Miller's Law¹, we can only hold 5 to 9 simultaneous objects in our short-term memory. Faced with such a limitation, we are constantly forced to make a choice among the subjects that most deserve our attention. When a developer is focused on one task and suddenly forced to switch to another (for example to deal with an emergency or answer a question), he is forced to overwrite the previously memorized information to change context and load the one needed to handle the new task.
A loss of productivity
The consequences of such interruptions are not well known. Once the unplanned task is completed, it takes time to return to the original activity. And the more complex the context is, the more difficult it is to rebuild, and this is often a source of errors and omissions². Developers are particularly prone to this trend because of the large amount of information they have to memorize in their daily work of understanding, analyzing and creating. A simple three-minute interruption can take up to 25 minutes to go back to the initial level of concentration³.
In addition to one-time interruptions, this loss of productivity is also felt at a higher level when one person works on multiple projects per week, sometimes even per day. In his book "Quality Software Management", Gerald Weinberg shares his famous estimate of the cost of context switching.
Focusing on a single project allows us to devote 100% of our time to it, but as soon as we start juggling projects, the loss of efficiency explodes. According to this estimate, we would lose 20% of our time by working on 2 projects at the same time, 40% on 3 projects and up to 75% loss on 5 projects. Constantly recalibrating one's mind between different tasks or projects is very costly in time and energy. Some authors even talk about the trap or the myth of multitasking.
Fighting context switching
That said, context switching is not inevitable, and raising awareness is the first step if we want to get it under control.
In Contraste’s projects, we are careful to implement tools that limit context switching and promote better productivity:
With the Scrum framework, used by the Contraste teams, the Sprint Goal allows to focus the team around a single objective and to keep developers in a relatively similar context. In addition, an exhaustive Definition of Done, gathering the different validation and quality testing steps, allows to limit the return of any rejected features that would undermine the focus on the current sprint.
For Kanban users, the implementation of a Work in Progress Limit restricts the number of concurrent tasks. The team works on a limited number of features at any given time, to avoid spreading themselves too thinly and losing focus.
As far as possible, we recommend that our employees regularly plan a few moments of total disconnect. This is an excellent way to increase their productivity on a project, without any distractions related to emails or calls. The impact of a simple notification on concentration should not be underestimated.
Although multitasking may seem attractive and even encouraged in an increasingly interconnected world, many studies agree that it has a cost, and a high one. Don't fall into the trap!
Blog post written by Maxime
Consultant & Agile Coach
1 "The Magical Number Seven, Plus or Minus Two: Some Limits on our Capacity for Processing Information": http://www.yorku.ca/pclassic/Miller/
2. "Multitasking: Switching costs": https://www.apa.org/research/action/multitask
3. "No Task Left Behind? Examining the Nature of Fragmented Work": https://www.ics.uci.edu/~gmark/CHI2005.pdf