Tips and Tricks for Effective Mob Programming

For the last 18 months, the New Relic Insights team has been very focused on mob programming. In this time, we have run into a few hurdles that we had to find our way around in order to keep mob programming productive for everyone on the team.

Use the mob effectively

One of the first things we learned was that we didn’t need the entire mob to solve every problem. Not all problems require a group solution—some tasks are simply too small. Tasks that leave folks standing around waiting are a poor use of the mob’s time. Assembling and preparing pull requests is a good example of this type of task. We decided to take extra time during our planning meetings to identify tasks that our “hero” (the individual on call) or a small portion of the mob could more efficiently handle. The entire mob still reviews any work that is produced by the hero or smaller group before the changes are committed. These reviews ensure that we’re all aware of potential changes and have the opportunity to raise or address any concerns.

Use “learning mode” when mob programming

To get the most out of our mobbing sessions, we decided to engage in “learning mode” as often as possible. Learning mode puts the least experienced or knowledgeable engineer in the driver’s seat, which has a dramatic effect on shortening learning curves. This approach also places the more experienced engineers in mentorship roles, allowing them to spread their knowledge to others. Since our goal is to help every team member achieve the same level of technical knowledge of the product we develop, we’ve found it essential to invest this time and energy in perfecting our methods.

We even created some guidelines so the more experienced engineers on our team can ensure a successful transfer of experience or knowledge.

1. Suggest, don’t dictate: Instead of telling the driver what to type into their editor, we explain what we’re trying to accomplish and then help the driver find the best solution. We’ve found that drivers learn better this way, and they don’t just end up feeling like a stenographer. Whenever possible, we ask questions that lead the driver to discover the answers on their own.
2. Stay focused and be present: Shut your laptop and put your phone away. I’ve struggled with following this guideline—we all have—and I recognize that the distraction almost always affects the rest of the mob. We tell all our mob members to be present, and if you can’t, it’s OK to leave until you can be.
3. Use a timer, but be ready to pause it: We switch drivers every 10 minutes. However, we often wander off implementation into design discussions—it’s unavoidable—so this is when we pause the timer. This is another key guideline of our mob: the time you spend driving should be dedicated to writing the code that helps complete the task, not discussing design solutions.
4. Set specific tasks for each session: When our mob gathers for a session, we first agree on and create a checklist of the tasks we are going to complete, and order them by priority on a whiteboard. This ensures we are all focused on the same task and keeps us moving forward. Additionally, this keeps us aligned with Minimal Marketable Feature (MMF) work, which we can communicate with our engineering and product managers to assure them we’re completing tasks that align with developing small, self-contained features that demonstrate immediate customer value.

Ditch the conference room during retros

The Insights team has also implemented a fairly casual retrospective process. Our retros happen over “coffee walks.” We’ve found that these walks provide a casual, friendly time in which any of us can bring up concerns we have about the mob or our sessions. We developed this casual approach because we wanted a format for identifying areas for improvement or for expressing concerns that wouldn’t require a formal setting, like a conference room. Since each member of our mob brings his or her own experiences to the group, and because we each change over time, regular communication is necessary to keep the process working. It’s also vital to ensure that each of us is comfortable voicing our concerns. In fact, most of the guidelines I’ve been discussing have come out these retro sessions.

It’s inevitable that you’ll hit some snags as you get started mobbing. It will be crucial in the early days that you embrace your team and work together to identify problems, causes, and solutions. Treat these moments as hurdles, not blockers, and your group will be perfectly fine.

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.