Exploring Five Pair Programming Techniques
Blog: Agile Adoption Roadmap
A collaboration by Antonio González Sanchis and Mario Moreira
Extreme Programming (XP) introduced a programming technique that’s been famous since its early days: pair programming. It sounds simple, two people working together with the same computer. However, what people don’t know is that there are many ways in which you can approach this technique. Let’s explore a few:
Driver-navigator:This is the best known style of pairing. It consists of one person ‘driving’, taking the keyboard and coding or doing the work, while the other one is ‘navigating’. The Navigator’s job is to pay attention to the work being done by the driver while keeping the big picture in mind. They should guide the driver in the right direction. It is very important that driver explains every decision they make, otherwise the navigator might lose interest and may stop paying attention. It’s healthy to switch roles every now and then.
Ping-pong: For this approach you might need two keyboards connected to the same computer. In contrast to the driver-navigator mode, in ping-pong both people can be driving at any point in time. A good strategy for this approach is to have one person writing the tests while the other one tries to pass them. As in the previous approach, you should be switching roles often.
Backseat navigator: A typical approach when there’s a new team member in the group or a junior colleague. The navigator (usually the more senior team member) tells the driver, who has the keyboard, what to do to solve a problem with every little detail. The navigator should provide insights on how to solve the problem but also on why that’s the best solution in mind. It’s a good way to ramp up new members in your team as they build relationships with other people in the team while learning about the working style.
Tour:If there is an even number of team members or someone who you used to pair with went on holidays, you are not going to stop working. However, when those people return or you start pairing with someone, you don’t want them to start right away. Therefore, a good way to start would be to do a ‘tour’ through the code or work you did in their absence. The person who doesn’t know the most about the work takes the keyboard and the mouse and starts driving through the code while the ‘expert’ acts as a navigator and explains every detail.
Distributed pairing: Often people tend to think pairing is for collocated teams but that’s not entirely true. While pairing face-to-face is definitely much more effective than remotely, there are many tools and ways colleagues can pair. A good suggestion would be to use a videoconference messaging tool with a screen sharing app that allows the navigator to see in real time what the driver is doing.
These are not the only pairing styles that you might encounter but they are the best known. They are also the easier techniques to try when you want to start pair programming. Also, examples seem to focus on software development but pairing is applicable to almost every field. For example if you are in marketing and are launching an email campaign, you can pair with someone to navigate through the email while you write it, etc.
There might be anti-patterns when pairing. For example, you might find cases when the navigator is ‘sleeping’. This means the navigator can be checking emails, texting or even coding in parallel without paying much attention to the driver. Try to identify the root causes of this behaviour before you jump in into action. Usually it might be because the driver is not explaining properly the reasons why he is doing a specific task in a particular way.
Lastly, keep in mind that while pair programming may work in every role or department, it might not be suitable for every work. There will be times when you just want to discuss the approach with the team and go do it by yourself. That’s also a way of getting feedback, which in the end is the main purpose of pair programming: getting feedback early.
If you are interested in trying pair programming, the first thing to do is review the list of possible techniques (above) and select one that you will experiment with. Then identify your pair. Brainstorm on how you might approach pair programming, specify how long you will try your experiment, and begin.
————
Learn more about Antonio González Sanchis at https://www.linkedin.com/in/antoniogonzalezsanchis/
Read more of Mario’s article at: http://cmforagile.blogspot.com
Leave a Comment
You must be logged in to post a comment.
