The idea here is that someone who has been on the project for a great amount of time (possibly the Tech Lead) can help bring newer members of the team up to speed.

They can help the new team member to get their development environment up and running (although clearly making this as automated as possible is beneficial!) and help walk them through the code covering any questions they may have.

This role may also involve going though the reason that the team is there (i.e. what problem we are trying to solve), an overview of the way the problem is being solved and the technologies being used to do so, patterns being used in the code and any other information that is considered useful to the new team member.

My colleague Pat Kua covers this in more detail, referring to it as Student to Teacher in his series of posts on onboarding tips.

Using pairing in this context makes it much easier to get new team members up to speed, therefore improving their ability to be a productive part of the team.

Pairing up senior and more junior members of a team is a very effective way to increase the level of the junior person.

More senior team members have a lot of knowledge which they can pass onto junior team members - as this knowledge comes from experience in the field it is not necessarily something that could be gained from reading a book.

On several of the projects I have worked on one of the more Senior members of the team has been the one who provided the onboarding for new team members.

Clearly there needs to be a balance with this approach because no matter how patient the senior person is, at some stage they are going to want to have the opportunity to work with someone closer to their level of ability.

Using pairing in this way helps to bring up the level of the less experienced members of the team and allows them to learn things that more senior members of the team probably take for granted.

This one is a harder one to sell because there are no doubt other ways of sharing knowledge on teams beyond just pairing.

However, I have seen it work successfully on projects I have worked on for spreading the knowledge of how different parts of the application work amongst the team. This is generally referred to as increasing the truck factor - no one member of the team should be invaluable.

I saw this as a benefit on a project I once worked on where I had spent the majority of our time pairing both with ThoughtWorks colleagues and client developers.

At the end of the project we had a meeting to discuss what handover needed to be done in order to allow the team to continue when we finished. We really struggled to find anything at all - the knowledge of how to do the vast majority of tasks was completely spread out amongst the team and no one person had knowledge that the rest of the team didn’t have.

This is almost like a side effect of pair programming but it definitely has some gains which should not be discounted.

I’ve never used parallel pair programming, only pair programming which is used the majority of the time on projects I have worked on.

I would be interested in knowing whether we can still gain some of these other benefits from using parallel pair programming - it seems to me to be quite a streamlined version of pair programming, and I wonder whether we would still get the useful side effects of pairing if we don’t pair all the time?