Bjørn Stabell 白熊

Arlo’s team wanted to be extreme, and they started with one of the XP practices, pair programming. Going extreme meant that they would pair program all the time. No code produced by a single person was allowed to be checked into the repository.

But, pair programming is also a pretty new and relatively undefined practice. There were still a lot of questions open, among them:

• How long should each pairing session last?

So, they set out varying the time each pair was pairing, and what they found was not what they thought. For a team of 6 people:

• From 0 to 90 minutes, productivity slowly increased
• From 90 minutes to 4 hours, productivity dropped to about half
• 4 hours and beyond, productivity stayed the same

Most previous explanations of pair programming seemed to advocate pairing half days or longer, so switching pairs every 90 minutes is pretty radical. But productivity was double what it was if pairing was for 4 hours or more. Defects and code debt also decreased, but less dramatically so.

Pairs would spend 15 seconds to swap. If they got lack and started prolonging the pairs beyond 90 minutes, the team would buy an annoying-sounding kitchen alarm clock and set it to 90 minutes. After a week of the kitchen timer, everyone was ready to stick to 90 minutes again

Each developer was only on a task for 3 hours. First 90 minutes as the beginner, the next 90 minutes as the expert. A result of that was that a combination of people would be applied at each task, and suddenly it was if no tasks were hard anymore.

For truly hard problems, however, they would churn (swap pairs) even more frequently, e.g., every 30 minutes.

Knowledge exchange happened extremely fast. New techniques learned in the morning spread throughout the whole team by mid-day. Arlo calls this technique telepathy.

The developers themselves would pay attention to pairing about an equal amount of time with each of the other developers. The coach would also watch this, giving feedback if some pairs seemed to occur too frequently.

With an odd-numbered team, one person will be alone. Since they can’t produce production quality code alone, what do they do? There are many options, e.g., pairing with QA, customer, or doing mechanical work like simple refactoring (e.g., renaming) which is just so simple it doesn’t benefit from pairing.

Everything that would take time for development persons would become tasks, including documentation, and all of them would be paired.

To do pair programming effectively it is necessary to standardize on a development environment. But that doesn’t mean the environment can’t be continuously improved on.

Note: For 12 man teams, peak productivity came at 2 hours, while plateau at 4 hours.

• Part 1: The agile experiment
  • Safe is for weenies
  • Metrics
  • “Meta process”
  • What did they learn?
• Part 2: Practice: Promiscuous pairing
• Part 3: Practice: Least-qualified implementor
• Part 4: Practice: Team-owned tasks
• Part 5: Arlo’s agile experiment summary

This entry was posted on Friday, July 13th, 2007 at 04:04 and is filed under Exoweb, Python, FOSS, Django, Programming. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.