Too much in flight

In a Scrum context, multitasking is bad. Teams who follow Kanban will be familiar with this concept, as that process invites you to explicitly set your lane limits up front - only 3 things in progress, only 2 things awaiting product owner review, only 7 tickets waiting for release, and so on. Most people don't do this for a Scrum board, but it's an important discipline to keep.

But what's the problem with having a lot of things in flight? I often say that you shouldn't do this, but don't always explain why it's such a bad thing. It comes down to two things:

• Task switching cost
• Failing to resolve blockers and impediments

Task switching kills your productivity

Software development is a strange activity, because a single software development task is easily capable of taking up all of your mental capacity - in fact, often more than one person's mental capacity, which is why we talk about structuring our programs to reduce cognitive load or pair programming to share the load between two brains. (Ever had one of those moments where you've forgotten the name of a class or module variable, but your partner remembers it just like that? This is pair programming at work.)

Emptying that mental capacity of one thing and filling it with another takes time. You might not notice it, but next time you're coding something think about how long you spend going, "oh yes, it's this class," or "where did that variable go?" Getting into the fabled zone typically takes around 15 minutes. If you're concentrating on one task and you're lucky enough to clear your day of meetings, you've only got to take that cost twice: once in the morning, and once when you come back from lunch. If you're constantly switching between things, you're taking that hit on every context switch. You spend less time in productive full flow, and more time trying to remember where things are or committing code to the wrong branch.

This gets even worse if you're talking about two different projects rather than just two different tasks, as you need to change the whole context around what you're doing. You can mitigate this by working on one project in the morning, going for lunch, and working on the other in the afternoon though - making use of that inevitable post-lunch delay before you're back up to full speed.

(Before you get tempted to make your team cancel their lunch plans, the productivity boost of taking a break far outweighs the cost of getting back up to speed. I'm telling you not to constantly switch tasks, not to skip your breaks!)

Sometimes you might need to swap from one in-progress task to another where you're waiting for an answer to an e-mail or support request. The important thing is these should be fire-and-forget tasks, where you can send your e-mail, get on to the next thing, and not go back to the original task until you get a reply. But even this can lead you into another anti-pattern.

Multiple tasks make it too easy to ignore blockers

The most common anti-pattern I see that causes too many tasks to be in flight is failing to resolve blockers. A developer picks up a task, and gets to a point where they need some clarification. They e-mail a stakeholder, then while they're waiting for a reply pick up another task. They get so far with that, then encounter a problem with a third-party API. So they file a support request, and go on to something else. This time it's a build not working. Tell the team's recognised build/deploy expert, move on to something else. More clarification from the stakeholder, send another e-mail… and so on.

What inevitably happens here is that other team members (especially testers) end up drumming their fingers with nothing to do for most of the sprint, followed by a mad rush at the end when all of the e-mails get answered and the support ticket responses come in. You find you can't get everything implemented and tested in the time available, and blow out the sprint commitment despite some of the team having had nothing to do for most of the sprint.

At a certain point you have to say, "I've got too many things stalled waiting for a response" and start chasing them down. This is one of the reasons Scrum works well for delivering projects - you might have a whole bunch of easy stories on the backlog tempting you, but if you've got a big thorny blocker in the current sprint you need to deal with that first. This is why you never pull stories into a sprint which isn't complete (or almost entirely so); it's better to focus on resolving what's in the current sprint even if the effort:reward ratio feels rather unrewarding.

Remember to think as a team, too. Going back to the Kanban lane limits, they're for the team, not for individuals. If you're genuinely waiting on resolution to a blocker that can't be sped up, then it's time to ask two questions at the daily stand-up: "is there anything I can help with?" and "can anyone help me with this blocker?" The worst thing to do is to keep going, "oh yeah, and today I'm going to pick this up" without explaining to the rest of the team why you're constantly hopping between tasks without finishing any of them.

How to avoid excessive multitasking

The most important thing: learn to scrum together as a team.

Many teams are used to a flaccid sort of Scrum where each team member says, "I'll pick up this story" at planning, everyone heads off into their own silo to work on their story, then everything is thrown back at the tester in the last couple of days to give them late nights and headaches. This isn't how it's supposed to work, though; in fact, this practice is often pejoratively described as lots of mini waterfalls since it invariably starts to resemble one, with all of the design happening at the same time, followed by all of the development happening at the same time, followed by all of the testing happening at the same time, followed by all of the bug fixing and so on.

In a proper Scrum, the entire team swarms on Story 1, gets it across the line, then works on Story 2, completing that before they start on Story 3. While the developers build the software, the tester is working on test cases; while the tester is testing, the team fix bugs in the story. Throughout, the aim is to make sure everyone can find something to do on the story the team is currently working on - ideally matching their own specialisation, but sometimes a front-end developer might need to work on the database code to get a story across the line. (Pair programming helps a lot with this kind of cross-skilling activity)

It's a challenge at first, because you need to learn how to extract a new sort of value from your sprint planning: how to divide up a story so everyone can work on it at once. This is generally a good thing, since it forces you to think more about how you're going to deliver the story, not just come up with an arbitrary list of development tasks. Initially, this is difficult, because you're used to dividing things up into silos and each developer expresses the story plan in terms they understand. What's more likely is that your first step will be getting to the point where 2 or 3 team members can work on the same story, and it'll take a few sprints before you get to the point where everybody is regularly managing to scrum together on one story.

While you're doing this, you also need to build up the internal discipline that makes you resolve blockers as top priority. This means removing some of the crutches that let you avoid facing your blockers. Don't pull stories into an unfinished sprint. Finish the story you're on (as a team) before moving on the next one unless it is logically impossible for someone to make a contribution to it. Moving to the next story as an individual is essentially saying, "I cannot make any useful contribution to the current story in progress" - it's OK to do this, but you need to mean it. If there's something you could be doing to help the story along or resolve a blocker, then do that instead.

If you're still struggling, then try taking a leaf from the Kanban book. Set yourself a strict limit for items in progress; (team members)+1 is a good one to start with. Whenever you're over the limit, then challenge every task in progress at the daily standup. Ask the team: why is this still in progress? What can we do to resolve it today? If we can't do this ourselves, who do we need to help us?

By doing this, you reduce the number of tasks you have in flight, and in turn reduce both task switching costs and the number of blockers you leave unresolved. This helps you deliver faster, more predictably, and make your sprint commitments.