The practice of Mob Programming is being widely used by now. What is new to most companies is the need of applying the practice in a remote environment.

We at openForce now tried to apply the best practices of mob programming in a remote session and it worked out just fine! This article shall explain how we arranged ourselves with the remote situation. What we worked on and how it turned out is to be featured in another article about fancy things like terraform, packer and how we coordinate our GitLab runners.

Why a remote mob makes sense

Often remote working is considered to be less communicative and knowledge transfer is done via presentations, documentations or videos and screenshots. All these forms of communication have well known limits when trying to spread knowledge. One of the best ways to spread knowledge in a team of developers onsite is the approach of mob programming. So why not try to take the best practices we have for remote meetings and one of the best approaches to spread knowledge to create a better remote working experience.

What our workflow looked like

The team that worked together did not have experience in the given constellation although most participants were part of a mob before. With a group of five we had a quite ideal group size. The session itself started of with the organizer explaining the goal of the session, as we beforehand chose an issue from our board.

Afterwards we started coding using the popular driver/navigator pattern as described by Llewellyn Falco, which was originally designed for pair programming but got popular for mob sessions too as the concept works just fine.

  • Driver:
    • Writes Code
    • Follows the Navigators instructions
  • Navigator:
    • Instructs the driver to write code
    • Tries to break down tasks into codeable units

The multiple navigators discuss ideas, look up things and decide what to code so the driver can focus on the final result built by all attendees. For switching roles we used a timer of 15min which turned out to be a reasonable interval. Regarding the length of the whole session we didn't make any initial plans. We then ended up splitting the session it in two blocks of around 3 hours with a lunch break in between. Furthermore we set a timebox for the second block to create a fix end time instead of an open end session. Luckily we even reached our goal a little ahead of time and got to play around with the final result.

During the session it was really productive to be able to discuss the code while also being able to look up missing information as a navigator. In the meantime it was just as enjoyable to be the driver and listen to the ongoing discussion or to ask fun questions like: "Does this even work?" Overall the Workflow really helped to focus on getting the issue done while spreading knowledge as we used some new technologies most participants were not familiar with. The two perspectives of understanding the syntax and semantics of the used technologies as a driver, as well as seeing the bigger picture and the growing architecture of the project as a navigator really helped to learn new things with a hands on approach.

Which tools we used

As a remote session like this needs continuous communication and attention of all participants we tried to use as few tools as possible. In detail we only used Jitsi to have a ongoing video call and VS code with the live share plugin for obvious reasons. The video call was much needed to create a certain presence of the attendees. Furthermore it sort of felt like a in person session for the navigators while discussing the next line to be written. Regarding VS code and the live share plugin we were really satisfied with the capabilities of this tool selection. Being able to see each others cursors and to browse within the whole project as it is and not in your local version of it allowed the navigators to give precise instructions, being able to follow the driver and look into different files. It also allowed for a quick switch of roles as there was no need to switch any screen sharing or to commit files on every driver change. To be fair our setup does pretty much require two screens, as you always want to see each other at least in the corner of one's eye.

Final thoughts

The idea of mob programming is great and the possibility to learn new things while actually creating value is the best thing to happen to a developer. Although not being able to sit together in one room and have a group event to learn, code and reflect this idea is applicable to a remote approach. We found it very appealing to be able to share thoughts throughout a video call and the live coding session and didn't miss much apart from having lunch together and celebrating the results as a team. We would recommend every team in need of a way to share knowledge to try out a remote mob programming session. Because we are going to have many more of these in the future.