At one point, I took over as a ScrumMaster for one of seven teams that was responsible for delivering a large project for a multi-national company. Each team had an area of expertise and work was assigned to the backlog of each team according to their ability. The team had been using Scrum for about 18 months and was comprised of professionals with at least ten years of experience each. Even so, the team usually had one or two stories moved to the next iteration because they were not finished on time. In addition, significant time was spent on defect repair. I decided that the best way to proceed was to just let the team go through their normal process for an iteration so that I could see what they did and could coach them after seeing them in action.
During the iteration planning meeting, each story was tasked out and the individual tasks were assigned. By the following day each coder had five tasks in progress. A day and a half before the iteration closed all of the stories were dumped onto the testers. The testers did their best and managed to verify most of the stories. The ones that could not be fully accepted were moved to the next iteration so that they could complete testing.
During the retrospective, we decided to talk about what happened. It seemed that chaos reigned over the entire iteration and nobody was happy. The coders were not happy that all of their stories were not approved. The testers work was unbalanced with little to do in the beginning of the iteration and were swamped at the end. Everyone was working hard and even working through lunch and leaving late each night.
I suggested that we play a variation of a game that I found in the book “Kanban in Action” by Marcus Hammarberg and Joakim Sunden called the “The Numbers Multitasking Game.” This game requires a double sided piece of paper and a timer. The goal is to complete three products inside of a grid. The first product is in the first column and is the alphabet written in blue ink. The second product is in the second column and is the numbers 1 through 26 written in black. The third column contains the corresponding roman numerals written in red. When you are ready, start the timer and complete the products by filling out the rows in order (Blue A, Black 1, Red I, Blue B, Rlack 2, Red ii,…). Stop the timer when you finish all three products. Now restart the timer and do the same thing by column (Blue ABC…, Black 123…, Red I, ii, iii). Note the time when you finish this side. Normally, you will see a factor of two or three when you context switch (side A) vs doing a single task at a time (side B). This is true every time you must start a new task and change your thinking.
Based upon the exercise, the team decided to try taking just one (in some cases two) tasks at a time in order to reduce context switching. Over the next iteration, the team finished the stories early, both coding and testing. In addition, they were able to take their lunches and not work overtime. Over the next few iterations velocity increased and the level of chaos decreased.
Everyone believes that they multitask well. The truth is that there is always a cost when you change from one line of thought to another. It does not matter what your job is (Coder, Tester, ScrumMaster, Product Owner, Manager), there is always a cost to switching tasks. In some cases a person may need to be working on two tasks given the possibility that one task may be blocked or waiting on someone else. But even in those cases, it is best to schedule the morning for one task and the afternoon for the other.