On Pair Swapping

Pair swapping is advantageous in pair programming.  While knowledge sharing is one of the many benefits of pair programming, having this knowledge siloed in a single pair is better than a single developer, but not as good as spreading across multiple pairs.  The larger the system, the more important this becomes.

Benefits

Pair swapping has a number of benefits, including:

• Thought Diversity
• Promotes Collective Code Ownership
• Building relationships with team members

How many times, even as a pair, that the pair gets stuck on some problem.  The pair has exhausted every idea they can think of, scour the internet for Stack Overflow results but come up empty handed.  A pair swap occurs and someone comes in with a new perspective and solves the problem quickly.

Promotes further collective code ownership.  It's no longer finger pointing a pair; it's become let's fix this and each pair is empowered to make changes.  Over time, coding standards and patterns emerge that the entire team developed.  The codebase evolves into a more cohesive work rather than different styles throughout the codebase.  As patterns emerge, code maintenance becomes less expensive as there are fewer surprises.

Pair swapping allows you to get to know your fellow developers.  What are they passionate about, what keeps them up at night, what gets them up in the morning?  Team building is important to having a productive team.  What better way of team building than to learn about our fellow team members one waiting-for-a-build/tests at a time.

Process

So, how then, might we do this effectively?  Every pair starts out with a card and after a defined amount of time, one person stays with the card in progress.  This is called anchoring.  The other person swaps to another anchor.  The anchor brings the new developer up to speed, which should only take a few minutes, and then proceed.  When the time comes to swap again, the person that previously anchored should now go to a new anchor.  Anchoring is also useful when on boarding new team members.  Depending on the code base, encourage new team members to anchor after a little while.  This will help gauge how well they are picking up the code base.  Ensure you are always alternating anchors.

Frequency

Monday and Wednesday right after stand up has been a good practice.  I've experimented pair swapping 2x/day up to a week and longer.  Half day is too much context switching and longer than a week seems to get stale.  Your mileage may vary.  Often the time you think you don't need to pair swap is the time you do.

Pair swapping is worth the effort.  If you're lucky enough to be on a team of > 3 (swap the lone developer) then get to know your team members better one build/test run at a time!