Agile Resolution 1: Destroy Multi-Tasking the Productivity Killer

Several months ago, the company I’m assigned to as an Agile coach decided to “try Scrum” with one of their division’s teams but with several caveats: The team would be limited to applying a maximum of 10% of their time to the Scrum experiment, and they could only use Scrum with one of the many projects assigned to them by their manager. In addition, this Scrum project was set as “lower priority” by the manager. The rest of their projects would continue to be managed in the usual, non-Agile way that the manager preferred.

I started coaching the team after they had already been struggling with this new Scrum process for a number of weeks. The team had about 12 members, split between USA and India locations. Most team members worked remotely from their homes and only interacted virtually by email, conference call, or screen-sharing collaboration tools. After working with them, i immediately recognized that multi-tasking was a key impediment for the team.

The team was having daily standup conference calls (one for India team members, and one for USA team members about 12 hours later), each lasting about 15 minutes. They also had a couple of one or two-hour user story refinement sessions, but they eventually discontinued these sessions to save time and because no user stories were being completed/accepted.

I spoke with the team manager as well as the ScrumMaster about the team’s struggle with multi-tasking. I used a whiteboard to illustrate how long it would take to get this project done (i.e., delivered to customers) if the team’s focus continued to be highly fragmented, compared to if they had the ability to remain focused and complete work from “end to end” with little or no external dependencies.

How Valuable is Focusing on Completing One Task?

I started with a hypothetical duration of 4 weeks that this project might take if the entire team were fully (100%) dedicated to working on it. I compared this to if the team were limited to spending a maximum effort of 10%. I reduced effort by half (i.e., to 5%) due to the costs of context switching (more on that below). Despite being directed to spend 10% of their time on the Scrum project, most team members were reporting to the ScrumMaster that they could only find two to three hours a week at most to spend on this project, due to competing higher-priority projects. This is even less than the already low four hours (i.e., 10% of 40 hours) they ideally had available to dedicate to the Scrum project.

I drew a timeline where increments on the x-axis represented four weeks — about one month — and used this to project how long the two scenarios would take. Instead of the project taking one month at 100% effort, it would take nearly a year (45 weeks!) to finish at just 10% effort. In fact, in the latter case, it would probably take at least a year when accounting for holidays, sick days, vacation days, etc.

Above the timeline, I drew three scenarios:

  1. I asked when the project would finish if it were the highest priority, assuming 100% effort. As stated above, the answer is roughly one month (four weeks).
  2. I asked when the project would finish if it were one of a handful of competing priorities and given only 10% effort. The answer is 10+ months (45+ weeks).
  3. I asked when the project would finish if it were the lowest priority of a handful of projects but still given 100% effort when the time came. In this scenario, the Scrum project wouldn’t start until the higher-priority projects were finished first. The amount of time to complete the project remains the same (i.e., four weeks). Meanwhile, each higher priority project would start and finish earlier throughout the year, and would start adding value (generating revenue, etc.) sooner.

Here is a prettier version of the whiteboard sketch I made:

Multitasking is Evil_CCarrington

How multitasking prolongs delivery and kills productivity

The Cost of Context-Switching

Let’s take a tangent now to talk about the costs of context-switching (multi-tasking), which is the bane of productivity existence, at least in an Agile setting. In the 10% effort scenario above, these might include:

  1. Team members leave or join the team, and new members require training, knowledge transfers, or handoffs to other team members.
  2. Roadmap planning introduces new, even higher-priority projects, and this 10% effort project is put on hold indefinitely, or even canceled. In the last case, any partially completed work by the team would be completely wasted.
  3. Work that the team did on the project months earlier is forgotten so the team has to slow down to review and refresh memory. Or work done earlier becomes irrelevant because technology has been updated or changed in some way in the interim, such that rework is required.
  4. The team takes more time/effort to put other projects they were working on out of mind and remember what they were doing with this 10%-effort project when they last worked on it … and repeating that cycle of forgetting/remembering every single time they switch from one project to another, as often as every single day, many times a day!

The Upshot

Following the conversation mentioned above where I drew out the above timeline with these three scenarios, the ScrumMaster was persuaded enough to encourage the team to limit their work in progress (WIP), as well as limiting his own personal WIP. After a few weeks, he was already reporting productivity gains for himself, as a result of focusing on each highest-priority task until it’s completed and trying to avoid working on many tasks simultaneously.

The team manager, however, was not persuaded. She continued to use her authority to limit the team’s ability to focus on this project and reduce their WIP, because she had been rewarded (through promotions and accolades) by repeating this pattern of juggling many projects in progress simultaneously, and occasionally delivering one of them. The organization had effectively set up a paradigm that discouraged efficiency by encouraging multi-tasking.

The Same Project, Four Months In

  • Not a single user story had been accepted.
  • All but one team member on the USA team had stopped attending daily standups.
  • The solitary USA team member managed to complete a few preliminary user stories, but the Product Owner wasn’t yet available to review the stories or accept any of them.
  • The India team had moved on entirely to other projects and their daily standups had been canceled.
  • The team manager was still confident that eventually the project would be completed someday.

Multi-Tasking is the Antithesis of Agile, and It’s Destroying Your Productivity

So why is reducing multi-tasking important for Agile/Scrum to be effective? If the story above hasn’t convinced you, perhaps a list will:

  • The perils of multi-tasking is why Agile/Scrum encourages teams to focus on one thing at a time, limiting work in process (WIP).
  • It’s why Scrum divides work into sprints: so teams can focus on just what they can complete in 1-4 weeks (i.e., however long their sprints are), while ignoring everything else in the backlog.
  • It’s why we ask in daily standups what is impeding/blocking the team or individuals – so we can focus on clearing those impediments as soon as possible to resume work on the highest priority story.
  • It’s why we have retrospectives that focus on ways to improve as a team, and why we encourage teams to pick one or two things at a time to change (so they can focus on that change as a theme for the next sprint).

Steps to Take Today to Limit Your WIP

Here are a few practical steps you can take today to reduce your team’s multi-tasking and your own:

  1. Identify the business value of each work item in your queue. There are many different approaches to achieve this, depending on your organization, industry, type of product, type of customer, etc. However your organization defines business value, let this information help you set your priorities and that of the team.
  2. Prioritize all of the work in your queue. Involve customers or a representative of the customer (such as your Product Owner) in the prioritization. Review your backlog priorities regularly, and adjust as appropriate.
  3. Now that you’ve prioritized your backlog, only pull in tasks of the highest priority. The prioritization scheme generally maximizes customer value, and delivering customer value is the ultimate goal of every company. When a low-priority task becomes an impediment to value delivery, it increases in priority and can therefore be pulled into the sprint for completion.
  4. Limit your WIP. Start with a smaller number that’s uncomfortable but not impossible. Try it out and make adjustments to your WIP as necessary. Limiting your WIP helps lower the cost of “de-prioritizing” something that once was a high priority, if you haven’t started working on it yet.


The Cost of Context Switching by Petri Kainulainen

The High Cost of Multitasking, an infographic by the Huffington Post

The True Cost of Multi-tasking, by Dr. Susan Weinschenk (Psychology Today)

The High Cost of Multitasking by Farnoosh Tarabi (Yahoo! Finance)

Human Task Switches Considered Harmful by Joe Spolsky

The Multitasking Name Game, by Henrik Kniberg (Crisp)

How Being Busy Makes You Unproductive by Dr. Travis Bradberry (LinkedIn Pulse)