Mob Programming – Remote Teams in the Flow

My fellow project engineers, architects and I recently took part in an internal training course on “Remote Mob Programming for Fixed Teams”. We wanted to learn how to best program together in a mob, what tool support is available and whether it is easy to learn and do this kind of work in our teams. In this post I want to share my experiences from this training.

What is Mob-Programming?

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.

 

What did we learn in the Mob-Session?

In our training we conducted a mob session. We thought about a topic in advance: Setting up a Kubernetes cluster using Ansible in the Azure and deploying a sample application in it. The instructor guided us through the working method and supported us with questions, otherwise we were left on our own.

What have we discovered and learned in the meantime?

• One of the most important points is that each team member has the same working environment. For our mob programming we need up-to-date versions of git, Ansible (including the same collections) and kubectl, as well as a current Python version with a huge number of packages.
• When one team member works on Windows, another in WSL, and a third in a Linux VM, there are countless road blocks to get everyone to reach a point to be able to work meaningfully. Of course we switched to Docker at some point. For this purpose, we have created a so-called Management-Container, which installs all required software packages in the correct versions in one container. This solved 90 percent of the problems, we were able to solve the remaining 10 percent together in the mob session. Before we reached this point, however, over an hour passed.

• At the beginning of the mob session, we felt that a 5 minute interval for switching is very short and we should perhaps extend it. However, we quickly found out why short intervals make sense: each person should have their turn to write within 30 minutes. If you extend the interval to, for example, 10 minutes, everyone in a 5-person team would only get it once an hour. This can quickly lead to distraction. Due to short intervals, the concentration of the persons remains higher, as it is quickly everyone’s turn again.

• In our training we also learned a lot about collaboration. It is important that each person in the mob session is focused on the task. Active participation is essential: if someone is not with us or has an idea about a problem, the person is supposed to actively address it. This way everyone stays on the top of things and doesn’t lose the desire to work. Likewise, you should actively decide for breaks, as such focused work and discussion can quickly become exhausting.

• An interesting problem during a mob session may be the unequal distribution of knowledge in a team. If the current writer has more in-depth knowledge of the subject than the other team members, the person may feel slowed down and wants to continue writing on his own. Here, however, patience and perseverance are required in order not leave someone behind. If someone else is the writer, the expert can share his expertise with the team so that everyone can participate.

• Since many different people work together in a mob session, the solutions to the problems can be varied. It has proven to be the case that each person is allowed to present and discuss their solution approach, usually in a team you will find the variant on which everyone can agree.

In the Flow – Productive in the Mob

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  

---