Pair Programming Matrix

At Pivotal Labs we consider ourselves to be expert pair programmers, but sometimes even we need help. We identified (thanks to a retrospective) that we were being very unbalanced in our pairings: some developers seemed to pair with each other often while rarely paring with others. We wanted a lightweight means of enforcing balanced pairing. That’s when someone remembered the pairing matrix.

Pair Programming Matrix

A blog post titled “Pair Programming Matrix” inspired us to try our own pairing matrix. It’s a grid with a cell intersecting each pair of developers. Here’s a photo from the original article:

We thought we would give it a try, only using a Google Spreadsheet with some fancy conditional formatting instead of a whiteboard

Upshot

Overall the pairing matrix serves it purpose: it helps us have much more balanced pairings. We’ve been using it for several months and will likely continue using it so long as it seems useful.

It strikes me that a pairing matrix would be a good way for team new to pair programming to add a bit of helpful structure. I would hesitate to add this structure if it’s unneeded: “if it ain’t broke, don’t fix it.”

Pros

Exposes “holes” and “hot spots” when developers are not pairing together or pairing too often

Easy to use, reset

Can be a simple way for teams new to pairing to get started

Cons

Time off skews the matrix

Does not work well when team structure fluctuates often

Becomes unwieldily with larger teams

Examples

Here are some screenshots of pairing matrices at different stages. Team structures changed and thus the featured developers were not always the same, but you get the idea.

Early in the process. We already have a hot spot!

Pairings are starting to even out.

Over time we were much more balanced.

Eventually we needed to reset.

Too big!! We abandoned this and made the team smaller.

Make Your Own Matrix

By popular demand, I have made a blank, read-only copy of our pairing matrix, complete with conditional formatting. Feel free to duplicate it and modify the copy. Please post your own modifications and optimizations in the comments.

Why do you strive to equalize pairing? People will determine on their own with whom they are most efficient. Why break up productive pairs?

May 10, 2013 at 4:34 am

Joe Moore says:

Ryan — Good question. As with many things at Pivotal we identified inconsistant and infrequent pair rotation as a problem during a retrospective. To be clear, the team as a whole agreed that this was an issue, rather than a top-down manager level decision. At Pivotal we find frequent and diverse pairings beneficial for many reasons: knowledge transfer, exposure to different perspectives, exposure to different skill-sets, diversity in personalities, just to name a few. The team felt that long-running pairings (in this case, exceeding 3 days) was a drawback, and that a pair’s efficiency diminished the longer they were together.

The pairing matrix made it easier to know which pairs had paired “a lot” vs “a little”. It was a helpful tool. One of the team members even wrote an app for that: http://www.pairtrix.com/.

Regarding people determining the most efficient pairs on their own: our team identified that were were bad at doing this. The same people tended to pair up more out of habit rather than efficiency.

Regarding braking up efficient pairs: the matrix tool was just that: a tool, and not an enforcer. If pairs wanted to stick together until the end of a user story then they did. If it made sense for them to work on several stories in a row then they did so, also. But at least the tool prompted a conversation about whether or not it was time to switch rather than falling into an easy (but not necessarily efficient) habit.

FWIW the project I’m referencing is the only project where I have ever used a pairing matrix; it is also the largest full-time pair programming project with which I have worked.