Dieser Artikel ist auch auf Deutsch verfügbar
Remote mob programming is a method of software development that brings the concept of mob programming to distributed teams. With the spread of COVID-19, distributed teams became increasingly common both in Germany and around the world. Woody Zuill describes mob programming, also called software teaming, as follows: “Mob programming is a software development approach where the whole team works on the same thing, at the same time, in the same space, and at the same computer.” Mob Programming – A Whole Team Approach by Woody Zuill, Woody Zuill, July 2014, Agile 2014 Conference
Remote mob programming adapts this method for distributed teams by creating a virtual space where the team can meet and write code together. Remote mob programming is not a self-contradiction. It is a new style of collaboration that combines the advantages of both methods.
How does mob programming work?
But what is mob programming anyway? Imagine that you and your team are working on a task, but instead of everyone working on their own, the entire team works together on it. The computer screen is projected onto a wall, and one of you, the typist, is sitting at the keyboard and typing in what the rest of the team decides on as they discuss. Everyone in the rest of the team has the opportunity to participate in the decision-making process and influence the result. The typist, however, is intentionally excluded from decision-making since they would otherwise have the power to type what they want without it first being discussed in the team. This ensures that there are no solo efforts, and the members of the team must first discuss and agree on the desired solution.
What is remote mob programming?
Remote mob programming brings mob programming onto the internet. A virtual space, such as a Zoom meeting, replaces the physical room. The team meets there to continue the software development together. The typist shares their screen and can be viewed as a high-level API for the development environment. They do not participate directly in the discussion and identification of a solution. Instead, they wait for instructions and only write code when asked to do so by the rest of the team. The more experience the typist has, the more abstract these instructions can be. An inexperienced typist could receive exact instructions of what to type. An experienced typist, on the other hand, would be told simply to write a test that tests feature X with parameters Y. When the typist is not receiving instructions from the rest of the team, they should simply meditatively gaze at the blinking cursor since any movement of the mouse could distract the rest of the team from their discussion. The role of typist is regularly changed so that the person can once again participate actively in the problem solving. For a four-person team, it has proved to be good practice to change the typist every ten minutes. This means that everyone in the team will become the typist again after no more than a half hour, ensuring that the team members remain focused on the task. With remote mob programming, the process of changing typists is somewhat more difficult since it requires more than simply passing the keyboard to the next team member. One solution is to pass on the source code via Git. To avoid the need to go through all the effort of a manual commit and wait for the next typist to check out the code, you can make use of the command line program mob. Mob bundles the handover process into simple commands. This makes it possible to complete the handover of the code in fewer than ten seconds. To remind you to swap at regular intervals, mob also provides a timer.
Continuous progress and high quality
The entire team works on a single feature so that there is never more than one work-in-progress ticket. The focus then always lies on the most important ticket. To help maintain this focus, remote mob programming strives to avoid any waiting times. After all, waits often lead to context switching, meaning additional time will be required to get back up to speed. This makes it especially important for the team to operate as independently as possible. It is therefore absolutely essential to clearly delineate the software boundaries and ensure independence from other teams as well as to prepare the tickets properly so as to avoid dependencies on other teams.
Scheduled meetings are often imposed on the team as a way to coordinate dependencies with other teams, for example. However, the team always acts in concert, even during meetings. The large number of participants in a meeting can have a positive impact on the meeting results since the high cost of the meeting exerts pressure to ensure that it is executed as efficiently as possible. If it is not possible to arrange the meetings more efficiently, the team can also send individual delegates to a meeting. The team will also begin to question the need for some of its own meetings. The daily scrum, for example, is a meeting that becomes unnecessary with remote mob programming because everyone in the team already knows the current status. If the product owner needs an update on a topic, he can simply come to the virtual team room and get the update.
In some projects, there are architects who make important architecture decisions. With remote mob programming, the team takes on the role of the architect whenever this is necessary. When an architecture decision must be made, the team works out possible alternatives, reflects on the advantages and disadvantages and documents these in an architecture decision record. Because the architecture decision is made by everyone, it is important that individuals can also stand by decisions that might not be their personal preference. The goal should therefore not be to arrive at consensus within the team but rather obtain consent to a solution in which no one exercises a veto. With so many participants, it is often the case that more potential solutions are evaluated, which increases the quality of the solutions considered.
Even during the programming itself, many small decisions are made implicitly. With remote mob programming, these decisions can be made explicit and discussed. Simple errors are also usually discovered directly by the team members while the typist is still typing. This saves a lot of time that would otherwise be lost in debugging or troubleshooting. Plus, a traditional code review is also no longer required since everyone was already involved in the development and had the chance to share their opinion. Nevertheless, it is still worth going through the code one more time after implementing a feature for the purpose of refactoring.
All this produces a very strong focus on the most important ticket and enables continuous progress by reducing waiting times and context switching. This yields a very good time-to-market, which is one of the main advantages of remote mob programming.
Learning from the others
Remote mob programming also facilitates continuous learning thanks to the close collaboration. An initially heterogeneous team will quickly become more homogeneous in this way. This also makes a classic onboarding process superfluous. When a new developer joins the team, he is the typist on the first day. His computer and access are set up together with the team. The goal by the end of the day is for the new colleague to contribute a code change that goes into production. Then they have simply become another member of the team. If there is something they don’t understand, they can ask at any time. This may slow the team down somewhat at first, but the new colleague is able to get up to speed faster overall. After even a short time, they will have acquired a broad knowledge of the specific domain and the application and be able to effectively contribute to the team.
At home, but not alone
The advantages of remote mob programming are diverse: Commuting to work is eliminated. Everyone can enjoy lunch at home with their family. Private appointments, such as with a contractor at home or a visit to the doctor, are also no problem since it is possible to simply leave the virtual room for this time. Even though everyone is working entirely from home, they still form strong relationships with their coworkers. Remote mob programming welds a team together and creates a firm basis of trust. The regular small talk also helps everyone get to know each other personally. Disagreements and conflicts within the team are more easily and quickly identified and resolved. However, there is one disadvantage compared with working asynchronously: The remote mob programming team must agree on a time to start and end work as well as on breaks. To further promote trust within the team, however, it is still recommended to hold regular workshops or in-person team events.
When is remote mob programming not a good idea?
Remote mob programming can be a good approach, but – as with most things in software development – it is not a silver bullet. There are certain conditions under which remote mob programming is of limited use or should be avoided entirely. For example, if the team is distributed around the world in different time zones, it is impossible for everyone to find a shared time window for remote mob programming, making it practically impossible to implement.
Problems and conflicts that already exist within the team often surface quickly when remote mob programming is introduced. These problems may then either be quickly resolved or harden into firm stand-offs that make effective collaboration impossible, creating frustration for everyone. For this reason, remote mob programming should be introduced by a coach, who teaches the method to the team and then regularly guides the team in evaluating past experiences to ensure that conflicts are resolved early.
If a team is significantly dependent on other teams and is not in a position to develop a feature on its own, remote mob programming won’t achieve the goal of a good time-to-market. In this case, it is worth reconsidering how the applications are divided up. Effective remote mob programming requires minimal dependences to avoid context switching that interrupts continuous progress.
Remote mob programming is a style of work that relies on extensive communication. There are some personalities that do not mesh well with this approach since they perceive social interaction as very stressful, making it hard for them to stick at it in a sustained way. People who feel the need to think through problems themselves may also find remote mob programming frustrating. It is therefore best to try out remote mob programming for a limited time as an experiment and then decide as a team whether it is a good fit.
Summary
Remote mob programming is a new and exciting style of work that rethinks remote collaboration and is particularly suitable when one of the main goals of the project is a quick time-to-market and when intensive knowledge transfer is desired. Remote mob programming allows a team to collaboratively create a high-quality product and implement new features quickly by reducing waiting times. However, remote mob programming should not be considered a cure-all. It is important to consider the goals of the team and the project and weigh the pros and cons of remote mob programming in advance to determine whether the personalities in the team are compatible with this style of work.
More information on remote mob programming can be found at remotemobprogramming.org or in our primer. If you would like to try out remote mob programming with your team, you can schedule a one-day workshop at socreatory. If you would like to try it out as an individual along with others, you can participate in a remote mob programming session for free at mobusoperandi.com.