Recently we had particularly good retrospective where the team were able to admit that each of us has had difference experiences pairing. We were honest in saying that despite having “done pairing” we’d all done different amounts of pairing and that, at times, we weren’t even sure what we were supposed to get out of it.

There can be a fair amount of peer pressure to pair but if the pair don’t know what they can get out of it, it’s unlikely to succeed. We should be honest about that. What makes a good pair (see a previous post) and how do we know that we’re getting something out of it?

Once we honest in our experiences and expectations around pairing, we were able to be explicit in what we want to achieve. We had the conversation along the lines of “do we even believe we could get something out of pairing? Do we want to try?” and when the team bought into that idea we could be explicit about starting from scratch and putting tools in place to help us.

Some techniques I favour include

• When sitting down to start a session, state explicitly what each of you hopes to get out of the session. In short, what you think a pairing session should be like.

• Each pair can set up one or two “rules”, written on cards and placed prominently to remind each other about something they feel is important to the session. For example, I often have a rule “ask don’t tell” to remind me to be asked before I go rambling on about something in the code.

• The silent partner; saying up front that when not driving, the silent partner should hold their tongue and make notes / record a task stack. Interruption is interruption, so be considerate about when to make a comment. This one should be agreed up front, it may or may not be appropriate for your pair.

• Rotate the pairs frequently. You’ll have to agree amongst yourselves at what frequency but I think around two days is enough before rotating.

• Most important one of all; have a mini pair-retrospective at the end of the session. It’s a great chance to ask the question “how was that for you?” and a great way to let the other person know if some aspect didn’t go well.

Another useful tool can be the pair stairs. It’s very easy to avoid pairing rather than face it’s challenges so pair stairs can be a good way to keep you honest. Probably the most helpful thing though is having people on the team that have lots of experience pairing, know what the team can get out of it and are able to help guide pairing sessions for the less experienced.

Pairing is hard. It’s probably one of the hardest things we do as developers but it can also be one of the most rewarding, personally and for the team as a whole. Collaboration has given the world some of its greatest achievements but you have to be honest that in this case, you might have to work for it.