Agile Zone is brought to you in partnership with:

Matt is the Group Leader of Research Application Development in the Research Informatics Division of Information Sciences at St. Jude Children's Research Hospital in Memphis, Tennessee. Matt has been developing and supporting enterprise Java applications in support of life sciences research for St. Jude since 2001. Matt is a committer to multiple open source projects and is the founding member of the Memphis/Mid-South Java User Group. Matt is also a regular speaker on the No Fluff Just Stuff symposium series tour (as well as other major conferences), and his articles have appeared in GroovyMag and NFJS the Magazine. His current areas of interest include lean/agile software development, modularity and OSGi, mobile application development (iPhone/iPad/Android), web development (HTML5, etc.), and Groovy/Grails. Matt has posted 44 posts at DZone. You can read more from them at their website. View Full User Profile

Waste #6: Task Switching

09.15.2010
| 19908 views |
  • submit to reddit
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 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.

 

Task Switching Diagram #1
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.

Task Switching Diagram #2

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

Published at DZone with permission of its author, Matt Stine.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Scott Rosenbaum replied on Thu, 2010/09/16 - 12:47pm

Nice article and I like the picture, but don't you think it is a bit idealistic to think that people could truly focus on one task? What about dependencies within the tasks? Or what if Task C has a team of people that are dead-locked waiting for the attention of the developer.

The reality is that we need to be better at managing tasks interrupts and not merely hope that we can avoid them. Technologies such as the Eclipse Mylyn Project along with companies like TaskTop are helping to create software solutions that help developers better manage the interrupt driven nature of our work.

Matt Stine replied on Thu, 2010/09/16 - 4:22pm

@Scott

Idealistic? Absolutely. The example is intentionally oversimplified to demonstrate the fact that even in an ideal scenario with no task dependencies, deadlocks, etc., task switching has a real cost. 

Software tools can help, but cannot eliminate the cost, as it is a cognitive issue. Even if I'm immediately presented with all of the relevant information/artifacts necessary to complete my task following a task switch (something that Mylyn does extremely well), I still have to "switch my brain on" to that task. It still takes me real time to get into flow. And every time that I have to restart that process, it's costing my company/customer real money.

So while we can only eliminate this problem in a dream world, we can take actions to minimize it as much as possible. This article is an attempt to point folks in the right direction.

Cheers!

Kaitlin Duck Sh... replied on Tue, 2011/08/16 - 11:10am

Context switching is a real problem.  I suggest looking at the Mylyn open-source project.  Mylyn allows you to store your context: which files/windows are open, what files you have looked at recently, etc. on a task-by-task basis.  Thus, when you switch from e.g. bug 10037 back to bug 9987, you will see exactly what you had seen when you left bug 9987.

 Tasktop Dev is a commercial version, allowing you to communicate with task repositories (AKA "bug databases", "issue trackers", "work item repositories", etc.) from many different vendors and providing support.

 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.