* This article is a translation of the Japanese article written on December 4, 2021.
Introduction
Hello! This is @ysk24ok, from the Merpay ML Platform Team. This article is for day 4 of Merpay Advent Calendar .
In this article, I talk about how we implemented mob programming to handle tasks as a team.
What is mob programming?
In Code with the Wisdom of the Crowd, mob programming is defined as three or more people sitting at a single computer in order to work together on solving a problem. It is said that this practice began rising in popularity all over the world after Woody Zuill (Hunter Industries) started talking about it during conferences and other industry events from around 2015.
In mob programming, a single person is given the role of typist, while the rest of the group is the "mob." The typist role rotates every 10 minutes. The rest of the mob generally does not write any code. Instead, they provide and explain ideas to solve problems to everyone involved (including the typist). Once the typist understands an idea provided by someone else in the mob, they then write out the code.
In my team, we use mob programming as follows.
- Before we start mob programming, we share assumptions and details on what we want to accomplish during the mob programming session. We do this to make sure that everyone is on the same page.
- Next, we come up with a strategy describing how we can accomplish our mob programming goals. Organizing a procedure in advance makes it easier for everyone involved to get a solid idea of the code we’ll be writing, and it helps prevent having to go back and redo work while coding.
- Next, we begin the actual mob programming session.
- Finally, we determine what to do once the mob programming session is over. This includes determining who will take over any remaining tasks, and whether we need to schedule more time later on for another mob programming session.
Background
The company resumed hiring at the beginning of 2021. I was hired along with another individual, and it soon became clear that there was a wide gap in knowledge between us and the other team members. This caused all sorts of problems. Members exercised a high level of ownership over their work, but this made it hard to determine what other team members were working on. It also took a long time for any given member to adequately understand the situation when asked by someone else to review their code.
I used mob programming at my previous job, and I knew that it could be effective in resolving issues with siloing. I decided to introduce the concept to the team.
Benefits of mob programming
It’s only been a few months since we introduced mob programming (in December 2021), but it’s been received well by the team. In fact, it’s become somewhat of a best practice here. We continue to do mob programming for around two hours a session, twice a week.
Sharing knowledge reduces issues with siloing
If a mob programming session includes people already familiar with the code being written, you can get advice and learn from them as you work. This helps to share knowledge and can reduce issues with siloing. If you’re developing something and you don’t know much about it, you can run into various issues, such as having to spend time getting to grips with existing code, or waiting for responses to your questions from people on Slack or other communication tools. In contrast, mob programming has a very high flow efficiency because everyone involved is right there (I talk more about flow efficiency later on in this article).
The entire team works together to learn new things
Engaging in trial-and-error as a team while solving an issue can help resolve uncertainties, even if you’re working with a new technology and no one knows much about it. This also means that everyone can learn about that new technology together.
Code reviews take less time
After performing some tasks with mob programming, one of the members of the team will be assigned to complete the code, and then another member will be assigned to review it. Everyone worked together on understanding the problem and agreeing on a solution, so the code can be reviewed quicker.
There is a greater sense of team unity
Prior to introducing mob programming, individual team members tended to work on tasks on their own, and we were less of a team and more of a collection of individuals. Mob programming has given us a greater sense of team unity, as we can all work together on a single task as a team. I think this has been especially important for us, as we haven’t been able to go to the office and engage in team-building due to the COVID-19 pandemic.
Tips on introducing mob programming
Switching from resource efficiency to flow efficiency
"Resource efficiency" basically refers to the utilization rate of developers. In contrast, "flow efficiency" is the speed at which a single task is completed. A policy focusing on resource efficiency would assign a single developer with multiple tasks, in order to fill up their working hours as much as possible. A policy focusing on flow efficiency, however, would assign a single task to multiple developers, so that the task can be completed as quickly as possible.
I’ll refer to the slide above to explain. A policy focusing on resource efficiency (top of slide) would assign separate features to each of the three developers and it would therefore take three weeks to release any of the features. In contrast, a policy focusing on flow efficiency (bottom of slide) would assign a single feature to all developers, allowing that feature to be released after only one week. Of course, this is just a simplification. However, if we can increase flow efficiency, it would then only take a little over one week to release the feature, even if the utilization rate of the developers drops; in other words, we could still release earlier than having everyone work separately.
Members of our team had all worked independently (focused on resource efficiency) prior to introducing mob programming, and some people were concerned that they would struggle to make progress on their work if we introduced mob programming all of a sudden. Mob programming is a practice that focuses on flow efficiency, so it can be difficult for people used to the resource efficiency approach.
Our team has been using the Scrum framework for development, so we began by defining sprint goals that we hadn’t set before and using mob programming to achieve those sprint goals. This meant that we could focus on achieving sprint goals as a team, which allowed us to increase our flow efficiency.
Flexible mob programming
Although mob programming has some very appealing benefits, some tasks simply aren’t suited to mob programming. Having time to sit by yourself and think something through carefully is just as important. This has led us to skip mob programming for some sprints.
On the other hand, there are some tasks other than programming that can be handled as a mob effort. We typically do this twice a week, but there are also times we do it more often. We make sure to keep mob programming flexible, in a way that works best for us.
Using VS Code for remote mob programming
It’s recommended to share a single PC when holding a mob programming session. However, members on our team generally work from home, so this isn’t an option. Instead, we use a plugin called VS Code Live Share to share a single source-code editor during our mob programming sessions. This allows everyone to participate in mob programming using whatever development environment they prefer, although we have to restrict ourselves to using only VS Code to edit source code.
Summary
In this article, I discussed the benefits of introducing mob programming within a team, and I also covered some tips to make the process smoother.
I had used mob programming at my previous job and knew it was a good practice to introduce. Having said that, I was a bit concerned about how it would be accepted by my current team. However, everyone seemed very pleased with mob programming once we introduced the practice, and I’ve been told that people want to continue doing it.
I think mob programming can be difficult to understand unless you actually try it. If you haven’t given it a try yet on your own or in your team, I definitely recommend it!
