What is Mob Programming?

Mob Programming is a collaborative approach to software development in which a team works on a task simultaneously, usually in one place, on a single computer. Mob Programming is often declared to be the evolution of Pair Programming, because not only two but all available developers work on the solution of a task.

There are numerous meanings for the English term Mob. As a noun Mob stands for rabble, mafia, horde, gang or bunch. And the verb to mob sth. or to mob somebody stands for to to surround something or someone and besiege someone. However, mob programming does not have a negative connotation, it should rather be understood as a sworn group of people who together besiege a piece of equipment until they have satisfactorily solved a task as a team. 

The roles in Mob Programming

Mob Programming knows between two and six roles, depending on how you look at it. In some descriptions they are simply referred to as tasks, which makes a lot of sense especially in an agile context, because Scrum as the most well-known representative does not define explicit development roles. Roles in Mob Programming are therefore mainly temporary, they are not on any business card or resume.

There are the following two roles in every Mob Programming:

• Driver
• Navigator

The Driver is the one who sits in front of the computer and types the source code into the computer. He implements the statements, requirements, ideas of the other team members.

The Navigators are the team members who develop ideas, discuss them with each other and make suggestions for the solution of a task. They provide the input for the driver.

The following four additional roles can exist in Mob Programming:

• Designated Navigator
• Researcher
• Learner
• Timekeeper

What should the driver implement when opinions differ on the solution of a development task? Should he make a decision independently? Practice shows that in such situations – or when working with larger groups – the use of a Designated Navigator makes sense. He collects suggestions and opinions. He moderates, asks questions and structures content. And if necessary, he asks individual team members to gather information and find out about aspects parallel to solving the task. A team member who takes on such a research task – in Scrum one would speak of a spike story – becomes a Researcher.

Participants who cannot contribute anything to a concrete situation are the so-called Learners. They learn actively by observing, listening and asking questions. And last but not least, there can be a Timekeeper who initiates the role change of Driver, Designated Navigator and the other participants. In most cases, Timekeeper and Designated Navigator are one person.

​Rules for Mob Programming

The rules of mob programming are not set in stone. They are good practices that every organisation must develop and apply for itself, and check for meaningfulness. Here you will find some rules or recommendations for the implementation of Mob Programming:

• The group will jointly appoint a Designated Navigator. This person acts as moderator and explains the further procedure to the participants. If not clarified in advance, the maximum duration of the session (e.g. half a day or a full working day) and a timebox for changing roles are determined. Furthermore, a separate Timekeeper can be defined.
• The Timekeeper ensures that there is a role change e.g. every 15 minutes, so that each team member becomes Driver and Designated Navigator at least once.
  Most of the time you read that the Driver is the only one who uses a computer, a keyboard and a mouse. For the researchers, however, there could be other devices (computers, tablet PCs, mobile phones).
• The driver’s computer is connected to a beamer or a very large monitor so that all team members can easily see what the driver is typing.
• Ideally, all participants are in the same room. This is often considered a prerequisite for Mob Programming, although Remote Mob Programming is also quite practical.
• Ideally a task, e.g. an epic, a feature or a user story should be edited from start to finish. In this respect, Mob Programming is no different from other approaches to software development. It’s about understanding the task, defining acceptance criteria, finding and sketching solutions, writing code, testing the implementation, documenting the features (which is often “forgotten” in Mob Programming) and following the Definition of Done.

In the Open Space Format there is the so-called law of two feet. It says that you can always drop out of a session if you can’t or don’t want to contribute anything, or you can’t learn anything. Opinions vary as to whether this law should also be applied to Mob Programming. What is certain, however, is that regular breaks increase productivity.

Advantages and disadvantages of Mob Programming

Mob Programming offers a number of advantages such as

• a shared responsibility for decisions.
• the possibility to learn from each other through different views and experiences.
• the possibility to solve complex tasks step by step in a team.
• transparency and a common understanding of the code base.
• a high code quality through “common coding”.
• the promotion of team bonding through the joint solution of a task.

But there is also a big disadvantage in Mob Programming:

• the high effort to solve a task.

It is often recommended to carry out Mob Programmings with teams of up to approx. 8 members, but theoretically there could be considerably more participants. The more participants there are, the more opinions there can be. The more opinions there are on a task, the more discussions there can be. The more discussions there are, the longer it can take to reach an agreement. Etc. Or in other words: even if the majority of participants learn from the exchange, Mob Programming does not have to be efficient.

There are also some other aspects that should be considered:

• Is the Driver just an executive body or is he allowed to implement his vision? If the driver implements his vision, it could be very inefficient if all navigators are degraded to spectators. But if he only implements the guidelines, his expertise may fall by the wayside.
• How do you make sure that the Navigators do not treat the Driver like a beginner or a beginner like an expert? This problem tends to be exacerbated by the change of the Driver.
• What happens if the Designated Navigator or Navigators try to micromanage the Driver? Does this promote team cohesion? How can the Driver avoid this?
• What happens if a Driver tries to delete the code of another Driver? Is this allowed or generally forbidden? Would deviations from the rule be possible?
• It is also often said that “external” employees or roles from the organisation participate in Mob Programming and can even actively play the roles of the Driver or Designated Navigator. Here it is important that each organisation determines a suitable procedure for itself. A Product Owner, for example, does not need to be able to program, so why should he act as a Driver?
• Despite the change of roles, it is advisable to schedule regular breaks.
• And: it makes sense to conduct an after action review or a small retrospective at the end of a mob programming session. Ideally, this helps to consolidate findings and further improve cooperation in the next session.

Sometimes it is claimed that technical debt can be avoided or at least reduced through mob programming. Do you also see it that way?

Notes:

Here you will find additional information from our Smartpedia section:

t2informatik develops and modernises software as a service provider. Click here to learn more.