Mob Programming – Remote Teams in the Flow

Mob-Programming or Ensemble-Programming describes a software development approach in which an entire team works together and at the same time on the same code. In today’s home office time, it looks like this:

• All team members meet in an online conference.
• In turn, a team member shares the screen and is responsible for the writing (“the typist”) . However, the team member only writes what the other members have discussed and then dictated! The typist does not participate in the discussion and does not write code autonomously.
• After 5 minutes, the next team member writes and shares the screen. After another 5 minutes you change again. This can be done until the code is finished or a predefined period of time has elapsed.

On the software side, we find support for carrying out mob programming in the Opensource-Tool mob. If the team is working in a Git repository, mob – trough mob start – creates a temporary development branch in which work will be done for the duration of mob programming. At the same time, it brings a timer that alerts when the 5 minutes working time is over. 

With mob next all changes to the temporary development branch are commited. The next person becomes the clerk and then runs mob start again. This will load all changes of the previous writer, which allows seamless work on the code. 

After 5 minutes, the clerk runs mob next and the next person is the turn. When the mob programming round is over, mob done is executed. The command saves all changes into a commit, which can then be pushed to the main development branch.

As part of the training, a mob session was held on the topic of “Setting up a Kubernetes cluster using Ansible in Azure and deploying a sample application.” The training leaders guided the participants through the process and were available to answer questions. The practical implementation was carried out independently by the group.

Insights and learning experiences from the mob session:

• A key aspect of successful mob programming is a uniform working environment for all participants. This requires the latest versions of git, Ansible (including the same collections), and kubectl, as well as a current version of Python with a myriad of packages.
• If one team member works on Windows, another in WSL, and a third in a Linux VM, there are countless obstacles to getting everyone on the same page so they can work effectively. That's why we switched to Docker. To do this, we created a so-called management container, which installs all the necessary software packages in the correct versions in one container. This eliminated 90% of the problems, and the remaining 10% were solved together in the mob session. However, the setup took over an hour.
• At the beginning of the mob session, the 5-minute interval for changing writers was perceived as very short. However, the advantage of these short intervals quickly became apparent: in a team of five people, a 5-minute interval allows each person to be active once within 30 minutes. Longer intervals, such as ten minutes, would mean that each person would only write once per hour, which can have a negative impact on concentration and participation. Short intervals, on the other hand, promote attention and participation from everyone.
• Another important point was active collaboration. It became clear that focused participation by all team members is essential. If there are problems with understanding or ideas, communication should be direct in order to make the joint work effective. It is also important to consciously plan breaks, as intensive collaboration can quickly become tiring.
• A common issue in mob sessions is the uneven distribution of knowledge within the team. If the person currently writing has more in-depth expertise, this can lead to a feeling of being held back. Patience and a willingness to share knowledge are crucial here so that all team members can benefit. If another person takes on the role of writer, the expert can contribute their own knowledge in a targeted manner, thereby strengthening the entire team.
• The diversity of participants leads to different approaches to solving problems that arise. It has proven effective to have all suggestions brought up and discussed. As a rule, a solution is found together that is supported by everyone.

Such a mob session can be very useful: you share your knowledge immediately with the team, you don’t need a code review and four eyes (or 10) can see more than two.

Of course, such a session also costs strength, because you must be focused practically all the time and are in constant discussion. And if everyone has a working environment, you quickly get into a flow where working together is a lot of fun.

PS: Here you can find the results of our session.