During one of the open space sessions at CITCON Asia in Hong Kong 2015, a question was mentioned by several people:

How do you convince people and make sure they start doing pair programming?

A short answer would be: You don’t.

Almost all developers tend to dislike idea of pair programming if they haven’t tried it before. It sounds quite weird, inefficient, and scary. Besides, any argument for starting to do pair programming by itself is weak at best.

• “Two people deliver work of three people if they do pair programming” – Yeah, right. A very bold statement. How did you measure that?
• “You will deliver higher quality code” – That could be, but we already do code review afterwards.
• “You will learn faster from each other” – Yes, others will learn from me, and slow me down. I’m faster than others, and don’t want to waste my time.

There are probably many more of these reasons not to try pair programming. They will usually end up in a really awful feeling where developer feels being forced to start doing pair programming, as if he does not know how to perform his job.

A much more successful approach is where you don’t try to change people’s behaviour, but the system surrounding teams:

Reduce multitasking

Inexperienced teams usually work on just as many stories as number of team members. Number of tasks is usually even higher. The most common effect is not being able to deliver much or anything according to Definition of Done within one sprint. Team will reflect on this and start reducing multitasking. This will automatically encourage people to start helping each other and finishing stuff before starting to work on something new. Helping each other often means sitting together behind a machine and making sure things are finished faster and better.

Stop fixing bugs, and start preventing them

Create awareness in team how wasteful it is to fix bugs or have dirty code. Those bugs should not be there in the first place. “Let’s talk a bit about our bugs. What kind of bugs do we have? Let’s do root cause analysis on them.” This process often leads to lack of knowledge and practice for less experienced guys. Most experienced guys are the ones who are most annoyed by dirty code and bugs. At that point they are more likely to see the advantage of sitting together with less experienced guys.

Stop measuring individually

Any individual KPI and objective is killing pair programming from the start. Instead, the outcome produced by the whole team should have the focus. By focusing on the outcome, potentially releasable increment, team will naturally realise how much they depend on each other and the need to work together more intensively will emerge.

Value continuous learning

People love to learn new things. In fact, most developers will remain in a team for a long time if they are continuously able to learn new things they choose themselves. That could be a new technology, or simply how to talk or explain things to others in an effective manner.

At the end, pair programming is just a mean to an end. Trying to sell a practice because you know it is good, is never a good idea. No developer really loves pair programming practice itself, they love working together, learning new stuff, writing great code very fast, and being appreciated for help they give to others. One way to achieve this, is by doing pair programming among many other possibilities. By emphasising the real things, you might discover that pair programming might not be a good idea in your situation.