Ways of Working104

Adopting Pair Work

an extension to Pair Programming

Evan Leybourn

February 27, 2019


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.

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



Defect Rate

6 hours

½ hour

½ hour


Task B

Initial work



Defect Rate

4 hours

½ hour

0 hour



Total(Initial + Test + Rework)

(6+4) + (½+½) + (½+0)= 11.5 hours


Average defect


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



Defect Rate

7 hours

1 hour

1 hour


6 hours

½ hour

1 hour



TotalMax (Initial + test + Rework)

(7) + (1) + (1)= 9 hours


Average defect


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).



Subscribe to “Emergence: the Journal of Business Agility”

Delivered to your mailbox four times a year, we bring together a curated selection of exclusive stories by great thinkers and practitioners from around the globe that you’ll only find in our publications.

These stories, research reports, and articles were selected to broaden your horizons and spark your creativity.

BAI Individual Membership Benefits

  • Unrestricted access the business agility library

  • Download complete eBooks on the most pressing topics

  • Replay your favourite moments from any of the global Business Agility Conferences

  • Network with your peers from around the world

  • Member discount on your subscription to Emergence

1 / Infinity

October 6, 2022, 5 minutes read time

Connecting Coach to Business Need

September 12, 2022, 54 seconds read time

2022 State of Agile Coaching

July 10, 2020, 15 minutes read time

From Ensemble to Orchestra

December 5, 2020, 32 seconds read time

Leaning Into Culture During Times of Crisis

July 29, 2020, 26 minutes read time

Structural Agility

You have NaN out of 5 free articles to read

Please subscribe and become a member to access the entire Business Agility Library without restriction.