Delivery benefits through pair programming

I’ve been in many situations over the years debating the value of Pair Programming, so I thought I’d share my experiences and views on the subject.

For those of you unaware of what Pairing Programming is, or more simply, Pairing, here’s an overview.

Overview

As an established agile software development practice, essentially it involves two people within a development team working together to deliver a task. Let’s say Scrum is being practiced, and a User Story is being pick up within the Sprint. The pair (either decided in an ad-hoc manner or using a Pairing Matrix/Ladder) progress the work together. It usually involves taking on a Driver or Observer/Navigator role. The Driver authors the code and the Observer/Navigator inspects each line of code written, with role reversal occurring often. A healthy pair would typically be in constant dialog, discussing their approach, whilst considering their partner’s opinions and alternative options.

Approach

The Driver and Observer/Navigator roles are performed during the pairing activity. Here is an example of the duties each role should undertake.

Driver duties:

• Implements the next task that the navigator provides.
• Gives future tasks to the navigator to track.
• Answers navigator’s questions.

Observer/Navigator duties:

• Keeps track of the big picture.
• Responsible for directing the flow of work to a specific conclusion.
• Reviews code.
• Keeps track of tasks identified by the driver so they can focus on coding.
• Ensures that best practices are followed.
• Track potential code improvements.
• Asks questions about the driver’s implementation.

Other approaches worth mentioning:

• Master and apprentice, e.g. senior and junior dev – offering a great opportunity for training on the job.
• Cross-discipline, e.g. QA engineer/tester and developer – particularly of value when embarking on a new User Story and taking a Test-First approach, whereby the test scripts are created ahead or in conjunction of the code.
• Remote pairing, not ideal as we know co-location face-to-face collaboration is the most effective way of delivering, however it is unavoidable at times. There are some great tools out there to make remote pairing frictionless (check out an article on slant.co, comparing some of the best tools out there).  I strongly advocate video calling in conjunction with a remote pairing tool.

Watch out for, and be careful not to become a, command and control pair member.  Falling into a command and control style may require some coaching or self-discipline to prevent one running ahead without taking your pair along for the ride. Frequent role reversal essential, along with a specific retrospective on the experience.

Benefits

Here is a list of benefits that isn’t exhaustive and not in any particular order but should be considered if you’re deliberating pairing.

Benefits for the project:

• Faster and focused delivery.
• Resilience, in terms of knowledge.
• Fewer lines of code.
• Easier maintainability.
• Fewer defects, shorter and less expensive testing.
• Reduced need for code review.
• Improved quality.
• Better emergent design.

Benefits for individuals and the team:

• Collaborative development.
• Knowledge sharing.
• Education, new skill learning opportunity.
• Personal development.
• Two heads are better than one.
• Team building.
• Increased enjoyment on the project.

Aren’t we doubling the man-hours?

If you’re still considering putting two resources on a task a major drawback, please take another look at the benefits.  Look beyond the short-term, and let me reiterate a few important points:

1. solutions typically get developed quicker;
2. are of higher quality;
3. and fewer defects typically result.

The latter being particularly significant, as defects can dramatically slow down delivery, especially if found beyond the next task being picked up. The delivery impact of defects can be compounded if there is poor maturity with other practices such as: Test-Driven Development (TDD); Behavioural-Driven Development (BDD); Continuous Integration (CI); and Continuous Delivery (CD).

Pairing Station

A word or two on practicalities.  In an ideal world, a Scrum team’s working environment is configured in a bullpen arrangement with a series of Pairing Stations, with identical builds of the Operating System, Integrated Development Environment, and any other necessary tools.  Of course, not everyone has that luxury.  The minimum to effectively benefit from the practice would be one or two large monitors, a workstation, two keyboards and two mice. Screens should be mirrored, if you have two.  You could even go one step further by giving a stand-up pairing station a go, it might surprise you!

Pairing Matrix/Ladder

A pairing matrix, or ladder, can be used to keep tally of who has paired and to help identify where there may be opportunities and gaps.  The matrix should be visible and close to your physical sprint task board, which I advocate using, in conjunction with a digital tool.

The use of a pairing matrix can also be gamified through the introduction of some form of leader board to help encourage the practice and make it more fun.

Pair Rotation

There are a few options as to the strategy employed for rotating individuals within a pair:

1. On a scheduled basis: every half day, daily, at each sprint
2. For the duration of the User Story
3. For the duration of a Task

There’s pros and cons with each, and it depends on your wider goals.  I have seen and heard from teams practicing pairing, as a norm, that their preference tends to be for at least the duration of a task or tasks to complete a User Story.  Enabling continuity and for a natural conclusion to occur.

Boomerang Rotation

Yes, boomerang rotation is a serious practice, and one that I’ve seen produce invaluable benefits for a task. In a nutshell, it involves pairing with a member from another team for an agreed period of time (i.e. days, sprints, or delivery phase of sprints).  Rotating members across Scrum teams encourages more open communication and fosters new ideas and perspectives. Another benefit of boomerang rotation was demonstrated when we invited an outside consumer to join us and assist in producing a suite of APIs to empower flexibility with a UI component they were building. The experience provided a unique insight and improved the efficiency of the required changes and consumption of the APIs by the client team.

Final Thoughts

Pair programming isn’t necessarily for everyone, but don’t knock it ’til you’ve tried it.  It’s process provides many critical benefits to team members and the project that undeniably outweigh its costs. If, however, you don’t have adequate sized teams, I’d strongly recommend Peer Review in your process to deliver high-quality software through alternative means.

It’s a great way to strengthen a sense of team and encourage collaborative agile software development.

Further reading

• Agile software development
• 7 ways to Win with Pair Programming, Byron Sommardahl
• Effective Pair Programming Practice- An Experimental Study, CIS Journal
• Pair Programming, Wikipedia
• A Study in Pair Programming, Eric Schwartz