↓Skip to main content

Work from right to left 👈

#planning #collaboration

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.

Consider also what happens if unplanned work interrupts you half-way through the graph above. When performing tasks one at a time, task A has already been delivered and only Task B is interrupted. In the multi-tasking scenario, none of the original work has been completed.

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

  • Focus on tickets, not people. Don’t turn your stand-ups to a micromanagement interrogation, asking every developer what they did yesterday. Instead, focus on each ticket on the board and how it can be moved towards the right.
  • 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 of a board with an arrow showing how to move from right to 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.

Updates #

  • 2025-09-09: Original post published.
  • 2025-09-15: Added paragraph on what happens when unplanned work interrupts.
  • 2025-09-22: Added bullet saying focus on tickets, not people.