Remote Mob Programming
In this post, Jessica, Robert and Thao, software engineers on our Learner Experience team, share their experiences with mob programming.
Like many companies we’ve worked much more remotely over the past year and have changed the way we collaborate and work together. One of the things we’ve changed is that we mob program more through screen sharing apps. This has allowed us to get the benefits of pairing, like sharing knowledge and learning, and build a strong team culture.
In this blog post we want to share things we’ve learned when pairing with more than two programmers and document tools and practices that enhanced the experience.
What is mob programming?
Mob programming is a software development technique similar to pair programming, but with more than 2 developers. In our case we would have a mob of 3–4 of us simultaneously working on a problem. One team member would share their screen and others could observe, comment and also type in their editor.
Preparing for mob programming
Mob programming can be time consuming, so it’s important to choose what to work on ahead of time. Ideally you should have a fully fleshed out user story in your backlog that is ready to be picked up. Everybody should know what the problem is, but you don’t need to know how to solve it, since coming up with the solution and the best way to tackle it is part of the mobbing session itself. It is good to have a list of todos or checklist items in order of priority that the mob can work on.
Since calendars tend to be full and people are pulled into meetings all the time, it pays off to schedule the mobbing session beforehand. This helps remove distractions. When mobbing, it can be easy for someone to drift off and attend to other tasks, like reading emails or responding to direct messages. In our view that’s an anti-pattern and the group benefits from the focus of all team members.
Establish upfront whether it’s okay to keep going when individual members become unavailable. If you all agree, make sure everyone is aware that it is okay to drop out to attend to other meetings and tasks on their calendar. It lets team members know that it’s alright to leave and come back when they are free again.
Make other people on your team and other teams aware that a team mobbing session is going on since that also helps to keep other tasks and meetings to a minimum where possible. It helps make the workflow less disruptive.
It is also important to take regular breaks, as working in a group can be tiring. To stay energised and motivated, it’s good to step away from the mobbing session and refresh regularly.
Style of mobbing
In theory, you can mob program with any number of people, but in practice you want a smaller group, so it’s more effective. In our team, we found that groups of three worked best.
One person is chosen as the driver, while the other two are observers. The driver usually shares their screen and writes the code. The observers will watch and can review the written code on the spot; they’ll be able to identify issues quickly, point out any errors and can suggest alternative approaches or other ways of implementing the code. It is good practice to switch up roles regularly to give everyone an opportunity to drive, for example by swapping drivers every 40 minutes or after each chunk of work.
Mobbing sessions can usually be broken down into 3 main steps:
- Preparation
- Implementation
- Documentation
Preparation
To start with, discuss the problem, put it into a wider context and share your understanding. This step is extremely helpful as it brings everyone up to speed and helps clarify things, before starting on the actual implementation.
Implementation
When the story lends itself to test driven development, it helps to write tests first. In our case, we converted the goals of the story into a feature spec. Once we have a feature spec that makes sense to us and fails, we can work our way to the implementation “from the outside in”. We then dig into controller tests and unit tests in our Rails codebase. Once the tests are passing and our feature implemented we spend some time refactoring.
Documentation
What is particularly valuable is writing detailed commit messages together. While they can summarise and document your work, they can also help you revisit the steps you took and share your understanding once more.
Once all commit messages are written and you are happy with your code changes, you can open up the Pull Request together to get feedback from other members of your team.
Culture
At FutureLearn, collaboration is embedded in our culture and so we have plenty of opportunities to mob. In the past we had sprints to remove tech debt and improve our codebase (something we called “Firebreak” at FutureLearn) which gave us a chance to break out into pairs but also into bigger groups and try mob programming. We’ve also mob programmed when we break out into groups during Learning Hours (internal team learning events) to work on a task together.
Over the last couple of months, we have started to do some more mob programming sessions within our product team, allowing us to work more collaboratively. Looking back at the times we have done so we can identify a few good practices that can be followed. Although we did not start out with a set of principles or rules to stick to, we agreed that we wanted to provide an open and safe space for everyone to feel comfortable to contribute and share. This in turn made it possible to keep the communication going.
We enjoyed having discussions about the various approaches to identify the one we thought most suitable for the problem at hand. It gave us opportunities to share our knowledge and to learn from one another. Having such open discussion as a team can help each individual gain a good understanding of the new implementation.
Tools
Since we are remote at the moment, we find that the quality of our mobbing sessions increases when we share the screen and video of ourselves at the same time. Doing this can allow your team to pick up on non-verbal queues and feel more connected.
We tend to use either Zoom or Tuple to mob. Tuple is a paid-for pair-programming tool catering to programmers, while Zoom is designed around business purposes. Even though Tuple works very well for pairing, its support for larger groups is currently limited: there is an “observer mode” available for this purpose, but it is restricted to 3 people in total. Zoom, by comparison, can support larger groups as well as it supports pairs. On the other hand, it’s a bit harder to share the keyboard on Zoom.
Pop is another tool available. It has a free tier and works similarly to Tuple.
Regardless of the video conferencing tools you use, you need to consider factors that can impact your team’s performance. For instance, connectivity issues may come from problems with our personal hardware or the occasional dip in the performance of the corporate VPN. As a team, we try to be fairly patient with each other when this happens and different platforms may have different tools for coping with these problems (e.g., Tuple lets you change the screen resolution when screen sharing).
Another useful tool is Git Mob which allows users to co-author commits easily. Co-authoring commits is a great way to ensure that every member of the team can take credit for the work. This way other developers can also contact each of the listed authors if they have a question regarding the implementation.
When and when not to mob
While at first mob programming can seem very time consuming, the benefits quickly outweigh the costs, when used at the right time for the right chunk of work. In the long term, time is saved by investing more brain power into a project. The end result was often better when we mobbed on a problem compared to when we worked on it alone. Knowledge sharing in this way also means that everyone is updated with the intricacies of a problem, because they were all involved from the start.
As a project progresses, we have found it can be beneficial to stop mob programming and split up into pairs or smaller groups so that work can be more closely aligned with everyone’s schedules.
Having others in the group around to keep us motivated can improve focus on a given task and generally helps maintain morale when the work is difficult.
Since we are all remote, mob programming didn’t just help us come up with better technical solutions. It was also a tool for team building and creating bonds between us that are good for team spirit when not in a shared office environment.
If you’re interested in working at FutureLearn, we’re hiring! Please take a look at our Careers page to see our available roles.
