Taming the Mob: An Introduction to Mob Programming

In last year’s Project UpScale, New Relic empowered our engineering teams by giving us more autonomy and decision-making power. As part of the exercise, we asked our to teams to define their working agreements by finishing this statement: “We work best when..." On the New Relic Insights team, we defined several working agreements, but our best decision by far was to pursue mob programming.

Mob programming = pair programming on steroids

In its most literal manifestation, mob programming happens when one computer is shared between an entire development team. As with pair programming, the goal is to regularly rotate the “driver” (the developer at the keyboard) to keep the group engaged and give every participant equal time writing code. As with any development model, there are plenty of variations, but the Insights team decided to use one computer for a six-person team, rotating the driver every five minutes.

Mob programming was new to a lot of us. We were all plenty familiar with pair programming, and knowing how fatiguing that could be, some of us assumed that mob programming would be even more exhausting. But that’s quite the opposite of what we experienced.

In pair programming both participants are fully active in a session, but in mob programming, some members of the group are more active than others at any given time. This is a fundamental tenet of the mob—if you aren't engaged in the current activity, it is perfectly OK to step away. In fact, the mob works best when it encourages distracted individuals to step away before they can distract the group. It's better for distracted team members to leave and focus on something else for a while, and then return when they’re ready to jump back in with useful contributions. This helps the active members of the mob maintain a high level of energy, concentration, and focus.

Mobbing increases social interactions across the team

Since only one developer drives at a time, the other mob members must maintain a high level of intellectual interaction—everyone unites to solve a single problem. This is another important tenet of mobbing—leveraging the group's inputs to form a consensus on design decisions that come from a diversity of opinions. We worried that if everyone came with their own strong opinion, our programming sessions would devolve into shouting matches or six-person arguments. As it turned out, that wasn’t the case at all. We were all so focused on producing the best possible product that we were more than willing to hear and adopt one another’s opinions. When we did face differences that we couldn’t resolve, we relied on management to make the final call.

Another concern for us was how to keep the entire team focused on a single task. To do this, we adopted the concept of the Minimum Marketable Feature (MMF): develop small, self-contained features that demonstrate immediate customer value. This ensured our mob united around a single machine and worked to build a single piece of functionality. Individuals in the team were able to easily identify when the team had diverged from our goal, at which point we could pull ourselves back towards our singular focus.

Setting the rules for the mob

As we worked with this process over several months—mobbing for at least four hours a day—we identified some working rules that made it a positive experience for all members of the team: First, put your phone in your pocket, close your laptop, and be present. Of course, these rules can’t work for everyone all the time—we understood that; it can be hard to maintain focus. And we all have dozens of responsibilities in our daily work that affects our attention. We told each other that, during sessions, it was perfectly OK to walk away from the team for a time. This was particularly important for the “Hero” (our term for the person handling interrupts) since they could be pulled away at any time to handle other requests. In fact, on our team, we decided the “Hero” could keep their laptop open so they could watch Slack and respond as needed. Of course that also meant we couldn’t use the Hero's computer for the driver, since if they left, they’d take the team’s work with them.

Another great benefit of mob programming is group pull request (PR) reviews. On the Insights team, the PR creator walked the rest of us through the changes in the PR while we analyzed the changes and looked for any issues. Once we had reviewed all the changes and understood the deltas, we’d merge the PR. These group-oriented reviews enforced the dissemination of information across the team, and kept us all aware of the changes we introduced.

Mob programming is about quality, not just velocity

Mob programming has been incredibly powerful for the Insights team, and we’ve used it to build a fantastic set of new features for our customers in record time, such as company-wide dashboards. The real value, though, is not just increasing team velocity, but ensuring that we’re building the highest quality software we can implement. We know now that individual engineers, no matter how skilled, can’t build software of equivalent production-ready quality at the same pace as the mob.

Watch the video below to hear New Relic engineers talk about the principles of mob programming and how it's impacted the software development process at New Relic.

Top image by Danny McCarty. In-line photos by Caito Scherr.