views:

583

answers:

9

Some members of the team are having problems programming together. Different gender, different culture, different age. How to deal with those problems? - Do not pair them together, or - Pair them together and let them come to a "golden middle"

+12  A: 

Pair programming is based on the idea that the interaction of two programmers adds value. If this is not true, change the pairs... let them choose. Programming should be fun!

Sklivvz
I'm not sure letting people choose pairs is a good idea. It seems like a recipe for pairs that have the same experience and views. That setup doesn't add cross-pollination value.
JeffH
@JeffH, I agree with you but I also think that if two programmers who don't like each other are forced to work together, there is no value in diversity.
Sklivvz
+3  A: 

What exactly are they having problems with? Do they not get along, not understand each other? Are they at different levels of programming experience?

It may help if you have a team member that can act as a "mediator" of sorts. Somebody who's successfully done pair-programming in the past and can help the two through their first few times together.

muloh
+9  A: 

How about rotating the pairs every week or every sprint so that if there are issues between a couple of pairs they don't feel like it has to be that way forever. I think if there is a specific time frame that you have to work with someone you do not get along with it makes it easier to "suck it up" and hopefully you won't lose any great people that way.

If after a few rotations you notice a specific individual that nobody is enjoying it may be appropriate to focus on adjusting the way that individual interacts with the team or if it continues perpetually removing them from the team all together.

spoon16
+1  A: 

The first step to resolving conflicts is to recognize that people are different. Even the most mild mannered programmer's patience can be tried in pair programming, it can be very stressful. Some people withdraw when they are confronted by conflict, others get aggressive.

The best way of approaching pair programming, in my experience, is to have a detailed discussion of what it is you want to accomplish for the session, before you lay hands on code. This will put both of your minds on the same track. When you disagree on something, stop coding, discuss it away from the computer, try to find common ground and most importantly don't dismiss any ideas your partner may have. Take breaks; don't work for 2 hours straight, try to stand up or go for a break every 45 minutes or so.

Kris
+1  A: 

Talk about pairing troubles as a group, and make sure the group is aware of different pairings that aren't working. That way, the group can help ensure that your pairs aren't avoiding each other. If you keep a disfunctional pair separate, they will always be disfunctional.

Get the pair to open lines of communication; try to get both sides to do new things. Assuming both people are genuinely good developers, they both have much to learn from one another. Try to alter their attitude from teacher to student.

Heath Borders
+3  A: 

Reassess your hiring practices and make sure that you select for team oriented employees.

Failing that, breath mints.

Adam Davis
Terse, but accurate - made me chuckle :).
xan
Working in a team and working in a close pair are very, very different things...
Richard Ev
But many of the same skills and professional attitudes necessary to work well in a team are the same for working well in a pair. Still, your point is valid - he should select for "pair programming" oriented employees. I'd be interested to know what differences you've found in skills between the two.
Adam Davis
+1  A: 

I'd second muloh's question - what kinds of thing are they having problems with?

In my experience these problems are often (but not always) a sign of underlying problems with the team structure / skills / relationships that need to be addressed if you want to get the best out of everybody involved.

Is Mary not getting along with Fred because Fred doesn't know enough about how sane folk work with databases? Is Fred not getting along with Jo because Jo doesn't bathe quite as regularly as they ought? Is Jo not getting along with Mary because Mary is a rude SOB? If so you can almost guarantee that Fred, Jo & Mary are also annoying the rest of the team in similar ways.

Just coz one or two folk push the issue enough to avoid pairing doesn't mean the problems goes away. It may well be annoying other folk too - they may have alternate ways of coping. Like looking for alternate employment for example :-)

If the team doesn't work well together it isn't a team.

Out of curiosity - how long are your pairing sessions and how often do you switch pairs? I find that it's sometimes easier to deal with this sort of thing if folk are switching pairs on a regular basis - once or twice a day. That way everybody gets to share the relative pros and cons of everybody on the team - which can help everybody focus on solving some of the cons.

adrianh
Pairs normally switch after user story is implemented, i.e. in one or two days.
alex
Might be worth changing more often then. Maybe experiment with either smaller stories - or swapping during a story (I tend to like doing the latter myself - spreads the info around more).(sorry about late response - assumed SO would e-mail me about comments on comments :-)
adrianh
A: 

Another approach is to continually switch your pairs within the scrum. Have a timer which might be set for 1/2/3 hours. When the bell goes off, rotate your pairs. This has a few effects:

  • Two people don't get stuck pairing together for a long time
  • Your developers will get to rotate through your current stories, getting familiar with each one and different areas of the code
  • If one of your dev's smells, you will only have to get through a short period of stink!
Burke
A: 

Pairing is a critical practice for an agile team. To begin with, it is best to identify developers that are willing and able to work effectively in pairs. One company I am aware of does extreme interviewing. That is, they will interview candidates in pairs giving them a problem to solve. They are interested if the developers are ability to solve the problem but are interested in their collaboration skills. Only those that can work well with others are considered.

It is not a requirement that all pair like each other. What is important is that they are effective. Given that pairs rotate frequently (for each card or more frequently), personality is less of an issue. If someone is not across pairs, and after being coached is still a problem, he or she should be asked to leave the team.

Cam Wolff