Pair Rotation in a team for effective pair programming

Question

We follow pair programming in our company and always face the issue of balanced and effective pair rotation within the developers on stories.

We follow a simple metrics in which every developer's name is mapped with every other developer and we mark the respective intersection whenever two developers are pairing.

This is not working out well, we cannot track how much time a pair has spent pairing and people forget to update the metrics many times. Tracking the pair rotation is helpful because we want the project knowledge to be shared across the team, and not just one pair. So usually what happens is, whoever is pairing keeps pairing till the entire story is completed (given they have better context), and no body else knows about what is being done & if the story or a regression/production bug comes back, the same pair has to pick it up (leaving whatever they are currently doing), which is what creates a bottleneck.

Are there any known metrics that can be used for tracking the pair rotations.

Answer 1

Why do you feel the need to track the amount of time developers have paired with each other? Is it because you want to remove the bottlenecks that you mentioned or want to share knowledge around the team, or because the code you're releasing to production is buggy?

I'd suggest tracking the things that are important to you and leave it up to the team to workout how best to achieve them.

As an example, track whenever a story has to be assigned to a specific pair and try and bring that number to zero over time.

Answer 2

I'm not sure that you want to do this. Your reason for pairing is very good - sharing knowledge across the team, making sure that multiple people are exposed to different parts of the code so you have more people to be able to work in areas. However, the whole idea of timeboxing pairs, especially in the middle of a particular work item (a story, a bug, whatever) doesn't seem like a good idea.

Breaking up a pair in the middle of a story interrupts flow. You have two people who have come together and are working effectively to solve a problem. In the middle of them coming up with a solution, implementing, and testing it, you rip them apart and try to create a new pair. This new pair needs to develop as a team, get on the same page, and then continue with the work - the net result is a disruption to productivity and quality.

I like the idea of creating new pairs, but only when it makes sense. I would advocate pairs working together for a sprint. In order to better spread pairs around, do keep track of who has paired and try to keep new people working together. Of course, if there are people who don't work well together, you may want to avoid that pairing in the future.

Your concerns about needing to interrupt work if there is a regression, a bug, or the story comes back up doesn't make sense to me. That approach of "drop everything to fix an issue" isn't agile. Unless the issue is a showstopping issue, it should be put into the backlog and prioritized and fixed when appropriate. If it is urgent and needs to be immediately addressed, you don't need the same pair to work on it. Assign it to a pair that has someone who has knowledge of that part of the code. This leaves you with one person who understands the functionality along with the design and implementation and someone who can now learn it as they implement the fix.

Answer 3

One thing I would consider is the size of your stories. Can you break them down into smaller chunks, so that it is easier for new pair combinations to pick up? Are you frequently running into a single story taking a sprint or more worth of work? Can you scope a story down to one to two days, making larger more complex features into smaller vertical slices of value that can be delivered sooner?

If a story takes a week or more to complete, then I can absolutely see where it would be difficult for engineers to want to rotate pairs. Engineers typically want to see something to fruition. By structuring your stories, where possible, into smaller vertical slices of value that can be delivered quickly, your allowing for more opportunities for a pair to complete a portion of work to the end, reducing friction to the idea of 'rotating off before delivering value'.

This approach also helps engineers get into the mindset of constant delivery of value, where small check-ins are the norm, versus large feature releases.

Answer 4

Assign a pair anchor that will be on the task from start to the end. A task estimation should not be longer then 2/3 days.

Switch pair every half a day. Thomas description of breaking flow would be correct if there was no anchor left.

If you want a visual feedback keep a pairing table on your whiteboard and let the anchor update who he paired with.

Beware not everybody is happy to switch that often, some people prefer to see a feature from the start to the end often with the same person. I think this creates knowledge silos and requires for long code review processes.