Waste #6: Task Switching

Welcome to episode six of our series "The Seven Wastes of Software Development." In episode one, we introduced the concept of eliminating waste from our software development efforts. Waste elimination can be traced all the way back to the the mid-1900's, the birth of lean manufacturing, and the Toyota Production System (TPS). This is how Taiichi Ohno, the father of the TPS, described its essence:

All we are doing is looking at the time line, from the moment the customer gives us an order to the point when we collect the cash. And we are reducing the time line by reducing the non-value adding wastes. [1]

In this episode, I'd like to focus on "Task Switching." Of all of the wastes confronting us as software developers, this one is perhaps the deadliest. Deep concentrated thinking is required for even minimum effectiveness as a software developer. Interruptions are the ultimate enemy of deep concentrated thinking, and any task switch constitutes an interruption.

Read the other parts in this series:

• The Seven Wastes of Software Development - Introduction
• Waste #1 - Partially Done Work
• Waste #2 - Extra Features
• Waste #3 - Relearning
• Waste #4 - Handoffs
• Waste #5 - Delays
• Waste #6 - Task Switching
• Waste #7 - Defects

The cost of task switching in software development has been a recognized problem for many years. Tom DeMarco and Timothy Lister highlighted it in 1987 in their influential book Peopleware: Productive Projects and Teams.

DeMarco and Lister were two of the first to describe flow - the holy grail of coding. Flow is that state of uberproductivity in which time disappears. The computer becomes an extension of your mind as the code flows down through your nerves and out through your merrily dancing fingertips. Flow is when value is manufactured.

Unfortunately, getting into flow is extremely difficult. It takes us at least fifteen minutes to get there; it is the time we spend loading the problem at hand into our minds. And during that fifteen minutes, we don't get anything done! Once we're there, any interruption forces us to begin anew, costing another fifteen minutes of unproductive time. Four interruptions costs an hour of productivity. Thirty-two interruptions costs a day.

The true cost of task switching is best illustrated rather than described. In the first diagram below I've depicted three tasks, each of which is estimated at one week to complete.

 

Let's imagine that each of these tasks will deliver value to a different customer: task one to customer A, task two to customer B, and task three to customer C. In this serial completion scenario, whereby the developer focus on one and only one task until it is finished, customer A realizes value after one week. Customer B realizes value after two weeks, and customer C realizes value after three weeks.

Now let's examine the all too common task switching scenario. Our developer's manager wants to see positive progress made on all three tasks immediately. We'll assume only the best intentions on the part of our manager. It's quite likely that he simply wants to assure his customers that their items are in progress and will be completed as soon as possible (or so he believes).

So, our developer takes each task and divides it into eight equal parts. He then completes part one of all three tasks, followed by part two of all three tasks, followed by part three, etc. I've added this workflow to our earlier diagram below.

While the picture is indeed worth a thousand words, I can't help but highlight the value delivery story:

• Week One - NO VALUE DELIVERED
• Week Two - NO VALUE DELIVERED
• Week Three - NO VALUE DELIVERED
• Week Four - FINALLY, VALUE DELIVERED

It takes our developer until the middle of the fourth week to deliver any value to any customer. In our earlier scenario, the longest anyone had to wait was three weeks, and our first customer realized value after one! The task switching scenario is in all ways worse than the serial scenario!

So, how do we beat this [2]?

1. If you must work on multiple projects, work on one at a time. Minimize the amount of context switches that you must do in a given time period to maximize productive flow.
2. Your team may be required to handle interruptions, especially if you're responsible for supporting the software that you build. In these situations, consider rotating the responsibility for handling all interruptions for a week at a time. Make sure, however, that each person has all of the knowledge necessary to handle the interruptions. Otherwise this solution will quickly break down.
3. Eliminate unimportant work and interruptions! If it isn't delivering value, stop doing it!
4. Ensure that all of the knowledge necessary to complete assigned work is in the right hands. This will prevent the need to switch tasks by preventing the roadblocks caused by missing information.

That's all for this episode of "The Seven Wastes of Software Development." Stay tuned for the final installment: Defects.

References

[1] Poppendieck, Mary and Tom. Implementing Lean Software Development: From Concept to Cash. Addison-Wesley, 2006.

[2] Shore, Jim. "Task Switching." http://jamesshore.com/Articles/Business/Software%20Profitability%20Newsletter/Task%20Switching.html