Working from home, social contact with colleagues is significantly reduced, both in duration and variety. To connect and collaborate in the office environment, a quick scan of your team will tell you who is free to discuss the issue at hand and work towards a solution (or decide it’s time to go to the pub).

Pulling out of a problem and taking a step back is a difficult skill to master. When working from home, in some variation of lockdown learning to live with a severely decreased social circle we are biased towards isolationism. Without actively reaching out towards colleagues, collaboration can easily slip into hibernation; sure, every now and then you need to eat talk but there are a lot of quiet periods.

67% of respondents felt less connected to their teams in the pandemic

After a few months (or 12) small inactions can compound and one survey found that 67% of respondents felt less connected to their teams. This is a problem for two reasons. Firstly, high performing teams are well-connected and highly collaborative (we all aspire to be part of one of those teams). Secondly, from a personal perspective and with apologies to any introverted colleagues, collaboration and interaction with other humans gets me out of bed in the morning.

If you build it, they will come

Pairing is a deliberate action, don’t assume that because you and your colleagues want to do it, then it will happen. Other team activities (sprint planning, standups etc) happen because they are scheduled; regular pairing is no different.

At the end of last year, after talking to some colleagues, we decided enough was enough; it was time do something explicit to increase collaborative working. Around the same time, Skype Dual Control became available, so we started our pairing via screen control sharing. In the meantime, Jetbrains released the Early Access Programme for Code With Me and we began the New Technology Introduction process to onboard it within the bank. Today, we use a blend of Skype Dual Control and Intellij Code With Me depending on the duration of the session, and the task we are pairing on.

No plan survives first contact with the enemy

Sometimes, the best plans for a pairing session are derailed by knowledge gaps in the team, transforming the session into knowledge sharing. This is a Good Thing™; you’ve identified that your bus factor is too low and moved to address the problem.

Three months on and I’ve noticed a big improvement. Collaboration is up between the team (most members pair with most other members) and because we are used to the tools, short ad-hoc collaboration has increased as well. Most importantly though, morale has improved, everyone I have spoken to is happier for the extra conversation and general good vibes that come from solving a problem together.

Failure is not an option

We’re still learning how to pair as a team… sometimes we fail; and that’s ok. Don’t let your first failure adopting a practice stop you. Retrospect, learn and move forward.

I’m not going to pretend that it’s been simple, very few good things happen by accident and we’ve had to adapt along the way.

Getting started

This is the process I followed starting to remote pair programming:

  1. Prepare: Read a couple of articles on pair programming methodologies and advice. If you know anyone who practices pairing, have a chat about what works (and doesn’t work) for them.
  2. Start small: Schedule some pair programming with one colleague, I would recommend 2 90 minute sessions a week, with each session split into 2 40 minute slots of concerted effort (stopping after 40 minutes is hard; it’s an area i’m trying to improve on).
  3. Plan the Session: Take the first 5 minutes to brief each other on your current tasks, select the most productive workload (for example, favour tasks that promote knowledge sharing) and scope the first time slot.
  4. Be prepared to pivot: After each slot have a brief retrospective, if the pairing isn’t giving the desired outcome, pivot to another task or invest some time into knowledge sharing so that the next session can be more productive.
  5. Retrospective: After 2 weeks (or 4 sessions), have a retrospective with your colleague, see what’s working and what isn’t, maybe the sessions are too short, or maybe shorter, daily sessions would be better.
  6. Repeat: Each find another colleague to start pairing with and schedule further sessions.

Tools

If code and data must remain on premise then a number of the cloud-based pair programming tools cannot be used. However, that doesn’t mean that remote pair programming is not possible. Today, the following tools/IDEs can be used to perform remote pair programming whilst keeping code and data on premise:

  • Screen control sharing via traditional chat application, e.g. Skype for Business/Microsoft Teams
  • VSCode LiveShare (there is a direct option that keeps data on-premise)
  • Intellij Code With Me (infrastructure can be deployed on-premise)

So, why not give it a go, and see whether it works for you. After all, what’s the worst that could happen?