Pair Work (Pair Programming)

From Business Agility Library
Jump to: navigation, search

The concept of pair work draws directly from the pair programming technique, as defined by the Extreme Programming agile development framework. In this technique, each team member works as part of a pair, at a single workstation. Each person in the pair is either the ‘driver’ or ‘observer’, and has specific responsibilities. The driver is responsible for doing the work, be that writing, developing, building, etc. The observer is responsible for advising, and reviewing, the work. Each person in the pair switches roles frequently, usually about every 30 minutes, and they form new pairs each day. The figure below shows how each person in the pair changes throughout the process.

Error creating thumbnail: Unable to save thumbnail to destination

By separating the two responsibilities, the driver can focus on developing the current task as quickly as possible, whereas the observer considers the bigger picture, and can suggest ideas for improvement, and identify likely, future problems. The act of observing improves discipline in the team, both by reducing wasted time (e.g. surfing the web or checking e-mail) and improving attention to detail (e.g. writing supporting documentation, or recording outcomes). However, the major advantage of pair work is the overall reduction of defects created that need to be resolved later.

In general, pair work provides a major increase in quality, at the cost of a minor decrease in speed.

Whilst there are no formal studies in pair work outside the software engineering disciplines, several studies of pair programming have found that the quality of work significantly improves, compared to programmers working alone[1][2][3][4]. As well as improved design and maintainability, these studies show a reduction in defect rates between 15 and 50%, with a higher reduction in defect rates for high complexity tasks, and using experienced pairs. While pairing, individual tasks are generally completed sooner, however, overall development speed (including defect resolution), compared to programmers working alone, reduces by between 15-25%.

Pair Work Example:

In this example, based on real-world teams, two teams (of two people each) are working on the same tasks; team 1 is using pair work and team 2 is not.

Team 1 – pair work: Because team 1 is using pair work they will work on task A together and then task B.
Task A Initial work

Testing

Rework

Defect Rate

6 hours

½ hour

½ hour

2%

Task B Initial work

Testing

Rework

Defect Rate

4 hours

½ hour

0 hour

4%

Overall Total

(Initial + Test + Rework)

(6+4) + (½+½) + (½+0)

= 11.5 hours

  Average defect 3%
Team 2 - Individual work: Because team 2 is not using pair work they are working on task A and task B simultaneously.
Task A & B Initial work

Testing

Rework

Defect Rate

7 hours

1 hour

1 hour

15%

6 hours

½ hour

1 hour

10%

Overall Total

Max (Initial + test + Rework)

(7) + (1) + (1)

= 9 hours

  Average defect 12.5%
You will notice that team 1 took less time to deliver each task and had fewer defects. However, since they delivered task A then task B, they were slower overall than team 2, who could deliver task A and B at the same time (though they were still less accurate).

The value of pair work to your organisation will change between requirements and teams. As an agile manager, you need to compare the potential increase in quality and reduced dedicated testing time, against the increased overall time to deliver. This is not a rhetorical question, but a true judgement of value that you need to make, and verify, regularly.

When to choose pair work

  Pair work vs. Individual work
Need Quality driven   Speed driven
Type Complex tasks   Simplistic tasks
Risk High risk   Low risk
Team Equal distribution of novices and experts   Low expert to novice ratio
Skills Consolidated in one or two people   Cross-skilled team Members

One of the key, qualitative advantages of pair work, is the implicit skills and knowledge transfer between partners. This includes both specific skills relating directly to the task, and general knowledge transfer relating to work techniques and expertise. This is particularly valuable in the case of helping new employees to learn the standards and practices of the team, and the specific requirements of the current customer. By switching partners each day, specific knowledge and skills quickly spread throughout the team, promoting a cross-functional and cross-skilled team.

Ultimately, pair work is a cooperative, social skill that requires good communication and trust between partners. This can be uncomfortable for team Members unfamiliar with this process, and can take some time to learn. Regardless of organisational status or experience, both partners need to contribute equally, and listen to the other’s ideas. Even as a mentoring mechanism, a new team Member is still an equal partner in the pair.

As a final note, there is some controversy over the value of pair programming, and thus pair work. I leave it to you to decide if this approach will bring value to your organisation. At a minimum, however, I recommend that you apply pair work concepts to high-risk tasks, and the training of new team Members.
  1. Evaluating pair programming with Respect to System Complexity and Programmer Expertise, Arisholm, et al (Feb 2007).
  2. The Effect of Pairs in Program Design tasks, Lui, Chan and Nosek (Feb 2008).
  3. The Costs and Benefits of pair programming, Cockburn and Williams (2000).
  4. Pair Programming Illuminated, Williams and Kessler (2003).