At XP Day 2008 I proposed an open-space session on pair programming. Specifically, I wanted to explore the reasons why programmers might not want to pair, or find it such an unpleasant experience that they’re put off doing it again.
Judging by the great number of people who turned up and stayed for the session, it’s clear I’m not the only one who is struggling with these issues, adding more weight to my suspicion that pair programming is the hardest of all the XP practices to master.
I worked with Laura Plonka to devise and run the session. Laura is researching her PhD thesis on pair programming, using video footage to analyse pair programming sessions, then running a retrospective where the pair get to debrief and share their experiences of the session.
Despite the huge contribution from everyone present, at the end of the hour, I felt as though we had only started to scratch the surface of the problems we’d identified. It seems as though too many teams, even at organisations who are ostensibly keen to embrace ‘agile values’, suffer from some toxic cocktail on this menu of dysfunction:
- an agile-zealous leadership which forces people into unwilling or poorly-chosen pairs
- a culture that, at some level, values heroics over craftsmanship, such that programmers may feel a subtle or unconscious reluctance to chose to pair on a task unless it looks utterly daunting, and there could be no shame in being seen to ‘ask for help’.
- a team that disagrees on the types of tasks that should be done as a pair
- team members who are far enough along the autistic spectrum (as Joseph Pelrine and Ben Fuchs pointed out, we have a higher proportion of these than many other professions) that they find the level of inter-personal communication required for pairing difficult or impossible.
- ‘Experts’ on the team who feel that pairing with less experienced members of the team will slow them down too much
- ‘Newbies’ on the team who are afraid to ask for help, or feel the work they’re doing is too mundane to need to be done in a pair
There were masses more issues brought up – these are just the main few that I can remember now. Hopefully more people will write up their sections on the session’s page on the XP Day wiki, or maybe comment on this blog post.
I spent the latter half of the session in a small group discussion the influence management can have on the adoption and enjoyment of pair programming. Paul Field and I enumerated the benefits that teams who embrace pair programming and create a culture where it works, can enjoy:
- Better system knowledge across the team (higher truck number)
- Skills transfer between team members (free training)
- Team bonding
- More defects found & found earlier
- Better solutions/designs
- More fun (better staff retention & morale)
- Better focus (less time wasted in email / facebook)
It’s worth holding onto this list, and thinking about it when experimenting with pair programming within your team. Not all these benefits will be immediately apparent, so it’s worth being patient and trying to figure out ways to measure them to give you feedback as to the success of your experiment.
Another great idea I heard for teams that want to try pairing but are unsure as to which tasks are appropriate: try doing every task in a pair for at least five minutes. If, after that time you both agree that it’s a waste of time to do it as a pair, you can split up.
I still feel like there’s huge amount of work to be done to collect and disseminate the patterns and anti-patterns around pair programming, but I’m glad to have at least stirred up the pot a little. Thanks to everyone who turned up and contributed so much, and thanks especially to Joseph and Ben for organising a follow-up session later in the day where we had the opportunity to drill down into those psychological barriers a little bit more. Great stuff.
Hey Matt,
With one of the teams that I’ve worked with previously, when discussing whether to pair and where to start, I suggested to them that they pair on everything, all of the time. It was only when the team was starting to ask the question “why do we still need to pair on this piece of work?” or I was discussing in 1-2-1s their respective frustrations with having to pair on pieces of work that were perceived to be simple enough to warrant not pairing, that we then did a retrospective on pairing to define when the team would pair and what they would pair on. I’ve tried to come up with a natty title for this pattern and the best I can do is “The Wood For The Trees”, I’ve blogged myself about an agile adoption pattern called Wax On, Wax Off and I think that title could be applied here too. Perhaps somebody else reading this will be able to suggest a better title.
More recently I’ve observed something similar to what you mention above, heroics being valued above craftsmanship. In my case though I think there is a subtle difference which is worthy of note. With developers that have for a long time been managing their own pipe lines and putting themselves under pressure to deliver it’s difficult to make them feel as though they have the space to be doing the right thing, particularly when they perceive that to get to a point where they are doing the “right thing” to be such a big step in to the unknown. Ironically of course, it’s at times like this that pairing can be most effective and as such, it is important to offer as much support as possible.
Hope that helps.
Hi, Matt. I just posted on antipatterns in pair programming and got pointed at this. I’d be very curious to see what other things you and Laura have identified as source of trouble.
@William, thanks for these, they look bang on. Check out the wiki page from XP Day, and also Gojko’s blog post about the session for more info about what we learned.
I still feel like a lot of the barriers are cultural. Most people that are, seem to be inhibited from giving pairing a proper go because, for various reasons, they’re afraid to look stupid in front of their peers or look like they’re slacking off and enjoying themselves in front of management.
Thanks, Matt.
Regarding the “afraid of looking stupid” bit, I think of that as the locker room effect. The first time you enter into a place where everybody is naked, it is really scary to take your pants off. But once you get used to it, it’s not a big deal, because everybody is naked. Being explicit about that seems to help some people adjust.
As to the fear of looking like you’re having fun in front of management, I definitely have seen that, too. There are some places that have a “if you ain’t sweating, you ain’t working” ethic, and I think there’s no short-term solution for that. (I did blog about a long-term approach, though.) But some people have that reflex even when their managers honestly don’t think that way, in which case having the managers be clear that they value results more than appearances can work wonders.
i also think cultural differnces between pairs also effects the pair programming practices. if somebody comes from remote area or from a different country and joind a company where local guys are very different than him, it is very difficult for the guy who come from another country to share his thoughts. I found they are bit shy, less social skills, but they are good when both pairs from same country where they share same culture, values.
I am doing a thesis on this – how cultural differences between programmers effect the pair programming practice which inevitabley effect the whole quality of the project.