Why multitasking may not be the right approach for your development team

Sometimes your team simply has too many projects on their plate. Deadlines and commitments loom, and you’re faced either with painful renegotiation, or with multitasking your team across multiple projects. It’s tempting to place your hope in multitasking — perhaps it will be possible to deliver all of those commitments on time, or at least close to it. And at least each set of stakeholders will be seeing progress and getting regular updates. Some of the pressure comes off, at least in the short run.

Unfortunately, we all know that the problem with multitasking in a development team is that it decreases efficiency. At West Arete, our team has been faced with the exact same situation in the past. When we measured the difference in our team’s velocity between working dedicated on one project at a time, versus multitasking a team with juggling two or more projects at once, we were shocked to see how large the negative impact was from the multitasking approach.

The dilemma of scheduling projects sequentially

In our internal review, projects that were subjected to multitasking took approximately 40 percent more time and effort than those where the team was allowed to focus on one project at a time.

We weren’t multitasking often, and we were aware of the potential cost of doing so, but the magnitude of the impact still surprised us. We quickly shuffled our schedule in order to run our remaining projects sequentially rather than in parallel.

Unfortunately, we know that the real world doesn’t always allow this. If you have two key stakeholders who each need their critical application to be live before the start of the next semester, neither one may be amenable to waiting until the other’s project is complete before theirs begins.

And sometimes, stakeholders don’t want accept the data on multitasking inefficiency. If they see that project A is estimated to take eight weeks of effort, and project B is estimated to take seven weeks of effort, they may initially reject the idea that running both projects concurrently could result in a total of 21 weeks of effort. But unfortunately that’s exactly what the data tells us.

What constitutes multitasking?

Is there any hope of making some progress on the other project? Certainly the worst outcome is where teams are working on two different projects in the same day. However, we were not even successful in seeing any improvement when putting two projects in the same week; even if you’re dedicating, say, Monday through Wednesday for project A, and Thursday and Friday for project B, you’re still going to see a big multitasking tax. We didn’t start to see the big efficiency improvement until teams were able to spend multiple weeks on end dedicated to a single project. Only in that kind of pure scenario did we see “flow”.

So what are your options?

• Advocate strongly for limiting your team to one project at a time. Your team’s focus, productivity, and job satisfaction will rise dramatically, and it’s truly the fastest way to get the total stack of projects done.
• Work hard to define and defend a minimum viable product for each project. Get each project into production with a useful subset of functionality as early as possible, so that if a project runs over you can circle back at a later date to add the desired functionality, rather than being forced to push all subsequent projects out to a later date in order to get the current project live.
• Consider temporarily increasing your capacity by working with an external team like West Arete to offload one of your projects. Often there’s an outlier project that is truly valuable, but it isn’t a perfect match for your team’s domain knowledge, or it doesn’t quite suit your team’s best and highest use. Coupled with the opportunity for mentoring or introducing a new level of new tools and techniques, having one less project on your plate can be a boon on a couple different levels.
• Occasionally you decide to accept the 40 percent tax and multitask anyway. For example, sometimes there’s a rare opportunity to have both sets of stakeholders present on site, and unfortunately both are visiting at the same time. You’d rather take advantage of that opportunity than optimize for development efficiency.

Obviously there’s no one right strategy for every situation. In theory, we’d always optimize for developer efficiency. In practice, staffing, dependencies, stakeholder availability, and infrastructure hold-ups can force us into a plan “B” or “C”.