How Do We Encourage Teams to Pair More?

An idea for an open-space session, by Matt Wynne

I think Pair Programming is extremely important to the success of a programming team, but every time I join a new team, I seem to find I'm in a minority of people who feel that way, let alone have any experience of actually doing it.

I'm not talking about trying to convince your manager that it's a good idea. Let's assume he or she trusts you all do whatever is right for the project. I'm talking about convincing your peers to come out of their caves and share their thoughts and ideas in regular, constructive, creative, pairing sessions.

I'm looking for a room full of people who understand and care about team dynamics, group psychology and all that deep and intangible stuff, so that we can:

• identify, and start to unpack the issues that block people from embracing pair programming
• identify concrete exercises and techniques that can be used to help teams learn to pair successfully

The open space attracted over 30 participants. We divided up into groups to brainstorm lists of "blocking issues" then combined lists to look for themes. Groups broke apart to explore each of these themes. The themes identified were:

• Management / Process Issues
• Psychological Issues
• Knowing What Tasks are Appropriate for Pairing
• Pair Constellations (Expert-Newbie etc)
• Working Habits
• Did I miss any? -- MattWynnne

Process theme

The brainstormers identified these blockers and the people addressing the theme (Matt Wynne and Paul Field) made the following suggestions:

• People can feel forced into pairing or forced to pair with particular people:
  • The team (a.k.a. the individuals in it) must choose to adopt pairing as a practice and the particular rules by which pairing works for them.
  • Coaches/managers should use Retrospectives to help the team adopt and refine pairing through experimentation.
• It's takes too long to write the code / progress slows
  • Make the expected benefits explicit. Typically these are:
    • Better system knowledge across the team
    • Skills transfer between team members
    • Team bonding
    • More defects found & found earlier
    • Better solutions/designs
    • More fun (better staff retention & morale)
    • More focus (less email/facebook)
  • Consider and, if possible, quantify these benefits when trying variations of your rules for pairing.
  • Progress may slow initially when pairing is introduced but you would expect it to pick back up as some of the benefits above kick in (measure it!).
• Managers "butt-in" / Can't pair because of too many things "in flight"
  • These are process smells. If the team commits to pairing for an iteration, it should stand by the commitment and use an initial assumption that anything that blocks pairing is an impediment and should be removed. This approach can force process smells to become maximally smelly and the team and coach can apply appropriate de-odourising sprays.
    

References

• http://blog.mattwynne.net/2008/12/16/why-pairing-sucks-in-08/