Get certified - Transform your world of work today

Close

Pair Programming

15 September 2015


Many eXtreme Programming (XP) practices, such as test-driven development, continuous integration, and collective ownership, are used by Agile teams.

Pair programming is probably the most famous practice of XP -- whether you are a fan or not. It reminds me of the Marmite food spread: You either love it or hate it. Well, I love Marmite, and I love pair programming and all its outcomes. Pair programming is the practice of two developers sharing the same workstation to get work done. One developer is the driver and the other one is the navigator. Usually the driver is responsible for writing the code, while the navigator is "leading the way" and reviewing the code. For effective pair programming, you have to switch the roles multiple times per day. During a single day, you will have the chance to be the driver for a couple of hours and the navigator for the rest of the time.

You can configure your workstation in one of the following four ways:
  1. One monitor and one keyboard. My least favorite.
  2. One monitor and two keyboards. A little bit more decent that the scenario above.
  3. Two monitors and one keyboard. More comfortable because you have two monitors (and you don't need to be on top of your colleague).
  4. Two monitors and two keyboards. The best configuration because you are comfortable, and you have your own keyboard.
If you use two monitors, consider cloning or mirroring the monitors so that both screens display the exact same thing.

When should you pair? I believe that you should pair all the time. The decision to pair shouldn't be based on the type, length, or size of the work to be done. Just pair all the time, and it is one less decision that you need to make during your day.

To be effective, you should also rotate your pair twice a week. This means that the person who joins you on Monday to start work moves to another pair on Wednesday so that you have a new colleague to work with. You can even have a "pair rotation ladder" to keep track of the pairs and patterns in your teams.
 

Pair programming benefits

The benefits of pair programming are many:
  • Collective code ownership. You'll have at least two persons working on the same code (and with pair rotation, probably even more).
  • Increased "bus factor" for your team. The bus factor is the number of developers you would need to lose before the loss slows down or blocks your team. The higher the bus factor, the better. It helps spread the knowledge across the team.
  • Fosters "beginner's" mind. When a new pair is formed, there will be a lot of questions and answers.
  • Engagement or commitment. Nobody wants to let the other partner down.
  • Valuable stand-ups. Everybody pays more attention to the feedback given by other pairs because of the pair rotation and the probability of joining that pair in a couple of days.
  • Better integration of new team members. It is much easier and quicker to get up to speed by deep-diving directly in the codebase (as a pair) than by reading documentation or manuals on your own.
  • Limited work in progress (WIP). You will have half of the work streams.
  • No code reviews. In my opinion, pairing is coding and reviews on the go. Therefore, additional code reviews are a little bit of overkill (except if the code reviews are with members outside the team).
  • Fewer code defects. Many studies have proven this (e.g., Cockburn and Williams in 2000, Begel and Nagappan in 2008).
  • More fun. It is actually fun to work closely with another colleague.
  • Fewer distractions. You can't check social media websites, such as Facebook or Twitter, while you are pairing.
  • Fewer interruptions. When a manager asks a developer questions, this does not only interrupt his or her work but the work of the pair.
  • Less slacking. Hopefully, between two brains, the right thing (e.g., documentation, testing, coding standards, etc.) will be done.
  • A broader comfort zone. The combined comfort zones and the skill sets of two developers will be bigger.
And remember that two heads think better than one. You will have better ideas and stay "in the zone" longer. You will also have more courage to assign yourself to risky or uncomfortable tasks, generating the opportunity to learn and to teach.
 

Characteristics of a good pair programming partner

You probably have already noticed that with pair programming, developers will need to change (some of) their daily habits because they don't have the chance to listen to music or take a break navigating on their favorite social network. So the question now is: Is pair programming for everyone? No, it is not. You need to:
  • Be willing to give it a try.
  • Be social.
  • Be confident.
  • Embrace your partner's feedback.
  • Manage conflict.
  • Accept differences (not everything will be as you you want it to be).
Pair programming can be quite exhausting, so it is not just rainbows and unicorns. You will obviously have a learning curve ahead of you. That is why I don't believe pair programming should be imposed; it should be highly recommended. Decide whether you rather pair or undergo code reviews. The decision is yours (and your team's).
 

Managing personalities

When you are pairing, you will encounter different personalities (you will find all of these no matter the team) that you must manage diplomatically:
  • The rock star: This person is a prima donna who thinks he or she is a tech guru.
  • The grump: This person is always in a bad mood.
  • The badass: This person makes you do as he tells you (probably related to Chuck Norris).
  • Your arch enemy: This person on the team is the one you dislike the most.
  • Your soul mate: You finish each other's lines of code.
  • The CVDD guy: This person is always pushing you to go for bleeding-edge stuff to bolster his or her curriculum vitae.
  • The senior: This is someone from whom you can learn a lot.
  • The junior: This is someone you can teach, coach, or mentor regularly.
  • The newbie: This is someone you need to bring up to speed and who will make you reexamine past decisions and reasoning.


Pair programming FAQs

Below are questions that I am frequently asked, and I would like to share the answers with you:

Q. Can you pair with a remote team member?
A. Yes, it works fine. Nowadays you have many tools that help you communicate and collaborate with remote team members.

Q. Are estimations affected?
A. If you are using points, no. If you are using days, yes (you should use pair days).

Q. Is it expensive?
A. Nonbelievers think that you are paying double for the same amount of work, but what is the cost of defects, technical debt, or a low bus factor? Don't forget that pairing is good for boosting team spirit and morale, and it helps to limit the WIP. So I believe that it won't be expensive in the mid to long term.

Q. Is it only for mature teams?
A. No, not really. Any team can do pair programming.

Q. Does it scale?
A. It scales fine. You can have all your teams doing it, and you can rotate (from time to time) pairs between teams. In one of my previous jobs, we called it a "boomerang" because the pair would be assigned to a different team but would return later.

It's important to note that there are (quite a few) notable companies implementing pair programming successfully. You also have many noteworthy "scholars" and hands-on fans. If you are keen on the idea of adopting pair programming, you should probably ask yourself how you can start using it. You have two possible scenarios:
  • Gradual: Pair just a couple of days a week, pairing only one team or having only one pair inside your team.
  • Accelerated: All developers are pairing in all your teams.
No matter which scenario you choose, I truly believe that you should give pair programming a fair chance, because it is an XP practice that has beneficial outcomes, as described earlier. One thing I can assure you, nothing bad will happen to you if you try. Just give it a shot!
 

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 4.3 (6 ratings)

Comments

Kapil Goel, CSP,CSM, 9/15/2015 12:34:07 PM
Excellent article, coming from the direct heart and will real time experience..... This is what i was looking for.
Pedro Gustavo Torres, CSP,CSD,CSM,CSPO, 9/16/2015 9:27:02 AM
Hi Kapil,

Thank you so much for your feedback. I really appreciate it.

I'm glad you enjoyed to read the article as much as I enjoyed to write it.


Cheers,
Pedro
Kapil Goel, CSP,CSM, 9/16/2015 10:56:26 PM
Thanks Pedro.
Just curious to know on scenarios like - When a high performer, who has been doing pair programming for many years and happy about it, what happens when such person joins another organization where "NO PAIRING" culture.

My 2 cents here - Backward compatibility should be easy here, with no issues.

What is your opinion in this scenario?

Regards,
Kapil
Pedro Gustavo Torres, CSP,CSD,CSM,CSPO, 9/17/2015 6:27:34 AM
Hi Kapil,

I believe that someone that is experienced and happy with pair programming could feel a little bit demotivated to work in a "no pairing" culture.

I think it should be something that should be discussed with the developer (from time to time) to make sure that he is dealing with this situation in the best positive way.


Cheers,
Pedro
Kapil Goel, CSP,CSM, 9/17/2015 11:31:52 PM
Thanks for sharing your views Pedro.

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.

 

Newsletter Sign-Up

Subscribe