Saratoga Software

Saratoga Software

We partner with successful companies and convert their business ideas into meaningful technology solutions

T (South Africa) +27 (0) 21 658 4100
T (UK) +44 (0) 20 363 78024

Email: [email protected]

Saratoga
4 Greenwich Grove, Station Rd, Rondebosch, Cape Town, 7700

Open in Google Maps
  • ABOUT US
    • ABOUT SARATOGA
    • VALUE PROPOSITION
    • COMPANY TIMELINE
    • LEADERSHIP TEAM
    • CSR INITIATIVES
    • PRIVACY POLICY
    • PAIA MANUAL
  • OUR SERVICES
    • SERVICES
      • AZURE CLOUD MIGRATION FOR CUSTOM-BUILT APPS
    • CASE STUDIES
    • CLIENT TESTIMONIALS
    • CLIENTS
  • OUR PEOPLE
  • INSIGHTS
  • CAREERS
    • OUR VALUES
    • JOIN THE TEAM
    • SARATOGAN LIFE
CONTACT
US

Mob programming | Collaborative coding as a remote team

Tuesday, 18 January 2022 / Published in Insights, Latest News

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.
Tagged under: Developer, ensemble programming, programming, remote, remote developers, senior developer, Software, team programming

What you can read next

Saratoga Shares Insights From The 2016 BA Summit
Implementing Progressive Web Applications for a prominent Media Group
Creating meaningful career growth for IT professionals

Recent Posts

  • Leadership training

    Supporting a culture of continuous learning through training

    Following our article, ‘The value of leadership...
  • The value of leadership training for professionals

    Annually, Saratoga identifies a number of our s...
  • Insights into a software testing career

    By Shinaaz Osman, Senior Quality Assurance Cons...
  • Common misconceptions about software testing

    By Shinaaz Osman, Senior Quality Assurance Cons...
  • Devconf 2022 lessons and highlights

    ‘Insightful, stimulating, diverse, inspirationa...

Categories

  • Case Studies
  • Insights
  • Latest News
  • Networking
  • Staff Profiles
  • Technology

CONTACT US

Please fill in this form and we'll get back to you as soon as possible!

T +27 (0) 21 658 4100 | F +27 (0) 86 575 7170 | UK T +44 (0) 20 363 78024

4 Greenwich Grove, Station Rd, Rondebosch, Cape Town, 7700

COVID-19 Information

© Copyright Saratoga 2000 - 2023. All Rights Reserved. Privacy Policy.

TOP
We use cookies to improve user experience, personalised content and analyse website traffic. By clicking “Accept,” you consent to store on your device all the technologies described in our Cookie Policy. To learn more about our use of cookies, view our "Cookie Settings".
Cookie settingsACCEPT
Manage consent

Privacy Overview

This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorised as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyse and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Necessary
Always Enabled
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Non-necessary
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.
SAVE & ACCEPT