Remote Pairing a true story

When you join a project, you might face a brand new world with new stakeholders to deal with, a different technological landscape, and new team members. On the other hand, new expectations and a clean slate to start defining the practices the team is going to embrace based on each of their backgrounds.

The challenge goes beyond those inherent to the project. It is key to establish new team dynamics, how the work is split, how requirements are refined, and how the workload is handled.

There are several ways to build a team. If you want your project to succeed, a good project coordinator will embrace XP Practices and use some flavour of agile to handle the business delivery workload.

The Challenge

Now imagine the team is composed of skilled and experienced members, but they are in different locations, different time zones, or perhaps working remote, or even working alternate days from home.

This is a perfectly valid team set up in our brand new highly connected world. It defies the traditional ways of working, putting our engineering practices under a microscope, and makes us try to find the best ways to cope with the new context, while still using best practices.

Pair Programming

Pair programming is considered a Core Practice among those 12 practices enumerated within the XP scope. It is basically a social activity and is where two developers work together in the same tool they use to produce their craft with the goal of creating enriched code that emerges from their interaction.

Working in pairs relates deeply with other core practices such as Code Ownership, Code Standards, and even helps build the Metaphor of the system across the team.

When you and the brand new team agree you'll embrace pair programming as a whole, all code to be sent into production is created by two people working together at a single computer.

The best way to pair program is to sit side by side in front of the monitor. Slide the keyboard and mouse back and forth.

But, how does this last statement match with the context presented in the first paragraph?

Pairing remotely is still pairing

Pair programming is a demanding activity and remote pairing is even more demanding, but it doesn't need to be even more exhausting. It can still be enjoyable, rewarding, and done effectively. Here are some lessons I learned that might help your team and boost their pair programming experience:

• This activity requires good and uninterrupted connections.

• Get a comfortable headset for your team, avoid microphones that capture too much environmental noise.

• There are dozens of tools available but stick to a video conferencing tool that allows only one person at a time to share their screen. We want one driver at a time.

• Ask questions and be prepared to explain to keep your pair engaged.

• It is not as simple to say "here" or "there" when referring to something to change or add. Use the method or functions names and line numbers to reference a location in the file.

• When more information is needed, invite someone who can help to your video conference to alleviate any doubts.

• You can also try mob programming (it didn’t work for me, but I know many of my colleagues have had great experiences doing mob remotely).

Other than the above, basically use common sense and general pairing guidelines. Here are some suggestions that might help you throughout your pairing experiences:

• Involve the whole team when doing planning meetings to make everyone feel included. Organize the meetings taking into account anyone who will be joining remotely.

• Have a refined backlog of work, which the whole team took part to create.

• Share context, make it part of the discussions and own the topic, but this is, in my opinion, a key factor to build a shared understanding of the work in the team.

• Shift the pairs and balance skills, as whilst pairing isn't a mentoring activity, it won't work if none of the pair members have experience on the topic or technology.

We are craftspeople, we like to solve complex problems in the best way possible, using the best methods that engineering practices encourage. In the hyperconnected context we live in, we can definitely find a proper way to work remotely as effectively as if we are together sitting next to each other.

Conclusion

Pair programming is tough, requires practice, and some sort of expertise from the involved team, and many strategies and suggested approaches exist to cope with this.

There are many developers that object to the benefits of it without even trying it. Trust me, try it, give it a run and evaluate the results. You'll be tired but the outcome of your craft will be beneficial for the whole team and you'll also learn from your pair.

Above I left some hints based on our experience working in a Codurance project where, despite its ups and downs, we managed to work collaboratively as a team with the involvement of Barcelona, London, and Manchester team members.

Do not allow remote working to prevent you from doing it!