The numbers behind context switching

About 6 months ago a colleague and I started to investigate figures on how people are spread over multiple projects and product initiatives and what this means for the organization.

Doing some research — google is your friend — we very quickly came across the heuristic of Gerald Weinberg and wanted to use that in our presentation to the leadership team. My colleague Roel Trienekens who reviewed my presentation, pointed out that the heuristic wasn’t correct and pointed me to a research paper of the University of California in 2017.

Reading that paper resulted in the article you’re reading now.

The research and numbers

When we switch our attention between tasks, our brain needs to re-focus to the new task. This is called reimmersion time, resumption time or resumption lag as shown in Figure 1 (1).

In 2017 research was done at the University of California to look at the impact of context switching in software development.

Here are the main findings:

1. Cross-project interruptions are characterized by relatively long reimmersion times, longer resumption times, and significantly different work contexts of interrupting tasks.

2. Developers who work on 2 or 3 projects spend on average 17% of their effort on context switching between tasks from different projects. Visually, this looks like this.

3. Developers who were involved in more projects tend to have more cross-project work interruptions. However, the linear correlation between the number of projects each developer worked on … and the amount of effort developers spend on context switching is weak.

4. Visual observation of the data points suggests that projects where multitasking overhead took less than 40% of the overall effort had a better quality of work compared to other projects.

This insight becomes interesting when we calculate what it means for the cost of our projects.

· Time to deliver increases by 17% on average

· Cost per developer increases by 17% on average

For a project of 100 man-days with 5 developers at a conservative daily rate of 600€ this would mean an additional cost of 51.000€.

Now, expand this thinking to an organization with 50 developers for a full year. That’s right… over 1.000.000 (one million) €.

Not calculated in the above are short- and long-term cost of potential quality loss, the cost of delay, the cost of coordination and planning overhead, the effect of drop in morale and rising stress levels, and the delay on benefits expected from the project.

Break the pattern

The research and numbers clearly show us that working on multiple tasks at once heavily influences the time we need to finish our work and more importantly creates a significant additional cost for our organization.

Luckily there are three solutions for this. They are simple, but not easy.

1. Bring work to dedicated teams as much as possible.

2. Focus by limiting work in progress (2) and only pull in new work when something is finished.

3. Deliberately and structurally integrate slack time in your planning and estimates so people have time to react, digest, reflect and take a breathing break.

I understand that my proposed solutions sound and feel counter-intuitive, but I promise that this approach will help you to increase your flow, deliver your work faster and save you a lot of money. I will go deeper into them in future posts.

(1) From Impact of task switching and work interruptions on software development processes — Alexey Tregubov et al.

(2) John Cutler has a very interesting thinking exercise on the effects of high work in progress on an organization.