The Pairing Staircase
Pair programming is an essential XP practice with many benefits - that are not the topic of this post. But it can be a challenge to rigorously follow the pairing imperative day in and day out. I see plenty of cases where a developer will stray. Maybe they feel that they can go faster on "this one thing" by themselves. Sometimes strong personalities get in the way of productive pairing. Companies like Thoughtworks and Hashrocket have so fully embraced pairing that perhaps these issues are not a problem for them. Those of us who are working toward that state have some hurdles to clear.
Once a team has nice pairing stations and agrees that pair programming should be the norm, we get to pick into the more subtle issues around pairing. When a certain developer picks up a new story, does she generally avoid working with one particular teammate? Is one member of the team consistently working alone? At its best, pair programming matches every dev with every other dev. Pairing styles should differ when a junior developer pairs with a senior developer compared to when two more equally matched devs sit down together. But however it happens, getting everyone working with everyone else is a good goal.
In our last retrospective we decided that one of our SMART goals would be for every developer to pair with every other developer. As the manager, I often do the measurement part of our goals. I threw a 6 by 6 matrix on a whiteboard. I crossed out the diagonal and said that the goal was to fill the matrix with checks before the next retrospective. Well… with pair programming "Chris and Pat" equals "Pat and Chris" so I erased the reflection. I eliminated some duplication where each name was written twice and was left with a nice looking staircase.
I had never heard anyone talk about such a diagram so I Googled "pair stair half matrix". Up popped a blog post that referenced a CITCOM 2009 Europe session titled Pairing with PJ. Turns out that one of the CITCOM organizers, Paul Julius is writing a book about pairing – cool. His CITCOM session referenced the same half matrix that was on my whiteboard.
OK, so a half matrix representing the (n^2 - n)/2 combinations of n developers pairing is not a completely original thought. But it is a useful one as it provides the team with a mirror onto their pairing patterns.
To use the diagram as a mirror, follow the "path" associated with a developer. To the bottom and/or to the left of each developer is a path that connects their squares. Consistent checks or absent checks may indicate an issue to be aware of. Over time, if you see patterns develop, you definitely have an issue to address.
In the figure to the right, you should see a pairing staircase with dev names and a number of check marks. I have added color-coded "paths" as arrows - obviously the arrows are only for the sake of illustration. It is immediately obvious in this simple case that Mark has been absent or sitting alone for the whole iteration (actually he starts next week). We also see that Dave has done very little pairing in this iteration (he was on vacation). Looking at the paths is a quick way to find patterns that may or may not emerge in the team dynamic. Getting the pairing staircase fully built in every iteration is an excellent SMART goal for our team.
When the staircase runs down from left to right as pictured, it looks kind of pessimistic. I taped up a whiteboard for the office so that we can look back on our pairing patterns (including what style of pairing was done). But when I did it, I flipped the stairs so that they run up in a more optimistic orientation.