What's an easy and sustainable way to introduce pair programming?

Question

As a ScrumMaster I've read some texts about pair programming. I want to introduce that to my team and make sure it's been done regularly. As a "special feature" we have a remote worker and I want him to be part of this movement. My goals are, as literature mentions, to improve code quality, transfer of knowledge and become "faster" at some point.

My questions are:

1. How to roll out pairing in a Scrum team?
2. What are best practices for starting and executing pairing?
3. How can I make sure pairing lasts and is no flash in the pan?
4. How can I help the team to include the remote worker?

The question is slightly related to this one: How can my team reconcile flow and pair-programming? but I am more focused on the Scrum Master view.

As I got three good answers, but I only can accept one, here's a short summary:

1. All answers suggest, that the idea of pairing should come from the team itself (maybe the Scrum Master could steer towrds this direction)
2. Pairing can be done using the driver / navigator metaphor
3. It is not said, that paring might be necessary the whole time. Don't be dogmatic as @Muhammad mentioned
4. This can be done via screen sharing and video chat. Timezones might be a problem.

Answer 1

How to roll out pairing in a Scrum team?

I am afraid there is no right answer to this. It all depends on the existing team dynamics. Nevertheless, what is almost always relevant is to understand whether pair programming is something your team will benefit from? If you have good reasons for it, discuss them with your team during the retrospective meeting and let the team take it from there.

What are best practices for starting and executing pairing?

Depending on how patient you can be, you can simply highlight the "problems" to your team and ask them to come up with solutions. If someone else comes up with pair programming as a solution, it will make things so much easier. There is nothing better than teams making good decisions on their own.

How can i make sure pairing lasts and is no flash in the pan?

You shouldn't make sure of this. Be wary of "cargo cult" or being dogmatic here. No one practice is suitable for a particular team infinitely. In my experience, pairing is great for junior developers or when the goal is to increase the level of "cross functionality" in your team. After a while, I don't see why pairing is necessary unless two developers themselves decide they want to pair for some reason or if you can share evidence that the overall code quality is better when developers (even experienced ones) pair compared to when they do not pair?

How can I help the team to include the remote worker?

This can be very tricky but not impossible given the numerous collaboration technologies out there. However, don't ask two developers to pair remotely if they are uncomfortable with the setup. I can imagine screen-sharing apps would be a way to go?

Answer 2

To pair or not to pair is a decision that the team should make and own. "Rolling out" any technical practice, and especially one that brings with it such strong personal preferences as pair programming, is pretty much guaranteed to backfire.

To encourage people to try pairing, I would keep an eye out for situations which commonly breed misunderstanding, or dissent in code review, etc., and prompt people with something like, "what if both/all of you worked on that together for half an hour?" You may want to avoid mentioning pairing by name. Maybe in a retro, if someone brings up a situation where code or product feedback required rework, you can help them understand how real-time collaboration would have helped avoid it.

My team has had success with remote pairing, though it absolutely requires a fast and stable internet connection. There are tools which specifically allow people to interact with each other's development environment at different levels (OS, shared editor, etc.), or you can just video chat while one person drives.

Answer 3

As with practically any change to workflow, your first step is to get buy-in from the Team. If I were you, I'd bring the problems you're trying to solve up during a Retrospective meeting, and ask for suggestions. It's possible one of the Development Team members will bring it up themselves - this will make it go down much easier than a mandate. It's also possible they might suggest an alternative suggestion which could work just as well (such as, say, code review) - depends on your actual requirements. If neither happens, then you could bring it up yourself for discussion. The only two ways I know of to avoid a practice being a 'flash in the pan' are either to get team buy-in or have an executive mandate - the latter of which could end up reducing performance, rather than improving it.

As for best practices, I know of three. First, it's best if junior programmers are paired with senior programmers, with the junior usually being the driver and the senior usually being the navigator (note that this works only if the senior is actually more skilled/knowledgeable, not just has higher seniority on a corporate ladder). Second, both need their own computers at a single desk - while the driver is programming, the navigator should be free to look things up on their own machine. Third, you should switch the pairs up every now and then - knowledge dissemination works best if your pairs aren't static.

Regarding the remote worker, that presents a lot of problems - especially if they're in a different time zone. If you're going to have to alter people's working hours in order to even get people to be able to pair program, then my suggestion would be to just forget it and keep to code reviews instead. If you don't have to worry about that, then at the very least you'll need some sort of screen-sharing software (so the navigator can see the driver's code; ideally the driver should be able to see what the navigator looks up, as well, so you'll need to share both ways) along with voice chat at the very minimum, preferably with video as well. You might even need three monitors per person - one for the shared screen, one for video chat, and one for IDE (driver) / browser (navigator). As a disclaimer, I've never tried remote pair programming before, but I imagine the setup listed above would be the minimum necessary to get anything close to the same experience as in-person.