I'm Rob Stearn, an Engineering Manager at MOO. In my last post I discussed the theory behind pair programming and discussed reasons why we don't embrace it. In this post I want to outline some ways to make it work.

How to make it work

We know that pairing produces results, we know why it does so and we understand the reasons why we're adverse to it. How then do we make it work? How do we move past the fear and pride?


Arm yourself with facts. If you need to justify a change in working practice to the 'troops' and the 'generals', run a test:

  • Find a reasonably complex task in your backlog.
  • Give it to a solo developer and a pair to work on.
  • Measure it from start to finish.
  • Include code review for the solo.
  • Encourage your team to discuss.
  • Be public with the results.

The last points about sharing results and encouraging discussions are vital to getting people behind making the change. Ideally this should be something your developers are begging you to do, not a change you implement on them.


Change is hard

We're discussing making a fundamental change to the way you and your colleagues work. Change is disruptive and almost always leads to a short term loss of productivity.Be aware of this, be clear and public about this, use the results of your measurements to point to the light at the end of the tunnel.

I often use the grief cycle, originally defined by Elisabeth Kübler-Ross, to describe the stages people go through when confronted with change. I won't go deeper into this here other than to recommend it for anyone initiating change as a way to recognise and understand behaviour during that change.

If you do one thing, make sure your colleagues know they won't be blamed.

Know yourself, know others

A pair that understands and knows each others ways of working will be more productive and happier.If you're a manager, there are some tools you can take advantage of to help your people know themselves better, and share that knowledge between them.

Three examples of such tools are:

They are all based around Jungian theories of personality preferences and present that as behavioural and communication types within teams or work environments.


It's well worth considering the way you sit to work together. Does the layout of desks/workstations support pairing easily? Do you have hardware setup in a way to promote pairing?Maybe consider setting up defined stations for pairing activity.



Effective pair programmers hone their balance during an initial adjustment period.This can take hours or days, depending on the individuals, the nature of work and their past experience with pair-programming.

Give people time to get used to the new way of working. Have regular retrospective sessions on the progress made and the issues uncovered. Rotate the pairs regularly to give people a break and a new perspective.

Agree on the rules

Agreeing on a set of mutually accepted behaviours will help you all support each other. These will start out quite fluid and benefit from examination and updating, then they will solidify as consensus is reached.

Some suggestions are:

  • “Slide the keyboard/don't move the chairs”.
  • Communicate constantly.
  • ​​​​​​​​​​Articulate your thought process.
  • Don't filter your ideas.
  • ​​​​​​Regularly switch roles.
  • Take agreed breaks to check mail etc..


As great as pair programming can be, it is a lot of communication and thinking and can be a strain to do all the time. Anecdotal evidence supports a maximum of 60% of time spent pairing with acknowledged time for solo work, breaks and non-coding tasks. As in life, balance is really important.

Great! So that's all, right? Well, no...


As you put these practices in place, measure again. Do a retrospective, publish the results, make changes and repeat.Treat any change to working practices as an experiment, which needs a hypothesis, measurement, results and conclusion before feeding that conclusion into the next iteration.


In these two posts we've covered defining pairing, how it can improve your team’s code, wellbeing and process, the theories behind it, reasons why people don't embrace it and some strategies for making it work.

I hope this inspires you to give pair programming a chance to make you, and your colleagues, better developers and better people.