Async Pairing

What happens if you want to the advantages of a pair or ensemble, but you don’t have much time together with the person you’re working with?

There’s more than one way to write code within a team, whether that’s as an ensemble (mob), in pairs or working solo with code reviews. But, what happens if you have different, conflicting meetings during the day or you’re working slightly different hours? Working in distributed or hybrid teams means that the working day can be much more flexible. However, this can create conflict when so much good work, and high quality communication, needs to be done synchronously.

An alternative solution I’ve observed, and used myself in several teams, is something I’m calling async pairing.

What is it?

It’s a pragmatic response to the realities of working in a distributed team. It looks something like this:

• Start a piece of work together. Do the kick off and start pairing for a bit

• Discover one of you has a meeting/real life thing

• One of you continues working for a short period (e.g an hour), pushes some commits and explains what’s been done to the other person

• Then swap, so one picks up where the other left off and continues the work for a short period. Again, by pushing small commits and messaging the other person

• At frequent intervals, you come together to discuss the changes and work together. Do this at least once or twice a day

What this looks like for me is usually a series of short messages and code snippets in slack, punctuated by video calls.

When doing this, it’s really important to keep communicating and to work in small steps. Explain the ‘why’ of what you’re doing. Regroup regularly.

It is not two people working independently on the same problem by solving different parts. It’s still pairing because you are still pairing much of the time and having a continuous conversation in between those sessions.

Why?

This approach mitigates some of the disadvantages of solo working by:

• Increasing context and knowledge transfer
• Improving the feedback loops
• Removing the pain of pull requests by doing code reviews continuously
• Preventing feedback on work being given only at the end
• Keeping work in progress low

And still keeps some of the advantages, such as:

• Allowing for asynchronous working
• Providing headspace for neurodiverse people or those just not wanting to work in a group for a bit
• Solidifying learning done in larger groups

Progress isn’t as smooth as working in a pair, and some of the advantages you get by working in a pair, and definitely as an ensemble, will be lost. However, I think it’s a useful additional technique to have available.

I would be really interested to know if other people are also doing this and how they find it, so please get in touch.