1

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.

  • 4
    Define "not working out well". Exactly what problems are you experiencing? Why is achieving a time balance so important to you or your team? What do you hope to achieve by tracking pair rotations? – Thomas Owens Apr 2 '14 at 17:49
  • Added more details to the question – Vivek Apr 2 '14 at 17:55
  • I just want to be clear - are you trying to split up pairs in the middle of implementing a story? – Thomas Owens Apr 2 '14 at 18:36
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.

1

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.

0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.