Mob Rules - Moving to Virtual Pair Programming

Like all companies, lockdown has impacted the way we work at TransFICC. We have always championed Extreme Programming as our methodology of choice, so when we decided to close the office at the start of March, this raised some issues around how we would operate with everyone working remotely. We felt this might conflict with pair programming (a software development technique we use extensively, where two programmers work together at one computer - as shown in the picture).

As a rule of thumb, everyone at TransFICC pair programs but we were not sure how we would do this remotely. To begin with we just didn't attempt this, we decided to continue with trunk-based development and trust people to just do the right thing; we made sure tasks were small on a given piece of work and individuals in a team would rotate on the functionality in an attempt to avoid silos. We decided to work this way because we really didn't want to utilise pull-requests - we don't like the increase in the feedback cycle, and you're not really doing continuous integration if everyone is working on branches!

After a week of working like this we found communication between team members was not going particularly well and the handover of bits of functionality was hard, due to the lack of context. Instead, we decided to attempt remote pair programming, where one member of the pair uses RDP to remote into one of our pairing stations in the office and the second member uses VNC to connect. They would then share a video call session to communicate. We found this worked pretty well once we had fixed some issues around shortcuts not working in our IDE; in fact we are still working like this today.

One of the benefits we have found from remote pairing is how easy it is to move into mob pairing; we can easily have 3 or 4 people all working together on a single pairing station. This has actually been easier than it is in the office, as you don't have the physical space limitation of everyone crowding around a single machine; it also allows for members of the mob to do some research on a given subject whilst the other members continue working on a problem.

We've found remote pairing to be more tiring than pairing in the office as you don't have the same physical cues and it requires you to over communicate. You also have to be more careful around who is driving, as you can't see your pair reaching for the keyboard! These are somewhat minor issues, with the former being mitigated by people taking regular breaks.

So overall, remote pairing works pretty well, but a side effect of working remotely is our teams work more in isolation now; before we used to have a lot more cross-team communication and collaboration, but this happens less now as there isn't the same common area for people to just chat. We tried to improve this by having daily coffee breaks; anyone can join them, but 6 people are selected every day who "should" attend as a way of making sure some people are available. We've found this to be a good way of having an element of socialising but it's still somewhat limited as only one person can talk at once (I am sure we have all experienced this on video calls).

We've attempted to break the team silos but ensuring we are doing cross-team rotation. At the start of lockdown we paused this, as moving to full remote working is quite a large change and we wanted to give people time to adjust. We have now introduced cross-team rotation but on a slightly slower cycle (we've done this twice now) and found it to be working quite well in terms of sharing knowledge across the teams. We feel this is something we can still improve on, and it is fixed as a part of our company retrospectives.

All in all, we feel our move to remote working has gone quite well. We feel our overall productivity has not diminished and we are able to continue with pair programming, allowing us to still have short feedback cycles. This does mean we have to work more synchronously than other companies who work remotely but it works for us - at least at the moment.