I have noticed a significant difference in the results achieved by teams with pairing depending on how they approach learning to pair.
In particular, many people don’t expect pairing, itself, to be a skill. They don’t realize that they’re going to have to learn new ways to think, to problem solve, to be creative, to filter their perceptions, and even to converse. Since they don’t realize this, they get surprised. And then they set themselves up to make that learning hard, and quit when they get poor results and find pairing to be hard while learning.
This is not true of all people who have trouble with pairing, but it is pretty common.
The skills to lean are entirely subconscious and mostly communication skills. I find it similar to learning a foreign language. One needs to achieve a level of basic fluency before anything works; before then, it’s all frustrating and inefficient.
But Does It Work?
As a single point of evidence, I have taught around 200 people to pair program, and have introduced it to about 500 others (given them a first sample, but not followed up with them). For each of the 200 people, we agreed that this was an experiment.
We agreed to pair program in order to learn how to pair and to get a good understanding of what all the light and thunder were about. The team could, thereafter, decide whether it wanted to pair on an ongoing basis. Unless the team actively decided to start pairing, it would revert to its normal / previous work practice.
Among these 200 or so people, the expectations were distributed reasonably typically. About 2/3 of the people identified themselves as introverts. Nearly all of the introverts were pretty sure that pairing wouldn’t work for them, for all the reasons stated in this article. Among the extroverts, about 1 in 4 were also sure that pairing wouldn’t work. This was commonly stated as being due to wildly different skill levels in the team.
In the final tally, exactly 2 people decided that pair programming didn’t work as well for them as solo programming did. The remainder became lifelong converts. Over 80% stated that they would intentionally select for teams that paired in the future as one of their primary considerations (usually above what product the team created or technology it used). About 40% stated that they would never again work on a team that used solo programming.
Of the 2 who found pairing harmful, one had diagnosed ADHD and sensory overload. She stated that she found pair programming emotionally painful and exhausting. She needed recovery time each day just to deal with the sensory overload. Yet she still voted that the team take up pair programming for 100% of its work because “it has had such tremendous effects on the effectiveness of everyone else on the team, and even for me it has significantly improved the rate at which I learn.” [paraphrased]
So yes, there is a chance that you, personally, will not be a match for pairing. There’s even a chance that your team won’t (haven’t found one of those yet; but perhaps it exists). But the odds are pretty low.
How Should We Learn Then?
If pairing isn’t working, I would posit that the most likely reason is that the team isn’t aware of the difficulty of learning the skills involved. It likely isn’t accounting for these difficulties.
In my experience, nearly every individual goes through the same progression in learning the key skills to a basic level, and it takes about the same amount of time. If the team pairs 100% of the time on 100% of the code and chooses new random partners at lunch and at morning, then it takes about 2-3 weeks to get break-even and start seeing the first real benefits.
These weeks play out as follows:
- First 1-2 days: see awesome benefits of increased collaboration and rate of learning. Wow!
- End of first week: exhaustion. Can no longer think. Background noise is constant distraction and partner keeps interrupting my train of thought. I hate pairing. It is useless and painful.
- All of week 2: same.
- Near end of week 2: costs have actually dropped. Complaints are still there, but lesser. People are starting to develop subconscious filters. But it still hurts.
- Sometime during week 3: first pay-off happens. Some huge bug is found easily. Someone notices a new idea spread around the team almost instantly, without a meeting. The team agrees to start or stop using some tool without taking a meeting. Wow! And then people realize they’ve already learned how to think in a pair. Not perfectly, but to the point that they are doing better than before pairing. Decide to keep going.
- Week 4: multiple wins. Costs continue to drop. Productivity starts climbing quickly. Wow! Lifelong convert.
- Month 6: well, there are more patterns after the first 4 weeks, but we don’t need to go into those here.
What if I just pair for half the day?
I am unsure how long it would take to learn with a part-time commitment. I would expect it to be a much larger number of hours – in much the same way as it takes years to achieve basic fluency in a foreign language via classroom instruction 4 hours per week, but only a couple of weeks in immersion with a coach.
Part of the reason that I have a very high success rate is that I approach a pairing experiment like I would approach teaching a foreign language. I make clear some of the skills that people will need to learn, how hard it will be, and how long it will take. I also make clear that it is optional and that, even if one successfully learns French, that doesn’t mean that one need to move to France.
The requirements that I place on a team wanting to learn:
- The whole team must commit to the experiment. No partial teams. (I am considering relaxing this one, but it will have negative consequences to do so.)
- The team must commit to the experiment for at least 3, and preferably 4, weeks.
- The team agrees that this is an experiment for the purpose of learning. It will not result in a change in how the team does its work. However, after the team has learned the new language, it may then decide whether to move to the new practice.
- The team understands that it will be learning the following skills:
- How to avoid “paragraphing” when talking. Learning to speak in half-sentences, leaving room for the other to take the idea in an unexpected direction.
- How to talk about unformed ideas safely. To not assume that someone actually believes the idea that they are stating – it may not be that well-formed yet. Basically, accept a low signal to noise ratio in both what you say and what you hear.
- To establish subconscious filters. People learn to not consciously perceive the conversations around them, but still process them subconsciously. As a result, they do not hear the conversations of other pairs until keywords get mentioned, at which point the subconscious back-fills the last 15 seconds of conversation.
- How to do collaborative creativity.
- How to do collaborative research (e.g., doc reading).
- How to do collaborative analysis & deep thinking.
Once everyone on the team is minimally fluent at those skills at a basic level, then the team members can get into a pair flow mind-state. And then the learning and effective production really kick in. But the people do have to get that fluency first.