Pairing
Pairing is an agile software development practice where two team members work together on the same task at the same workstation. This can involve coding, designing, testing, or any other development activity.
Goal
The primary purpose of pairing is to improve code quality, facilitate knowledge sharing, enhance team collaboration, and accelerate the development process.
Knowledge Sharing: Team members share their knowledge which reduces the knowledge silos across the team.
Improved Code Quality: Rather than waiting for a code review, when you might let smaller stylistic issues pass, the immediate feedback from teaming catches bugs earlier and improves the overall quality of the code.
Mentorship and Learning: Junior team members can learn from more experienced team members which speeds up onboarding.
Faster Problem Solving: Diverse perspectives and expertise can lead to faster, and better, problem solving, reducing the time to deliver.
Context
There are infinite ways to solve a problem or to design and write the code to build a feature. But they are not all equal. To ensure the most effective solutions, along with the highest quality code, we need to leverage the collective intelligence of the team. In creative work like software development, the more diverse perspectives and expertise we can bring to bear on a problem, the better the solution will be.
Inputs
| Artifact | Description |
|---|---|
| Working Environment | A shared working environment, including hardware (e.g., a large screen, comfortable seating) and software (e.g., Design software, IDEs, code repositories, handover timers). |
| Coding Standards and Conventions | Predefined coding standards and conventions that the team agrees to follow to ensure consistency in the codebase. |
Methods
- Driver-Navigator: One person writes code (the Driver) while the other reviews each line of code as it's written (the Navigator).
- Ping Pong: Team members alternate roles between writing a test and making it pass, promoting TDD practices.
- Remote Pairing: Utilising tools for shared coding sessions, facilitating pairing despite physical distance.
Criticism
| Name | Description | Mitigation |
|---|---|---|
| Decreased productivity | Pairing requires two team members to work on the same problem, which can be seen as an inefficient use of resources. | Studies have shown that there is no difference in speed of delivery between pairing and working alone. The benefit of being able to solve problems quickly outweighs the apparent inefficiency. While there is no time difference, the quality of the code is higher when pairing. |
| Limited to Certain Tasks | Not all tasks are suitable for pairing, such as tasks requiring deep concentration or individual creativity. | Use pairing selectively for tasks that benefit from collaboration, such as complex problem solving, and allow for individual work when more appropriate. |
| Introvert Exclusion | The highly collaborative nature of pairing may be uncomfortable for introverts or those who prefer solitary work. | Teamwork is a skill that can be developed, and the team can adjust the session's pace and energy to accommodate different working styles. |
| Only focuses on the dev work | Pairing is primarily used by developers only, whereas other roles in the team could benefit from the transfer of knowledge and shared problem solving. | Encourage pairing across all roles in the team, not just developers, and investigate teaming. |
Anti-patterns
- Dominance by one partner: One person taking over the session, limiting learning and collaboration opportunities.
- Lack of engagement: Partners not fully participating or contributing equally to the task.
- Inconsistent practices: Not standardising pairing methods across the team, leading to confusion and inefficiency.
- Ignoring team dynamics: Failing to consider personality matches and team chemistry when pairing individuals.