Last updated on | Agile General Knowledge

Agile Pair Programming Everything You Need To Know…

by Luís Gonçalves
pair programming


Some teams I have helped, identified a lack of knowledge on a product as a problem. To tackle this issue, they decided to start with “Agile Pair Programming”.

They never did it, so they asked me for some guidance, where and how to start.

Small intro to a “Pair Programming”

As Rachel and Liz wrote in their book: “Pair programming is two people working together- on the same computer, solving the same problem. Each person plays an active role in creating the software; the person actively typing is known as the driver, and her/his partner is the navigator who looks ahead to consider next steps and potential pitfalls. Pairs swap fluidly between these roles.”

If your team adopts “Pair Programming”, these are some of the advantages that you will benefit from:

  • Code is higher in quality because it is continually reviewed
  • Good practices are shared more widely among the team
  • Developers are interrupted less because people tend not to interrupt people working together
  • More than one developer knows each part of the code
  • Team bonding improves because the team learns from each other and enjoys working together

What should be done during the Pair Programming session?

First, when you are driving, demonstrate that a significant aspect of pair programming is explaining what you are doing and why, so don´t just type the code in silence.

Second, stay open for suggestions from your pair, even if they are novice programmers. Even though you see a very obvious solution, be willing to try the solution that your pair suggests. In any case, both will learn.

If the solution of your pair is wrong, he/she will learn why it is wrong with the help of your explanation. If the solution is good, then you will acquire new aspects with your novice colleague.

Third, one person should not use the keyboard for more than ten minutes at a time. Using ping pong programming can be a good approach. More information about ping pong programming will be found below.

One big mistake that is common in “Agile Pair programming” is the fact that only one person does all the job. A lot of interaction between pairs should be observed. Interactive pairing forces pairs moving keyboard back and forth several times.

In the beginning, agile pair programming can be frustrating. Most of the time it means that developers will slow down to help colleagues, but in the long term, this is a tremendous aid for the team itself.

Ping Pong Technique

To ensure that both members of the pair take turns at the keyboard, teams can use the Ping Pong Programming technique.

I learned this from Rachel’s and Liz’s book – Ping Pong Programming. Below you can find the steps.

  • The first developer writes a failing test and then passes the keyboard to his pair
  • The second developer writes just enough code to make the test pass
  • They then work together to re-factor the code that has just been written
  • Then the cycle can start again with the second person writing a new failing test and handing the keyboard back to the first person.

Coding Dojos

Agile Pair programming is used in “Coding Dojos”. A Coding Dojo is an activity that brings developers together to work on a pre-selected programming challenge.

This is a great way for developers to improve their skills and it´s a great event to encourage learning between developers.

Everything starts with a pre-selection of a coding challenge, which helps people to prepare better for the activity. The dojo runs with two developers working on a pair in front of a computer solving the coding challenge.

This can span different topics. For example, refactoring some part of the code, implementing a new architecture, etc. The PC will be connected to a projector to share their work with the rest of the room/office.

During the development task, developers talk aloud giving an explanation to others about tasks and their solutions. If the room cannot follow what is being said, the developers will explain once again until they understand the approach taken by the pair.

I believe this is an excellent way to help team members sharing the knowledge among each other.

Pair Programming Rotation

Of course, Agile Pair Programming can be used in a regular daily work.  To guarantee pair programming rotation, I like the technique that I learned in Rachel and Liz book.

To be honest, I believe that pair programming is not enough, we need to enable pairs to change within a team. Otherwise, we will end up in a situation where only some pairs know a part of a product.

A trick is to work with the team to design a “big visible chart” to increase a visibility of what they want to track; in this case, partners with whom they paired. This makes it easy for the team to see whether they are improving or not.

In this case, the team can use a pairing ladder to show who is paired with whom and how often. Below you can find an example of this pairing ladder.

agile pair programming

This was a short post to give you some ideas how can you enable/track pair rotation within your team.


We have developed a free assessment in the form of a Scorecard to help you establish which areas of business you need to focus on to achieve your particular Organisational Mastery.

Take The Test

If you liked this article, feel free to visit my company Products and Services pages.

We provide Team CoachingAgile Training, and Agile ConsultingOKR TrainingOKR ConsultingInnovation Training and Innovation Consulting.

With my team, I built 5 main products: High Performing TeamsScrum Team CoachScrum Master MentoringOrganisational Mastery and the External Business Accelerator.

Rate this post:
Luís Gonçalves

About Luís Gonçalves

Luis Gonçalves is an Entrepreneur, Author & International Keynote Speaker that works exclusively with Senior Executives of 7 to 8 figure businesses on the deployment of his game changing ‘Organisational Mastery’ Methodology.


Share your point of view

  1. From my experience pair programming can be very rewarding or very annoying. One practice we’ve tried in the past more or less successfully was the ping-pong programming that you mentioned. It works really well with test-driven development. You start with a broken test case, pass the keyboard to the pair. The pair fixes the test case and writes next test case for you to fix, and so on.
    One of the challenges we’re facing now is that our entire office is brand new, so we have nobody who knows the platform really well. It would be nice to work in pairs with experienced developers from other locations but I’m not sure if it’s possible considering the remoteness and time differences.