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
- 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.
- 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.
