Mob programming 101: Getting started with mob programming

Put away your pitchforks — we’re not talking about that kind of mob. Mob programming is a method of programming that’s become increasingly popular in the last 5 years. Woody Zuill, one of the pioneers of mob programming, describes it as “all the brilliant minds working together on the same thing at the same time, in the same space and at the same computer.” 

Perhaps you’ve seen a team at your company mob program, or you want to lead the charge on piloting a mob program practice in your organization, but aren’t sure how to sell it to your team lead. Regardless of your experience level, this is your comprehensive guide to getting a high-performing mob programming team off the ground — from building a workstation to defining roles and overcoming roadblocks.

While there are different techniques to fine tuning a mob programming group, there’s a general blueprint that works well, and there’s typically no reason to diverge wildly from it. These steps below will get you a solid foundation, but feel free to experiment with what works and tailor these steps to the individual personalities and preferences of your team:

The set-up

Unlike traditional programming or pair programming, mob programming brings three and six people together at the same computer (any larger than that and the conversation between teammates can get muddled). The key: Only one person operates the keyboard at a time, while everyone else engages in conversation about code that guides the operator on what to implement. In short, the group writes and owns all the code together. 

The roles

There are two key jobs on a mob programming team: The navigator and the driver. The navigator dictates the code to write, and the driver implements it.

Your navigator leads the discussion among those not at the keyboard. They might ask questions like, “What should the code be here?” or suggest changes to variable names or patterns that could be implemented. The driver sits at the keyboard and applies the instructions from the team. The driver’s role is not to go off and write what they want, but to translate the ideas they are hearing from the navigator and turn them into code. (You can have more than one navigator, but only one driver). Everyone that’s not a navigator or driver is expected to be actively engaged in the discussion as well.

As teams work together longer and get more comfortable with each other, there may be a tendency to get lazy and have these roles bleed into each other. You’ll want to avoid this, and be rigorous about keeping the driver and navigator roles “sacred.” By requiring the navigator to speak an idea or concept instead of just implementing it themselves, you are baking engagement into the development process.

The rotation schedule

After 10-15 minutes, you switch roles to give everyone an equal chance to drive and navigate. This amount of time is long enough that it doesn’t feel like musical chairs, but short enough to keep people engaged so they aren’t waiting too long between turns driving. For example, on a mob programming team of four that does 10-minute rotations, you’ll have 10 minutes being the driver, with 30 minutes in between to be a navigator or group participant.

The work space

The most important consideration for your dedicated mobbing station is: Can everyone comfortably see what’s happening? Most mobbing stations feature a large TV or projector connected to the computer, rather than a monitor; three or four people huddling around a cubicle gets uncomfortable fast. Outside of that, you can stock your station with whatever the team needs to do their best work, be it an ergonomic and traditional keyboard based on what different drivers prefer, a whiteboard for sketching out ideas and even hand sanitizer.

Right now you might be putting yourself in the shoes of your boss, thinking, “There’s no way it could possibly be more efficient to have four people working on one problem than four people working on four problems.” You might think mob programming sounds straight-up crazy. But in actuality, with the right conditions in place, mob programming can be as efficient — and often more efficient — than traditional programming. It just requires thinking about efficiency differently.

Since the Industrial Revolution, we’ve been taught to think of one type of efficiency only: Resource efficiency. It’s ingrained in our culture that busyness equals value. The prevalent perception is if you aren’t busy, you aren’t contributing. But there’s another type of efficiency: Flow efficiency. Where resource efficiency is about how busy you are, flow efficiency is about getting work done. 

Think of a traffic jam. A 5 p.m. traffic jam might technically be making the most efficient use of taxpayer resources that went to building the freeway; after all, you’ve fit as many cars on it as it can, optimizing every inch of asphalt on the freeway. But no one would actually call a traffic jam a good use of resources, because there’s no flow. Without that flow, you can’t ultimately accomplish your goal: Getting home from work at a reasonable hour. 

Every engineer has experienced paradoxical days where “they are so busy, they weren’t able to get anything done.” Mob program solves this problem by favoring flow efficiency over resource efficiency.

Mob programming’s biggest advantage is the potential to reap the benefits of flow efficiency; by just sitting down and knocking out code together, you mitigate time lost to long-standing pull requests and rework. Here are several other related benefits to consider as well:

1. Tight feedback loops

You don’t have to wait for answers to questions when your whole team is in the room. Feedback comes quickly and democratically. This is especially compelling considering the alternative — pull requests — which either come slowly and without constructive feedback (because the developer reviewing your code is too busy with their own work), or create inefficiency when the original work needs to be drastically revised.

2. Collective code ownership

Because everyone participated in making it together, there's inherent ownership right out of the gate. With collective code ownership comes consistently higher quality code, because 1) It’s harder to let subpar work slide when multiple people are putting their name on a piece of work 2) You’re getting the best ideas and experience from a group of people instead of just a single developer, and 3) Fewer mistakes get made when everyone has their eyes on the same thing at the same time. 

3. Fewer and shorter meetings

With mob programming, the kind of stand-ups where you report on what you worked on become useless; your team knows what you worked on, because they worked on it with you! Instead of check-ins, you can use meetings to plan and discuss priorities.

4. Flexibility to step away

If someone has to step away for a meeting or take a day off, the work doesn’t have to stop, because it’s not locked up on any one person’s computer. This flexibility extends to when someone is just having an off day, or is taking a vacation. Mob programming compensates for any interruption that would normally slow down development.

5. Speed

When you combine all the above benefits, it really boils down to one thing: Developing software quickly. It may take longer for the initial creation of the code, but because it’s higher quality, you don’t have to do as much rework or deal with merge conflicts and knowledge silos. You’re just focused on getting work done.

Like any programming methodology, mob programming has a few disadvantages. Being aware of them can help you mitigate against the roadblocks you might face. Here are three common drawbacks to mob programming:

1. The perception barrier

The biggest disadvantage you’ll find with mob programming is that it’s hard to change people’s perception about efficiency. We’re accustomed to thinking of resource efficiency in terms of busyness and visible production. Because of this, it may be difficult to get buy-in from a manager to get a mob programming practice up-and-running at all — and if you do, your leash for proving it out as a successful program might be extremely short. 

2. Remote work

It’s frankly harder to mob program when all or part of your team is remote. Mob programming works because everyone’s engaging in conversation together and sitting together, having roughly the same social experience. Video conferencing can certainly make it possible, but you still miss out on a lot of context and nonverbal cues when you aren’t in the same room. It can quickly become a subpar experience for remote teammates, who might then be tempted to take a more passive role in the discussion.

3. Hiding or deferring

In some ways, mob programming exposes each developer. Some developers on the team may not feel confident, or might be stricken by imposter syndrome, so they don’t participate when they aren’t at the keyboard. To work through a situation like this, try pair programming with that developer to boost their confidence, or even let them code on their own for awhile on tasks that can build up their confidence.  

If any of these concerns crop up as you implement mobbing in your organization, try mob programming on a trial basis, or use it for “all hands on deck” situations as a way to prove out the concept before diving in all the way.

It hopefully isn’t a surprise at this point, but mob programming is inherently social — and being social in a mob setting requires practice! People are messy, complicated and imperfect, and that’s no different now that you’re all working together on the same code. Some teammates may not initially be easy to work with, or you might have clashing styles. But the only way for the mob to thrive is through collaboration, so you need to ensure everyone has a voice for it to succeed. 

This social aspect might cause you to wonder how mob programming works with introverts — or developers in general. Frankly, many engineers didn’t get into the profession to do group work; they’d just as soon prefer to throw on headphones and work alone. As it turns out, most introverts don’t mind speaking up in a small group, and actually prefer it when it’s focused on talking shop versus engaging in small talk.

Mob programming won’t work for every company or every team, and that’s okay. But if you’re ready to maximize your engineering organization’s flow efficiency — to get the best out of your team, not just the most — it might be time to grab a pitchfork and get to work.

This article is adapted from the Pluralsight LIVE 2019 breakout session, "2.5 Year of Mob Programming with Allan Stewart." To view the entire Pluralsight LIVE 2019 Software Development Path — with more than a dozen sessions on Docker, the Lean process, Progressive Web Apps, blockchain and more — click here.