A reader asks for advice as his team gets started with pair programming.

Pairing can be fun, cost-effective, and risk-reductive. These benefits come with skilled practice. The needed skills can, of course, be learned. Here are my suggestions for a team new to pair programming.

1. Conserve energy

Programming solo is tiring in familiar ways. Programming in pairs is tiring in unfamiliar ways. When starting out, limit your pairing to 2 hours a day, perhaps as two separate 1-hour sessions. Later, when everyone’s gotten the hang of it and is excited about doing more, that’s the time to try doing a little more.

2. Keep participation voluntary

Collaborative work without eager, willing participation is not collaborative work at all. Anyone who doesn’t want to try pairing should not try pairing. Maybe, if everyone else seems to be having fun, they’ll change their mind; maybe not. No idea is so good that it must be forced on people.

3. Learn out loud

There are many different techniques for pairing. In “strong-style” pairing, the navigator expresses intentions and the driver listens and transcribes. Switch roles every 5 minutes. When your timer goes off, don’t worry about finishing the sentence or the thought. Just switch roles, see how well you adjust, and consider how to make the next switch easier. Worst case, you can finish the hanging thought 5 minutes from now.

4. Build pairing skill

If you’re about to try pairing, it’s probably not the only thing you’re hoping your team will try. Defer as many of those other ideas as you possibly can. Concentrate first on adjusting and getting good at working together in this new way while continuing to create code that isn’t too much different (maybe slightly better, since code review is happening all the time). When pairing is going well, it will provide a platform to disseminate new ideas. Before it’s going well, hold off on other new ideas as best you can.

5. Learn incrementally

Once you’re pairing, you’ll encounter lots of other ideas, such as writing tests first, refactoring opportunistically, and synthesizing these into Test-Driven Development.

WIP (Work-In-Progress) limits are every bit as useful for learning as they are for delivery, and for the same reasons.

Since delivery requires learning, a Learning-In-Progress limit of 1 might be too low. Try a limit of 2. For the rest, keep a shared list of everything your team would like to try. When you encounter a new something you’d like to try, add it to the list. When you’re ready to try a new something, look at the list and see what jumps out at you. Wait until you’re comfortable with what you’ve learned (enough to call it “done”) before pulling your next learning item.

6. Maybe don’t bother with pairing

Extreme Programming took a bunch of practices that had worked well and turned the dials all the way up. If we were adjusting those dials today, we’d turn the collaboration dial past pairing and work, as a whole team, on one problem at a time.

7. Invite an experienced facilitator

These guidelines may help your team navigate the shift to working together more closely. I hope they do. I hope you also consider bringing a seasoned software development coach to join you as you begin this journey. It doesn’t have to be me. :-)

Suggestions from others

Additional references