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.
Great ideas and good to see how the learning curve of pairing unfolds from your experiences.
Thank you.
Good observation penned eloquently. Appreciations and I agree to your findings 🙂
Does the level of experience of the people new to pairing make a difference?
I have not found much difference due to experience as developers. I have found significant differences due to prior experience in shared spaces or pairing.
The only noticable difference that I've seen due to experience is a slight anti-correlation between "senior dev" and "willing to learn something new." This is by no means universal. But I run into fewer senior devs that are willing to try something and see whether it works than I do junior devs. That whole status thing gets in some peoples' way.
I will never do pair programming: I am the lone ranger !
(anybody still knows who is the "lone ranger" ? )
How would you recommend applying this idea to teams with members geographically spread out? Would you expect pair video conferencing to work or does physical presence make the difference?
People do pair distributed. It can work. However, it doesn't work well for learning to pair. Experiment in person, then learn in person. Once you're fluent then try over the phone.
Again, it's like a language. Once you know Korean, you can speak it over the phone. But would you prefer to learn it over the phone or by immersion?
Also, I'm still against distributed. I've seen some good data (from Ambler, I think?) that orders teams by effectiveness. Most effective are agile co-located teams. Next are traditional co-located teams. Then a big gap. Then agile distributed teams, then traditional distributed teams.
So if you're thinking of being distributed, recognize that that one choice will overwhelm all other productivity gains you might make, forcing you into the lower level of effectiveness.
And if you are distributed traditional and thinking about how to get better, look at the cost and effort of becoming top-notch at the entire XP practice, vs. the cost (political and cash) of co-locating. The co-locating will give you a greater return, so if cost is similar…
Arlo, the 99% success rate that you quote seems high – as it would seem for any innovation (not just pairing). What data do you have to distinguish people who said "I'm a convert" around week 4, from people who are still pairing years later?
Secondly, out of all the teams you have offered to teach, approximately what percentage have excluded themselves from your dataset, simply by violating your rule that all members must be willing? (E.g. were there another 500 people who you offered to teach, but couldn't, because some of their teammates were unwilling to try)
Finally, from your experience, do you have any comment on the concerns raised by this study: http://www.sciencedirect.com/science/article/pii/… (particularly that the benefit of pairing is greatly influenced by task complexity – and not necessarily in the way one might expect).
It does seem high. And is. But it's the results that I've seen.
I've followed up with about 1/3 of these people over the years since then. above 90% of those I've followed up with are still pairing regularly. Most of the rest are on teams that don't pair and are trying to get the team to start pairing. I can't think of any of them who have stopped pairing (though I might be forgetting someone). I don't know what the continuation rate is among the ones that I didn't run into or keep up with later. And there may be selection bias; people I run into are likely active in agile circles and are also likely the ones going to events.
There are several people who have excluded themselves from my data set by being on a team that didn't want to try the experiment. But that doesn't alter the success rate. There is no reason to believe that those individuals would have a lower success rate than the ones that I did work with.
There is reason to believe that their teammates who actively resist even experimenting with pairing will have a lower success rate. But I honestly don't care much about those individuals; people who aren't willing to give something an honest try and see whether it works will never be a part of a great team. I don't require that people like pairing (or anything else) in order to respect them. But I do require that when they see a tool, practice, library, or whatever else that may help – and has lots of evidence that suggests it does – they at least give it an honest try.
I'll comment on the study in my next reply to this comment.
I make no assessment about the accuracy of that study; I have not analyzed it. However, I have found that few studies on pairing actually match my experiences or those of others I've talked with. For example, many of the studies are done in an academic setting with students. That is a very different group from a work environment, even when the work group is 60% new college hires. In order to trust the meta-analysis, I would require that they have excluded non-applicable studies like these.
I think it is also worth noting that few of these studies look at the most important outcome of pairing. Teams that pair, especially in a shared space, simply learn faster. They exchange information faster. And this lets them make use of more ideas. It also means that teams that have been pairing for a year are simply more skilled at their craft than teams that have been soloing for a year. This results, eventually, in improvements in productivity. More importantly, it results in improvements in flexibility. Teams that pair tend to become more and more willing to try things and see whether they work. So they spend some time on things that don't pan out, but they also get to take advantage of the things that do.
The real difficulty with any study on pairing is that pairing is a long-term win. The point is that it changes the way that you listen, think, and communicate. And this mental shift takes a while. To be legitimate, any study has to compare a team that has been using pairing for a long time (I'd do at least 3 months of 100% with shared space, or at least a year of 50% or without a shared space) with a team that has never paired but has been working together in an otherwise similar manner for a similar amount of time. It's really hard to get study participants that meet these parameters.
But without meeting these parameters, the study is fundamentally examinging something very different from the pairing that is actually happening on real teams in the real world. They're looking for their glasses under the streetlight rather than in the dark where they dropped them (to abuse a joke).
Thanks for the detailed and thoughtful response(s). Can you point me in the direction of any good descriptions (or better, videoed examples) of those changes in the way you "listen, think, and communicate"?
Hm. No direct citations, but perhaps some places to look.
I was at a good talk a couple years back at Agile 200x (don't remember which year). It was given by some people from Menlo Innovations. They talked about the typical first year of programming – how it felt, what people learned, and how people thought.
What city are you in? There is likely an experienced XP team running in your town. Members of such teams pretty much all pair 100% of the time and are happy to talk about it.
Finally, I'll try to provide such a description from my own experience.
You are changing from thinking within your own skull to thinking in the communal airspace. This means that you significantly increase the noise to signal ratio. You stop filtering what you say and stop checking for correctness. You expect others to do the same. The entire conversation shifts to incorporate a lot more zany ideas and flights of fancy – when then get trimmed out if they don't result in a good idea.
If you are pairing in a shared space, then you will learn to subconsciously filter the background burble of conversation. It's the same skill that lets you overhear your name in a crowded party while otherwise not hearing the background conversations. Only you get the same effect for temporary keywords – stuff that you just worked on, things you're curious about, etc.
I found that I also shifted from thinking by concentrating to thinkin by bouncing along associations. Others have reported the same, though I doubt that this is universal. I used to get very attached to my idea and explore things in a depth-first fashion. With pairing, I remain far less attached to any particular solution and explore in a breadth-first with trimming fashion.
Each of these changes takes time. Again, I found it a lot like when I was learning German. I had good classroom instruction (but no immersion), so started thinkng in German sporadically after a few months. At some points I was stuck between the languages – I had thoughts that were partly German and partly English, but my brain was still language-modal. Eventually I learned to think entirely in German.
And then I stopped speaking German. 15 years later my vocabulary is crap, but I still speak it ideomatically (good grammar and with an accent that most Germans place as "somewhere in Bavaria"). The parallels apply here as well. Once you become fluent at pairing, it will alter your non-pairing interactions. Others who pair fluently will likely be able to tell.
Interesting, thanks. The breadth-first solution search sounds beneficial.
Regarding "thinking in the communal airspace". (Great phrase, by the way 🙂 Perhaps that's the part of pairing I have the most difficulty in imagining. You mentioned "zany ideas and flights of fancy". I feel I have lots of changes of direction going on in my own thinking already. Slowing them down from "the speed of thought" to the "speed of speech", and integrating them with an equally numerous number of thoughts from a partner… it all seems difficult and time-consuming.
Some time ago I attempted to blog my "internal monologue" for a software design episode. Details are here if you're interested http://www.agilekiwi.com/other/news/conversation-…
I can't imagine the same thing being re-created in the form of actual spoken dialogue between two people. But perhaps that's not what pairing is about. Perhaps the kind of stream of consciousness in my example doesn't exist in pairing, and it's replaced by something else… Again, I'd be very interested to hear your thoughts on that if you have time.
PS I'm in Wellington, NZ. Scrum is very popular but we don't seem to have many XP teams here. I do know of one – I was a member of it for about 4 months. It was a long time ago now. In hindsight I wish we'd thought and researched more about what we wanted pairing to be like, and how to make it work well. As it was, I don't think we got much value out of pairing.
PPS I also attempted to blog about the perceived difficulty in moving from unspoken to spoken thought here http://www.agilekiwi.com/other/agile/expertise-me… and here http://www.agilekiwi.com/other/agile/pair-program… Again, I'd be very interested in your thoughts if you have time to read.
Thinking in the communal airspace is the part that takes the most of a mental shift. That's the bit that is just like learning a language. And, like learning a language, you can't really concieve of thinking in that language until you think in that language. It's also really hard to describe how thinking in, say, German can be just as effecient and effective as thinking in English, unless I am describing it to someone else who already speaks fluently in both languages.
Good pairing, in my experience, does result in a stream of consciousness much like you describe. People learn to speak partial thoughts; they speak in phrases and shorthand instead of paragraphs. A transcript of a pair session is often unintelligible to those without that team's context.
When I get into pair flow with someone (takes about 15 seconds if the other person has at least 3 months of pairing immersion experience and I've worked with them for at least 15 minutes before), we finish each other's sentences around 5-10 times per minute. We also leave half-sentences unfinished around twice as often. Many of these partial sentences transfered some interesting partial thought, whih gets changed and spat back. So many sentences get redirected before they get finished.
Once in a while, my pairing conversation hits a block. There's some concept that only one of us understands. So we have to stop and let one person paragraph for a minute or so to move the concept. I hope to get back to phrasing quickly though: paragraphing is inefficient and slows down the thinking.
This is simply a different style of conversation. It is more comon among women than among men, and among teens than among adults. Learning it takes time and effort, but using it is no more (or less) difficult and time consumig than any other method of thinking. It is a semi-externalized creation process where you allow your ideas to be constantly bumped around by your partner.
XP teams are outnumbered by Scrum teams almost everywhere. XP is far more demanding, the coaches are fewer, and the branding / marketing are much less. However, XP teams also tend to be much higher discipline (not always), pay more attention to the technical and learning practices, produce better code, and pair.
Which is why I suggested you look for one. Shame that you've already tried the only one in your area and they didn't do pairing well. it can be a tricky practice to get right – not because it's hard, but because it is one of the most weird-sounding / invasive practices.
When people first try TDD, they fail. And they assume that the failing was that they didn't understand TDD well enough, so they get more info and try again.
When people first try pairing, they fail. And they assume that the failing was fundamental to the practice so they stop doing it.
And that's, really, the only thing that makes pairing hard for teams to adopt. That's why having a coach who has done it before can help so much.
Everything else, for either practice, is skill learning. Each causes some painful adjustments in how you think and how you work. Pairing has more significant impacts on your thinking, so more intense a period of confusion. But that is just a matter of degree. In either case, you are starting down a road of skill improvement and it takes a while to learn. The only hard part is identifying when the practice won't work in your context (very rarely) and when you simply have not yet learned to do it well (most of the time).
I would hardly call pair programming innovative. Most other fields consider it common sense.
Great post! Your findings show that pairing isn't an easy skill for a team adopt. It requires patience and perseverance. I posted my thoughts on pairing a while back. No where near as considered, just gut feelings on how the Dreyfus model and Lencioni's dysfunctions could be applicable. Would be interested in your thoughts… http://chrisvmcd.posterous.com/the-dysfunctions-o…
Pairing is not actually a very difficult skill for a team to adopt. But it always requires effort on behalf of the individuals.
The probability of success and the amount of time / cost it takes to learn is completely under the team's control. The team can choose for a moderate cost over a long time with a low success rate. Or it can choose to pay hard for a week, then have two weeks of low cost, and have a high success rate. The latter is cheap. And the only difference is how the team chooses to adopt the practice.
Pairing it isn't a difficult practice for the team to adopt. The probability of success is high and all success factors are under the team's control. The only significant cost is political – both inside and outside the team. It can be hard for one person to ask the entire team to change its ways of working. But once the whole team sees the advantage and decides to really try pairing, it is pretty easy to succeed.
Of course, the costs to individuals in those first two weeks are high. So it is "expensive" for the individuals on the team. It requires learning. It requires patience and perserverance – but only for 3-4 weeks.
The key insight is that you can choose your destiny. It can be as hard as you want it to be. But it can also be relatively easy.
I paid my 3 weeks about 12 years ago. I've been reaping the benefits every week since then. I've got a teammate who finished paying his 3 weeks last week. He's now learning a lot faster than he was a month ago. It'll be about another two weeks before he achieves break-even on productivity.
What are your thoughts on people learning to program starting out in pairs?
I highly recommend it. It (tends to) makes the learning easier and more fun.
Of course, that's for kids. Adults sometimes have hang-ups that get in the way. But for kids? Pairing makes it more game-like. And having fun enhances learning.
There's a reason that Llewellyn and Lynn's teachingkidsprogramming.org teaches exclusively in pairs from moment 1.
I tried pair programming once and absolutely loved it. In one afternoon we refactored a chunk of code which would have taken either one of us a few days. I liken it to wearing a sock with a randomly distributed large hole which prevents you from being comfortable. If you take two such socks, the probability of coverage goes way up. And this is exactly what happened when we tried this. My pairing partner covered my weaknesses and I covered his. As a result, neither of us wasted hours being stuck and frustrated on something.
To further understand, I have a few qvestions:
1) What, exactly is "paragraphing" and why is it bad? And can you give examples of paragraphing?
2) Can you give (perhaps conjured, but plausible) examples of "half-sentences" which then converted to something useful by a pairing partner?
Thank you, Jay
I'm referring to the chunk size of a conversation. How much do you express before you intentionally stop speaking and let your partner take the conversation in a new direction.
Many people speak in stories or paragraphs. They try to convey a complete idea. Each of their thoughts is finished and fully expressed. This is great for cocktail parties. It's crap for pairing.
In pairing, the point is to riff off of each other's unfinished ideas. That requires that the ideas be expressed in an unfinished state. The best way I've found to do that is to express only part of one sentence. Say the most important / obvious part, and let the other person then speak (you may have to wait a while, if their conversational pause length is longer than yours). Welcome them taking the sentence in a direction other than you intended.
The purpose of conversation in pairing is to build. It isn't to be heard. It isn't to be understood. It isn't to get your idea out. The purpose is to co-create a new idea between you.