Blog Authors: Nicole Selig, Dane Acena, Jesse Gallardo, Lakshmi Galla, and Blake Steel
For unique situations, sometimes you need unique solutions. Our internship has been anything but what most might consider ordinary. We were five interns thrust into a remote work environment due to the worldwide pandemic. We wondered how we would be able to work, collaborate, and learn under such conditions. In our first week, our tech lead introduced us to a new concept: Mob Programming.
“Few teams at SEP have done it yet,” he said. “but this is the perfect time to try.”
So, we’re here to tell you about the results of it. In fact, we mobbed on this very blog post!
What is Mob Programming?
Mob programming a software development process involving more than two people. The whole team works on the same thing, at the same time, on the same computer. One person acts as the typist, or “driver”, which allows the rest of the team to act as “navigators”, running ideas through the typist. We start timer (like this one here), and after a set amount of time, a new person takes over the driver role. This way, everyone has control and input over how to write the code, and everyone gets an opportunity for a mental break.
Traditionally, mobbing is done in the same office space with a single computer. We found it was easy to implement mob programming remotely. The driver shares their screen on Microsoft Teams. When the driver’s time is up, they will push the code to the working branch of the repository. The next driver will share their screen to continue working off the previous driver’s code.
The Challenges
When 5 individuals who know nothing of each other come together to solve a problem they know nothing about, there are bound to be roadblocks. Here are a few we ran into:
- At first, we only switched drivers if a substantial change was made. If one or two people dominated the conversation or the code for a lengthy time, it was a struggle for the others to stay engaged. We decided to use a timer and to push code promptly when our time was up, regardless if the code worked or not. This kept the work fast-paced and everyone was better able to stay focused.
- Communicating code over a conference call was difficult at first. Saying out loud each character the driver should write was tedious and a little ridiculous. As we became more familiar with the tech stack we developed our own “language” for communicating about the code. We also shared lines of code through the Microsoft Teams chat feature.
The Benefits
As the weeks went by, we became cognizant of the benefits we were reaping from mobbing. So much so that we chose to mob every chance we could!
- There was no waiting for answers or back and forth conversations. Since we were all in the same Teams call, we were always on the same page. This led to much more agile problem solving and decision making.
- Everyone had a different viewpoint or expertise in our project, and this made problem solving a breeze. With 5 of us, there was always a chance at least one person on our team would know how to solve a problem or how to find the answer.
- We never had to merge commits, so no merge conflicts!
- Everyone learned every aspect of the project at the same time, at the same pace. This was extremely valuable for us as interns. We feel that dividing up the work would have some of us left out of crucial experiences.
- Mob Programming leveled up our communication skills. We learned how to approach our interactions with kindness, consideration, and respect.
- It was fun! We found mob programming to be an important team building exercise. We got to know each other’s strengths and how to best support each other.
Daily Retros
To mitigate some of the challenges of mob programming, the team had quick “retros” at the end of each day. Most of these retros focused on how we worked, rather than what we worked on. Everyone was able to voice their comments or concerns about our processes. After discussing what went well and what went poorly, we came up with ideas on how to continue improving our workflow.
Our Winning Routine
About three weeks in, we settled into a routine that worked for us. We logged in at the same time every day, decided what to work on from our list of tasks, and got to it. One of us volunteered to be the first driver. The driver spent 20 minutes at the helm while the others brainstormed. Then we rotated to the next driver, repeating the process until we broke for lunch or ended our day.
We usually had aligned work hours, except for a few occasionally taking lunch breaks at different times. They would drop out of the mob and come back without much fuss. Below is an example of notes from one of our retros:
We found the daily retros to be crucial to our success, and we highly recommend doing them. No two projects or teams are alike, and it’s up to the team to self-organize and determine what works best for them. We didn’t have to mob every day. We chose to.
If you’re interested in mob programming in a remote environment and want to learn more, this article will help you get started!
Build awesome things for fun.
Check out our current openings for your chance to make awesome things with creative, curious people.
You Might Also Like
