Mob programming | Collaborative coding as a remote team

Written by Stephan Bester, Senior Developer at Saratoga.

For over a year now, my team and I have been dabbling in so-called ‘mob programming’. Initially, we had been pair programming for a long time and found that this style of programming worked well for us. Then the team started growing. It was also around this time that COVID-19 hit South Africa and the team had just adapted to working remotely. We decided to extend this collaborative approach to our new team members, and soon we found everybody working together in a way none of us had encountered prior to the pandemic.

Ensemble programming is most commonly referred to as ‘mob programming’. I personally prefer the term ensemble programming as this avoids the sometimes negative connotations accompanying the word ‘mob’. In his book ‘Mob Programming’, Woody Zuill also suggests the name ‘team programming’. Whichever term you prefer, the core concept is that many team members work together on the same thing at once, with one person coding at a time.

Why mob programming?

The idea of mob programming is often initially met with scepticism, perhaps because its effectiveness seems counter-intuitive. “Isn’t it a waste of time to have many people doing the work of one person?” Perhaps, it never was a one-person job. We must remind ourselves that programming is thinking, not typing – the keyboard is rarely the bottleneck for development work.

The Mob Mentality Show on YouTube describes mob programming as focusing on flow efficiency over resource efficiency. It might be tempting to ensure that every individual is busy 100% of the time, but this ignores the impact on the overall team. For instance, handovers between team members (e.g. code review) introduce costly context switches and result in lag times on work items. By working together on the same task, the team has fewer things going on at once, resulting in increased focus.

In our team, we have observed many benefits to mob programming. An obvious one is knowledge sharing. The whole group gains knowledge of the task being worked on, so we end up with fewer silos. This also helps with faster onboarding – a new starter can learn about the system, the domain, technology, etc. from other developers while working together. Another benefit of ‘mobbing’ is shared code ownership. Because everyone was there when the code was written, everyone is comfortable working on the code later on.

We’ve found that mob programming increases focus as there are fewer distractions and less context switching. The fact that code review happens continuously also means that a good idea doesn’t have to wait until a handover to be discovered. Mob programming also makes the team more resilient because progress is not halted when a single person drops off; the momentum is kept and they can simply re-join later. I have also found this way of work to be much more effective in team-building than any corporate group exercises.

How does it work?

Mob programming extends pair programming to the rest of the team. It uses the same Driver-Navigator pattern – only one person (the driver) touches the keyboard, while the rest of the team (the navigators) directs their actions. The driver role is rotated among team members at regular intervals.

There seems to be an established setup for mobbing in a shared office. A group of developers use the same computer, usually connected to a big screen or projector, and positioned so that the whole team can see the screen. When the time comes for the driver role to change, the next person physically takes the mouse and keyboard or the team members switch seats.

In a remote world, we have found this translates quite naturally to a group voice call, e.g. on Microsoft Teams with the driver sharing their screen. When it’s time to switch roles, they commit their changes to source control, and the next person pulls them and takes over the screen share. If the code is not in a state to be merged, a temporary WIP branch can be used.

How we’ve optimised our approach

Of course, there are many different ways to approach team programming. For example, some teams connect to a remote mobbing machine instead of screen-sharing from their own. There are also mob timer apps – though we’ve not used these, instead going by our gut and looking for natural breaks in the work. Some of us have briefly experimented with the Live Share extension in Visual Studio, which allows multiple users to edit the same source file. However, this does not really fit the Driver-Navigator pattern. My team has found the ‘request control’ option in MS Teams useful for pointing at things on the screen (as an alternative to shouting out line numbers).

The question of whether cameras should be on or off comes up often. Seeing each other on video allows us to pick up on non-verbal cues and can contribute to a feeling of ‘togetherness’. At the same time, cameras can be distracting, and in the case of limited connectivity, the additional bandwidth might also be a concern. In our team, we typically leave our cameras off outside of formal meetings.

In my team, we do not enforce mobbing. We let team members naturally form groups depending on the nature of the work, the number of people available, etc. As soon as more than one person is online, we start a call, and things flow from there. We often have multiple calls running simultaneously, and people can jump between them as needed.

So, what size should an ensemble be?

The consensus seems to be around 3 to 5 people. This is the number range we typically roll with and is similar to what Woody Zuill recommends in his book. I put the question to Twitter and got mostly the same numbers. Interestingly, some responders reported that they were successfully mobbing with ten to twenty members.

There are many techniques used in ensemble programming, and I’ve also seen a more complex roles-based style discussed. For example, aside from the Driver and Navigator roles, there might be an Automationist who keeps an eye out for stuff that could be automated, or a Nose responsible for calling out code smells. There’s even a mob programming role-playing game on GitHub. We haven’t yet encountered the need to assign roles to this level, but then I have a team full of noses!

Whichever style you choose, remember to take regular breaks. Mobbing is effective but can also be exhausting. As a team, we often remind each other of this basic human necessity.

A whole-team approach

Now, as much as it’s called programming, the ensemble is open to more than just programmers. In addition to developers, we also mob with testers, UI specialists, clients and pets. Each person can contribute their own expertise, and at the same time, a bit of their knowledge is transferred to everyone else. As a developer-heavy team, we’ve made an effort lately to bring Quality Assurance into the process earlier and so far the results of this have been promising. Instead of throwing a ticket ‘back over the wall’ and waiting for someone to pick it up, testers work directly with developers from the get-go, so issues can be resolved on the spot.

Join the mob!

You might be surprised at the number of companies that have adopted this practice already. There’s a community Trello board that keeps track of companies and coaches that mob and there are some big names like IBM and Redgate in the mix.

Ensemble programming has fundamentally changed the way I think about teamwork in software development. It might be a difficult thing to introduce into some environments, especially ones with a more traditional project management approach. Nevertheless, having experienced its advantages first-hand, I believe it’s an idea worth exploring in every situation. Certainly, I plan to bring elements of it into every team I join in the future.

Further reading

• Mob Programming by Woody Zuill and Kevin Meadows.
• A few tips on mobbing by ‘Agile Otter’, Tim Ottinger.
• Mob Programming RPG.
• Mob Programming Patterns.