New Early adopter or innovator? InfoQ has been working on some new features for you. Learn more

Article: Successfully Adopting Pair Programming

| by Amr Elssamadisy on Mar 06, 2009. Estimated reading time: less than one minute |
Being "allowed" to pair isn't success. Success is when the team enjoys pairing and they are more productive because of it. If you approach adoption from that point of view you'll have a much greater chance of success.

Jay Fields shares his experience in helping teams adopt pair programming successfully. He covers:

  • Pairing stations
  • Focusing on one team member at a time
  • Pair switching
  • Who should drive
  • Pair mentor/learner model
  • Smells:
    • Uniterested and distracted pair
    • Spell checking pair
  • When not to pair
  • Core pairing hours
  • Simplest thing that could possibly work
  • Code reviews

This article is an insightful look into what it takes to getting from "I think pair programming is a good idea" to "we are pairing regullarly and benifiting from it".

Rate this Article

Adoption Stage

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Nice write-up! by Jonathan Hartley

Hey Jay, a nice write-up, thanks for that. I especially like the important angles of tackling the human issues of constructively getting people on board.

It's interesting to see how some of our practices at Resolver Systems have, after a little experimentation, converged with some of the things you talk about, such as frequency of switching - we all switch pairs every day, a move we were initially sceptical about. We anticipated that it would be too rapid, and would involve too much task switching and getting up to speed on new things every day, but it has actually turned out to be our favoured way of working.

Since we're only a small company, and we're all into pairing, it means we don't need dedicated 'pairing stations' - each of our desks is set up for pairing. We generally just work at whoever's desk is closest. We each choose our own IDE, and have quite a menagerie of them in-house, so generally everyone will also maintain an install of some generic environment which their pair can request to use if they want to. Formerly the lightweight but surprisingly powerful TextPad was a common choice for this, but nowadays we've pretty much got everyone graduated to Vi or somesuch.

A couple of our guys write a script for 'Vi' to toggle between two configurations, so we can toss the keyboard back and forth and still each use our own preferred Vi settings and scripts, etc. Obviously enough though, under such conditions, our settings tend to converge somewhat, as we all steal each other's best ideas.

Like testing, I'm amazed at how many incidental unexpected benefits come out of the pairing activity. Obsoleting code reviews is such a great thing, since it was a dull, life-sapping activity. Also I find that the guilt and blame surrounding ghastly mistakes (slippage or bad design or whatever) are eliminated, because people truly understand how the problems occurred - they were right there shoulder-to-shoulder with you when it happened. All equally culpable, hence forgiving and 'in it together'.

A question on Pair Switching by Henrik Engstrom

Hello Jay,
Great article! I get really inspired to try to introduce this concept in my current shop. Something that bugs me after reading your article is your section on pair switching. I was hoping that you could clarify this a bit - so I have the whole argument arsenal ready when selling the concept to my client :-)

In the my current project we work with SCRUM (or a version of anyway...) and all tasks/requirements are written on stickers put up on the infamous wall. We have a rule that if a requirement is estimated to more than 16h it should be split up into several requirements, hence no task is estimated to more than 16h. But the tasks belong to problem domains and developers tend to become domain experts by implementing all tasks for a domain.

My question, or concern, on pair switching is how you weave this work together with the requirements in your projects? Are you making sure that no task is longer than 8h to enable daily pair switching? Or is one of the developers always working with the whole domain and other partners switch into this domain on a daily basis? Or do you just don't care and just develop as much as you can on one day and then the next pair picks up the work where you left off?

I would very much appreciate if you, or someone else in this forum, could cast some light on how this could be done.

Good article! by Yao Scott


Re: A question on Pair Switching by Joakim Sundén

Hi Henrik,

Joakim Holm has a fun and interesting post on pair switching at

It's in Swedish but he refers to an English paper about "promiscuous pairing":

Joakim Holm will give a talk on pair programming and collaboration in the method track I host at Developer Summit, April 15-17.

Re: A question on Pair Switching by Henrik Engstrom

Cheers Joakim. I will definitely check both of them out.

Re: A question on Pair Switching by Jay Fields

Hello Henrik,
Sorry it took me a few days to get back to you.

I'd handle this in two ways. Firstly, yes, it's much easier to pair switch on a regular basis if the stories are small enough to get done in a few days. If you have to carry a week's worth of context, it's tough to get momentum on delivering a story.

If you can't break the stories down for some reason (try again! =) you can also have 'story owners' who are never away from the story for more than 1 day while it's under development. For example a story owner may be on the team that starts the card and work on it for the first 2 days, then work on something else for a day, then return to the card for another 2 days. A story owner can repeat that process until the card is done. That way, at least one person on the story has context for most of the life of the development on that card.

Thank for the comment and the question.

Cheers, Jay

ping pong pairing by Troy Frever

We follow the red-green-refactor sequence when ping-ponging. Person A writes failing test, B makes the test pass, A refactors, B writes the next test, etc. This gives the nice benefit of never doing two tasks in a row, yet still alternating who writes the next test.

Pair-programming desk by Niclas Nilsson

Here's a link to the (creative commons) blueprints of the specially designed pair-programming desk we created at factor10:

Kind regards
Niclas Nilsson

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

8 Discuss

Login to InfoQ to interact with what matters most to you.

Recover your password...


Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.


More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.


Stay up-to-date

Set up your notifications and dont miss out on content that matters to you