Work from right to left 👈

Does your team work on many things but finish few? Multitasking feels productive, but it usually makes everything slower.

More than two decades ago, Joel Spolsky wrote a great article on why human task-switching is a bad idea. It is well worth a read, but the main take-away is:

You should never let people work on more than one thing at once.

He also points out that doing one task at a time gives you results faster on average than when multi-tasking. Also, the longer it takes to task switch, the bigger penalty you pay for multitasking.

A comparison between performing tasks one at a time and multi-tasking, showing that the first task is done much quicker when doing them one at a time. — Comparison: one at a time vs. multitasking.

So how can you achieve this in your daily work? I have some guidelines for how to think about a Scrum or Kanban board that can help.

The goal is to get things done, not to make sure that everyone has something to work on. Maximum resource usage does not equal maximum output. Some slack is essential for optimal performance. For example, a highway is most effective when it is 70-90% full.
All tickets are in the same swim lane. No priority or component swim lanes on the board.
A ticket further right always takes priority over one to the left. You only work on a ticket “to the left” if you cannot help move a ticket “to the right” further right. This is sometimes referred to as “pull, don’t push”. During standup, address tickets from the right to the left.

An example board, showing how focus and priority should go from right to left.

Challenge yourself to move tickets rightward. It is not enough to say “oh, John is already working on that so I guess I’ll work on another ticket”. There are several ways you can help, such as providing early feedback, pair program, or perhaps perform a subtask. If a task is assigned to someone who called in sick, you can pick it up and move it forward. Be wary of scope creep, and consider using depth-first development to stay focused.

Some teams prefer to explicitly limit the work in progress (with a “WIP limit”), saying that no more than n tickets may be in progress at the same time. Feel free to use that if it helps you.

Exceptions can be made for blockers that are truly time-critical (e.g. production is on fire). However, each blocker ticket should be considered an organizational failure and followed up with a post-mortem. The root cause that allowed the blocker to disrupt the flow should be identified and a new ticket to fix it should be created.

So if you want to get more done, focus on finishing rather than starting. Work from right to left and you’ll finish faster.