TOP TOC 
Agile . since Jun 23 . Index . DOCs TOP TOC
The more flexible the work assignments, the more a team can take advantage of its natural talents. Many tasks are best solved by the combinations of 4, 5, or even more talents. It is very rare to find a set of people from whom you can pull any pair necessary for any problem. However, it is quite possible to pull five people who combine to give the five necessary talents.
Team based responsibility allows you to do exactly that. Because no one individual is tasked with finishing the problem, each person can be switched in to a given task only and exactly when required. This means that each person spends more time applying their specialty to your tasks at hand and more work gets done.
Furthermore, people who natively think in the most appropriate way to solve a problem tend to develop better solutions. This results in a measurable difference in bug rate. Finally, programming is more fun when each person spends more time applying his talent.
Pull-based task assignment was advantageous for the same reason. Although we all had a very good idea what the talents of our team members were, each person still knew himself best. By using pull-based assignment, each person could argue where his talents applied to the problem. We could also take into account day-to-day effects, such as sleep deprivation or romantic problems.
Our team also believed strongly in the concept of the working manager — our nominal manager spent about 60% of his time writing code. Management tasks were just more things that the team had to do. Because of this approach, we ended up without a domain expert in management, but with several naturals at the various parts of the job.
We had three people who were the team’s ultimate spokesmen. Our planning and experimentation were done by anyone on the team, but there was a natural who stepped up to help when it was needed. Similarly, we had naturals in the behavioral competencies of Energizing, Leadership, and Team Building. All of these were different people.
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.