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 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 |
TotalMax (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.
- Evaluating pair programming with Respect to System Complexity and Programmer Expertise, Arisholm, et al (Feb 2007).
- The Effect of Pairs in Program Design tasks, Lui, Chan and Nosek (Feb 2008).
- The Costs and Benefits of pair programming, Cockburn and Williams (2000).
- Pair Programming Illuminated, Williams and Kessler (2003).
The component MostRecentArticles has not been created yet.
The component LibraryHighlightsSmall has not been created yet.
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.