TOP TOC 
Agile . since Jun 23 . Index . DOCs TOP TOC
It is generally assumed in the XP community that pairs are assigned on a per-iteration basis. I have spoken with members of teams that experimented with per-week or per-two-day assignments. There aren’t many of them. We decided to experiment with pair duration.
From our informal straw poll, it appeared that few teams had tried short pairings. We had a gut feeling that these might be worth trying. So we tried pair durations of 1 hour, 90 minutes, 2 hours, ½ day, 1 day, and 3 days.
These smaller times were shorter than our task length at the time at which we performed the experiment. Therefore we needed some way to decide when to swap. We instituted the dreaded egg timer. When the timer went off, any pair who had not changed since the last time the timer went off had to change.
Additional pair swaps sometimes happened between scheduled times. These additional swaps were encouraged, but not very common. Most pairs would fall into their task and forget to swap until the buzzer went off — even if they completed a subtask or ran into a need for someone else’s talent.
We tried two methods of performing a pair swap. In the first, one member of the initial pair stayed with a task until its completion. In the second, whoever had been with a task longer switched away to a new task with every swap. In the second approach, an individual would swap on to a task and work as a beginner, stay during the next swap acting as a teacher for the next new person, then swap away.
Pairing strategy had the tremendous long-term effect on our productivity. Therefore we gathered extensive data on approaches to pair swapping. Rapid, alternating swaps achieved peak velocity.
Figure 2. Swap rate and velocity
The above chart shows how mean velocity varied with pair swapping technique. The velocities have been normalized to a percentage of the highest mean velocity. The x-axis shows the number of hours between pair swaps. The dotted line shows pair swapping where the expert stayed; the solid line shows alternating pair swaps
At short pair intervals it is better to develop an expert, because that is the only way to transfer knowledge from one pair to the next. For intervals longer than an hour, alternating pair swaps work better. It apparently took our team approximately an hour to transfer sufficient knowledge to develop a new domain expert.
The graph is compressed to show only pair swaps up to 1 day. This makes it easy to see the shape of the curve near the 90-minute optimal point. However, we did note that longer pair times had slightly higher mean velocities. Our data suggested that 4 and 8 hours were bad, but longer times rose to just above 50% of our peak. Both curves appeared to flatten out at times over 1 day, at which point there was no measurable difference between them.
We took these measurements when we were a team of 6. We took a similar set of data points when we had grown to 11. The curve had the same shape, but it had shifted right by ½ hour. The crossover point was at 90 minutes, and the peak at 2 hours. We hypothesize that this was because each person had been away from any given part of the code for longer, so it took a little longer for us to get up to speed.
The curve did not, however, stretch out. It just shifted right. This indicates that neither total team size nor unfamiliarity with a given portion of the code base had any effect on a person’s velocity once he had gotten up to speed.
The final nail in the coffin of long pairings, however, came when our weakest coder went on a three-day vacation. At the time there were only three people on the team. With one person on vacation, we could no longer swap. Because it would only last for a couple of days, we assumed the effects would be minor.
Not thinking much of it, we attempted to maintain the same intensity and velocity that we had the week before the vacation. Since 100% of our code was pair-written and we had only had one pair before, we didn’t think we would notice that much difference. Besides, we still had the pair that performed best together.
We were wrong.
By the end of the first day we were exhausted. On the second day, we made it a couple of hours before we needed to call a rest. Even after the break, we couldn’t maintain the velocity that had been so easy before. We spent half of the third day neither paired nor programming.
By the time our missing teammate came back on Thursday, we were both begging for a pair swap. We then went right back into 90 minute swaps. We had fully recovered by noon on Thursday, and finished the week out at our previous velocity.
Agile . since Jun 23 . Index . DOCs TOP TOC
When people are in Beginner’s Mind they learn faster and achieve more. Similarly, people tend to be more creative when they only partially understand a situation. Because they don’t know all of the limits yet, they don’t have as much difficulty seeing past them.
Pair churn ensured that every pair had a member in Beginner’s Mind at all times.
In addition to gathering the metrics, we also asked people how they’d felt under various approaches. One of the most commonly stated responses was that the swaps were too frequent. It took people about 90 minutes to get fully up to speed on a new problem, and then they’d get swapped away. Most people felt like they were constantly drinking from the fire hose, unable to catch up.
We talked about this in a couple of weekly retrospectives. We discussed Beginner’s Mind. After a couple of weeks, everyone saw how much more they were learning than they had in any other situation in their lives. The fire hose became a thrill ride. It became a challenge.
We found that with pair swaps below 90 minutes, some information was lost with each pair swap, requiring the new pair to frequently ask questions of the person who had just left the task. With longer pairings no information was lost, but after 90 minutes the pair’s velocity dropped notably.
On a related subject, teaching is a great way to learn. This is especially true if the teacher is relatively new to the subject.
Alternating 90 minute swaps caused each pair to contain one person in Beginner’s Mind and another who was teaching the subject he’d just learned. This strategy proved to be a phenomenally effective combination. It strongly outperformed the situations where we developed an expert by leaving a person on the task for a longer duration.
Pair churn also maximizes the effect of pair net. Information flows better. Everyone masters tools faster. Everyone learns how the data are organized in each system faster. Everyone learns new coding techniques faster.
One telling example of rapid pair net happened accidentally to the Silver Platter team. Around 10 am I was driving. While doing a bit of copy and paste, I accidentally hit Ctrl + Shift + V instead of Ctrl + V.
In Visual Studio, Ctrl + Shift + V operates a paste stack. It remembers everything that you have copied in the past. Pasting inserts the top of the stack. Pressing the keys again before doing anything else replaces the just-pasted stuff with the next item in the history. You can continue to pres the key combination to go back further in your history. This makes it easy to copy from a couple of sources at once and paste them all together.
My partner and I noticed this and spent a few minutes figuring out what the weird behavior was. We then went on with our work. Over the rest of the day, we swapped as normal. Once in a while, the paste stack would be useful, so I’d teach it to my partner.
Around 4 that afternoon I was again driving. My navigator saw me doing some copy and paste and took the keyboard to show me a neat trick — the paste stack. I was surprised that he’d seen it, so I stood up and asked the bullpen how many of them knew about the paste stack.
All 11 people had learned about it that day.