In my previous post on Pair Programming I talked about the individual practices that make pairing more effective. Effective pair programming at the team level is an art, and some consideration should be given to how it should be conducted as well.

Pair Switch Regularly

One of the mistakes I’ve seen with pairing is regarding how long someone should pair together. Pair switching too often causes a lot of context switching, both in terms of potentially checking out and building code, and (more importantly) mental context switches. A lot of people talk about having to “get in the zone” in order to be productive as a developer. There is a period of time which is required before all of the distractions are cleared from one’s mind before they can really focus in on the problem; believe it or not this is just as true for pair programming. Although many people claim they can’t reach this level of concentration while pairing, this has not been my experience. It is just as true for a pair as it is a lone developer. The trick is to enter that zone together.

The other end of this spectrum is not pair switching enough. This is often referred to as being “pair married”. On the one hand you’ve paired with someone often enough to know their rhythms, which allows you to get a lot done. On the other hand, pairing with same person all the time for can get old quickly. A lot of bad habits can be picked up this way, and pairing with one person all the time can lead to thinking your way into a rut. A major benefit of pairing is a fresh set of eyes on the problem and a new perspective. Pairing with the same person all the time eliminates a lot of this benefit.

Pairs should switch on a regular basis, neither too frequently, nor too infrequently.

Pairs Should Switch Regardless of Whether a Story Is Done Or Not

Another good pairing habit is to switch pairs regardless of the state of the current story in play. This doesn’t mean both devs switch off of what they’re working on, however. What it does mean is that one dev switches out, while the other dev acts as the anchor for the story. This allows the continuation of knowledge and knowledge transfer to the next dev to occur. If the team follows this pattern then after a while everyone gets familiar with the whole codebase.

Some developers might balk at not seeing a story through to completion. I’ve been that developer at times. It can be frustrating to put so much work into a story only to pair switch out and watch someone else complete what you were working on.

Having said that, I recognize this behavior for what it is: ego.

Wanting to complete something yourself is a very me-centric point of view. It says “I did all this work, I should be the one to complete it.”, or (more insidiously) “This was difficult, the rest of team may have a hard time, so I should just do it myself”. Ego is a big driver of discontent, and it has no place in the codebase.

Another reason pairs should switch regardless of the state of the story is that quite often, after working on a particularly difficult piece a pair will simply be too close to the code. They could very well be overlooking an aspect of the code that someone else coming in fresh may immediately recognize, allowing the story to continue anew. Alternately if a story is long running and the pair is frustrated it may be beneficial to allow a developer to swap out and to work on something fresh. This eases the frustration, while again letting another member of the team tackle the problem, perhaps from a different angle.

Rather than insisting that they be the ones to complete a story, team members should give up their attachment to the code, and trust that the team as a whole can and will handle delivering it successfully.

Dedicated Pairing Stations

This is an often overlooked necessity. Often, organizations think two devs can just sit down in front of one of their workstations and begin working effectively. The first thing that developers who are pairing for the first time discover is that it becomes more difficult if there is only one keyboard and mouse, one monitor, or even just space for one dev to sit comfortably. Logistically, pairing is made easier by providing a second mouse, keyboard, and monitor, in a space big enough for two people. This allows each dev to easily be able to reach the controls, see the code, and be comfortable next to each other.

Another consideration is that a lone dev’s workstation is keyed to their identity, credentials, and workspace. This means that if that dev is out sick or leaves the company then the work on that machine is not available to the rest of the team until they come back or IT grants access to the machine again. Ideally, machines/VMs are established that are accessible by the entire team via shared credentials. This allows pairs to easily switch between workspaces and to carry on regardless of the status of one team member.

Pair Planning

If the team knows that a member of the team is going to be out or even leaving the team, then pairing should be conducted accordingly. Someone should pair with that developer to insure knowledge transfer and an easy transition. If there are two or more new members joining the team then having them pair together is a bad idea. No one likes to flounder or feel like they don’t know what they’re doing. Instead, more experienced members of the team should pair up with them to give them a smooth onboarding experience.

If there is a mix of junior and senior developers in the team they should be mixed together in pairs. All junior and all senior pairs is usually not ideal (at least initially). If there are experts in parts of the codebase then these experts should be paired up with non-experts to spread that knowledge, and the experts should be forced out of their comfort zones and into parts of the codebase that they might not be familiar with, but that another team member is.

Pair Retro

This is a pattern that can help developers new to pairing become better at it, and to help developers who have been pairing for a long time to remember what it was like to pair for the first time again. The pair retro is a mini-version of a standard sprint retro. The pair talks about what went well (We really knocked that story out!), what didn’t go so well (Hey Senior Dev, I didn’t get to touch the keyboard very much!), and how to improve (I’ll try to give up control more often, and you’ll be a little more aggressive at the controls.). This is a great pattern for new teams, and especially for new pair partners. After a while (probably sooner than you think) it will become unnecessary as devs will become more used to pairing and will norm on pairing habits, but in the beginning it can be an invaluable learning tool.

These are some of the practices that over the years I’ve found to engender effective pairing at the team level. I hope this has been useful, and happy pairing!