Raise your hand if you’re a habitual multitasker. Do you get distracted by each incoming email? Do you switch between projects and tasks? Us too.
We recently did an activity that brought to light just how much multi-tasking could be affecting our work. We stole it from Henrik Kniberg at Crisp. The goal of the activity was to simply write names on a notecard. Sounds easy, right?
There were two rounds to the activity, each with different rules. In both rounds, we had five “clients” and one “developer.” The clients were each assigned a name (different from their real name) and their job was to provide instruction to the developer so she could write the name written on the card with no bugs.
Round 1: Start Early, Finish Early
The sooner you start a task, the sooner it’ll get done…right? Nope, not when there are multiple tasks to complete (and who doesn’t have multiple tasks to complete?).
In this round, the developer had to start each client’s work as soon as she could—and couldn’t let the work sit without working on it often. This meant she had to write each name one letter at a time. One. Letter. At. A. Time.
Round 1: Five names. One letter at a time.
By working on multiple client names at one time, the developer spent nearly two minutes writing five names. Even though each name started early—within 10 seconds of the start of the activity—and was worked on consistently throughout the round, work wasn’t completed on all names until about two minutes had passed.
Start early, end early?
The chart above shows our results from round 1. Hermann had to wait more than two full minutes from start to finish to get his name written on a notecard. Two minutes! Try taking two minutes to write a name on a notecard. It’s tedious. Even worse, watch someone take two minutes to do so.
Round 2: Start to Finish
In round 2, the developer worked on one name at a time, taking each from start to finish before moving on to the next client.
In this round, work moved quicker, clients spent less time waiting and going back-and-forth with the developer, and the developer got to focus on one client at a time.
Round 2: One name at a time.
The results from round 2 look quite a bit different than from round 1. Each client got his or her work completed within just a few seconds of starting, instead of after two minutes. The developer worked in priority order (the order the clients were sitting around the table) and was able to fully focus on each client. All of the work—the same amount of work completed in round 1—was completed in less than a minute. Sure, Erich had to wait 50 seconds for the developer to start his work, but look how quickly he got the completed work back.
Little’s Law
This activity proves software development is a system that falls under Little’s Law, as most systems do. There’s a fancy equation for the law, but in layman’s terms, the more work in process a system has, the longer each piece takes. By working on five clients’ names at a time, each one took much longer. By only having one in process at a time, not only were the individual tasks completed faster, the entire set was completed in less than half the time.
Lessons Learned
Let’s look at the results of the two rounds next to each other:
Wow. As a developer, which way would you rather work? And as a client, which way would you prefer your developers work?
This activity was eye-opening for a lot of our team members. As a result, we’re currently working on applying the lessons we learned about multitasking by:
- Checking and responding to email and IMs only after focused periods of work (research says 52 minutes is the sweet spot for focus time)
- Setting response time expectations for emails, IMs, and messages from our project management tools
- Structuring work within sprints to allow for project focus time
- Limiting the amount of work in process at any given time
- Being cognizant to only include team members who really need to be copied on messages
- Taking those pesky “reply all” conversations offline after three back-and-forth messages (a conversation will move things along faster than a bunch of emails)
To test myself, I wrote this blog using my new-found knowledge about multitasking. Truth be told: It was hard. It’s a big shift in thinking from my usual bounce-around style. But without email, IM, and (shh) Facebook, I noticed a big difference in my ability to go start-to-finish on the post…with a much-needed coffee break in there.
Did this blog post inspire you to try new ways of structuring your work? Tell us on Facebook or Twitter.