I had the chance to run a 90 minute session at this year’s Agile Conference in Chicago. The conference as a whole was an terrific experience but here I’d like to talk about my session, and what I learned from it.
The session focusses on the barriers that prevent people from adopting pair programming. I’ve encountered a whole variety of reasons for this in different teams I’ve worked on, and the first part of the session involved the participants working in groups to talk about specific characters I’d created who exhibit some of these problems.
We used these discussions as a catalyst to look over the general set of issues that can be a barrier to people’s adoption of pairing. We then went on to talk about tips and tricks for tackling these issues, but I’ll save those for another post.
Here’s what we came up with.
Issues
Lack of Feedback Within the Team
Trying out a radical new practice like pair programming can feel pretty disruptive to some people. It’s important when a team is going though such volatile changes that they get plenty of opportunities to feed back to one another about how it’s going. It’s also important that they recognise the benefits that pairing can bring for them. Offering pairing as a solution to a problem that the team has identified for itself will make for much more enthusiastic adoption than simply mandating it as a necessary agile practice.
Lack of Management / Team Approval of Pairing as a Valuable Practice
Again, if the team doesn’t recognise that pairing will help them, they’re unlikely to really give it an enthusiastic – and therefore successful – shot. More importantly, if management isn’t actively encouraging teams to try the practice out, it’s likely that at least some of the team will be reluctant to try it for fear of displeasing their boss.
Lack of Trust in Team from Management
The benefits of pairing are counter intuitive: two people working together are actually much more than twice as productive as if they were coding solo, yet this is not obvious to the causal or cynical observer. Management don’t necessarily need to understand this, but they certainly need to make the team feel trusted to make their own decisions about whether the practice can make them more effective. If the team don’t feel trusted by their management, they’re unlikely to try out a practice that can seem mysterious and even frightening to the uninitiated.
Lack of Trust Between Team Members
Pair programming brings people much closer together than they might normally have to be in a work situation. Thoughts and opinions are shared in rapid succession about quite subjective issues. It’s important that team members trust each other in order that they can settle in to this new level of intimacy.
Lack of Respect for Cultural / Gender Differences
Again, the level of intimacy between team members that paring demands can cause problems when people fail to consider one another’s backgrounds. Different people have different needs for personal space, for example. People with an intense need for personal space may be put off pairing simply by the idea of having someone sitting in such close proximity to them. Pairing that person with someone who is from a very tactile culture can be a disaster! It’s important to respect and work around these kind of issues as they are usually deep seated and cannot be simply rationalised away.
Need the Right Incentives
Often team members, especially from organisations used to a more traditional way of working, can be given incentives that don’t make paring the obvious choice. If people tend to be singled out for praise for delivering a particular feature, for example, it’s likely that they will be keen to own features by themselves so that they can take all the credit.
Lack of Experience at Pairing
There are some basic protocols that make pairing work effectively – talking about what you’re doing; swapping the keyboard when a new test is written or a test passes for the first time; taking regular breaks – but these are tricks that people tend to have learned though experience. On a team full of people who have never tried pairing before, you can expect some fairly basic mistakes to be made that may make pairing feel less enjoyable or effective than it could be.
Fear
This seems to be a significant barrier for people who’ve never tried pairing before. Some people are simply afraid of the unknown – they may have been programming solo since they were quite young and are really used to this way of working.
The other big fear is the one of intimacy – having to share your ideas and opinions freely and have them instantly judged by someone else is a much more direct way of working than many programmers are used to. This goes along with a fear of looking stupid – many programmers fear their ideas or designs are not that good, and would rather not have to demonstrate this to a pair.
A more sinister fear is the one some ivory-tower builders can have of losing their job security – by being forced to share their ‘unique’ domain knowledge with their team members will they lose their power and potentially their hold on their job?
Autism
Joseph Pelrine has talked about the higher-than-average incidence of Asbergers Syndrome or other ASD psychological conditions within the computer programming progression. People on the autistic spectrum demonstrate many skills that make them excellent programmers, yet they also suffer real barriers in communicating with other people. These barriers can make the close collaborative experience of pairing stressful for both them and their pair, and it’s important to be able to recognise the signs of this and work around them.
Need to Understand the Importance of Learning
A big part of the benefit of pairing is the spread of knowledge throughout the team, both about the problem domain and the technology being used. When an organisation simply doesn’t understand the value of learning, it may not yet be ready for the benefits that pairing can bring.