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.
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.
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?
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”.
The first step is often a zero-pressure phone call to answer questions and explore whether we both feel that there could be a fit.