Pair rotation

One of the core eXtreme Programming practices is pair programming. There are lot of different blogs and places to find more about pairing. But one thing closely associated with pair programming which usually makes it even more powerful is pair rotation.

What is it?

Pair rotation is when the team uses pair programming and changes pairs frequently.

Why?

What you achieve from pair programming and pair rotation working well is collective code ownership.

Due to pair rotation the team is much more healthy as

• Everyone knows about most parts of the system
• No one person or few individuals are overloaded with a lot of work
• It makes code reviews obsolete (although pair programming itself reduces the need of code reviews)

When

Usually teams rotate pairs right after the standup when they signup for the work they would be doing. This may also happen at a certain agreed upon frequency. This frequency can vary from 1 day to 3 days. Multiple resources on pair programming talk about rotating pairs multiple times a day, but I haven’t seen it done often. Most of the times it doesn’t help in dealing with context switching and can lead to the team being slower.

From my experience working on multiple teams of various sizes, I would say that if we don’t switch pairs for more than 2 days then it is something to pay attention to. Pairing for beyond 2 days usually means there might be a knowledge silo being created on the team.

How

There are two ways I have seen pair rotation happen on teams:

Anchor

This is when pair rotation happens where one person (say ‘A’ ) from the pair (of ‘A’ and ‘B’), continues on the user story till the completion of the story. The person ‘B’ in this context, can be replaced by ‘C’ , ‘D’ and so on. This means that person ‘A’ carries context and conversations throughout the story. This technique can be useful when

• Someone is new to the project and trying to understand some area well. It is good for the person to be the anchor pair on the story.
• When the story needs a lot of people interaction (may be with other team or even vendors) it may be useful to have one person stay along the whole story to provide historical context.

Relay

This is when one person from the pair continues but the second time you switch pairs the new person stays and the person who started initially person leaves the story. The pairing would look like this :

• A and B
• B and C
• C and D
• …and so on

The advantage of this technique is that different pairs are looking at the same piece of work. It works well when most of the team knows about the current story and the logic of the story is not too complex and can be shared quickly.

One thing to keep in mind is that the above way wouldn’t work if stories regularly run for more than a couple of days.

Conclusion

These are just ways of trying things. Be agile and don’t think of these as rules. Try and tweak these as per your team and the work you are doing.

Thanks to Nikita Gupta for reviewing this blog.