BT

Need an Answer to Context Switching? Get Disturbed

by Vikas Hazrati on Sep 15, 2009 |

Context Switching, is defined as changing focus and attention from one task to the other in relatively short periods of time. It is widely considered harmful for the team member and the project that he is working on. It is often considered analogous to multi-tasking and a recent post on InfoQ quotes a study from Stanford to showcase the associated negative effects. David Starr considers context switching analogous to Muda. He suggested,

Context switching is the very essence of Muda, a Japanese term for activity that is wasteful and doesn’t add value or is unproductive. Learning to positively manage context switching help to reduce your Muda of motion and will turn you into a more effective person. Period.

There are multiple ways to tackle the menace of context switching and the rule number one suggests, "Do not context switch". However, Charles Miller suggested that doing away entirely with context switching is wishful thinking. There are multiple distractions in a project and there needs to be a way to deal with them. He mentioned the following techniques used by Atlassian

  1. Asynchronous Communication - Atlassian runs a Jabber server for staff, and during the day all developers are logged on to instant messaging. The advantage is that, since it is asynchronous in nature, it can easily be ignored, and responded back to at the appropriate time. Blog and internal wiki are other good tools, which are used, to get the view point of others without disturbing them in real time.
  2. The Disturbed – Another interesting concept employed is designating a single developer to the status of “The Disturbed” . This developer would be disturbed for an entire sprint. He is responsible for managing and responding to all the distractions and context switching scenarios which would otherwise have disturbed the whole team.
Designate a single developer to be "The Disturbed"; taking a two week stint to act as a magnet for all the questions, requests and distractions that would otherwise be distributed across the whole team.

Charles does caution that one should not expect a lot of work to be done by 'The Disturbed" during the sprint. This is expected given the pitfalls of context switching. He mentioned that,

The downside of this approach, of course, is that for two weeks the Disturbed gets very little work done on whatever feature track they are nominally committed to. On the other hand, because the Disturbed isn't expecting (or expected) to get much of that work done while being disturbed, it is far less frustrating for the developer and far more predictable in terms of scheduling and estimation for the team as a whole.

Thus, next time when an Agile team has to deal with multiple context switches or distractions, it might be a good idea to consider assigning a dedicated team member who should be disturbed for the duration of the sprint.

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Pair Programming helps by Joakim Sundén

I have found that the cost for context switching is lower when pair programming. It is often only one in the pair that's disturbed and that makes it easier for her to get back in flow after the disturbance.

Re: Pair Programming helps by Vikas Hazrati

Joakim thanks for sharing that, that seems to be interesting. Another advantage of pairing :)

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

2 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2013 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT