Two Rules for Mobbing Success

Mob programming involves gathering the entire development team in a shared space, giving them a single development machine and asking them to build software collaboratively. How bizarre! The word “mob” makes the situation even more outlandish, with its connotation that team members do whatever the heck they please.

Indeed, the practice of mobbing doesn’t really come with a lot of rules. Guidelines for mobbing are, for the most part, common sense: We stay engaged, demonstrate respect for our fellow team members, solicit input from the whole team and continually seek to improve our ability to deliver high-quality software. You’d dream up these guidelines quickly enough yourself, were they not already recommended by such canonical “mobsters” as Woody Zuill.

The phrase “entire team” is a rule-by-definition — when we say we gather the entire team in one place, we mean the entire team. We invite testers, programmers, designers, managers, analysts, security folk and all others with a part in building our software. We expect them all to contribute.

But is mobbing in front of a single computer really a free-for-all? Can anyone grab the keyboard and go to town, coding away for an hour or two while everyone watches?

Were that the case, a mob would undoubtedly be boring or frustrating for most observers. A manager watching such an unstructured team would quickly decide that mob programming is one of the stupidest ideas ever foisted on software teams.

What is mob programming?

Before we go any further, let’s take a moment to ensure we share our understanding of what mob programming is and how to make the most of it. As the Agile Alliance explains, mob programming is “… a software development approach where the whole team works on the same thing, at the same time, in the same space, and at the same computer.”

Mob programming is a close relative of pair programming, except that the mob is usually far larger than two members.

“Swarming” is much like mob programming, except that multiple keyboards might be in use simultaneously. Swarmers generally have several typists driving several screens all focused on different parts of the same problem.

Mobs tend to undertake a wider span of development activities than individual or pair programmers, who generally confine themselves to programming: mobs often take on visual design, documentation, and other development tasks distinct from programming.

These collaborative patterns have been in use long enough to recognize some of the hazards to which each is subject. We’ve seen pair programming, for example, suffer domination issues. One party to the pair grabs the keyboard and slogs through their dreamed-up solution while the other pushes back their chair. Disengagement grows, with this “process smell” known as a worker-rester situation. With worker-rester, the effectiveness of pairing decreases to the point where it does indeed cost twice (or more!) as much to deliver software.

In order to succeed, as in pairing, mobbing must engage all parties involved. Otherwise, those not involved represent pointless overhead. The benefit of engaged mobbing is far from pointless: We celebrate the dramatically better solution that true collaboration can yield.

To take full advantage of mobbing, make use of the talents of everyone on the team, and deliver better software sooner, here are two essential rules to follow for mobbing success.

Rule #1: The Driver Doesn’t Navigate

This first rule implies that mobbing involves two roles: driver and navigator. The driver controls input to the computer (usually a keyboard and mouse). The navigators — the rest of the team in the mob — provide continual direction to the driver. The driver’s primary job requires listening to the mob and translating their directions into software, tests, scripts or whatever other solution is needed.

Llewellyn Falco describes this form of interaction as strong-style pairing. “For an idea to go from your head into the computer, it must go through someone else’s hands,” Falco says. If you’re currently the driver at the computer and you get a new brilliant idea, you must relinquish the keyboard and describe your brainchild to a new driver.

This rule eliminates most of the risk that a mob session will culminate in a bored audience. A dominating sort can’t commandeer the wheel and decide they’re going to drive us wherever they feel, and everyone else isn’t stuck watching from the back seat in sheer boredom (or terror).

Rule #2: Use Timed Rotation

Each driver should have only a short, fixed amount of time (typically from four to seven minutes) at the keyboard before relinquishing the controls to a new driver. We keep a timer continually going to ensure that everyone on the team rotates to be the driver. Some teams use a physical kitchen timer; some use software designed specifically for mobbing use.

With a timed rotation, everyone has a fair shot at being the driver and at providing input to the driver. Without the timer, we’d see increased risk that participants disengage. I guarantee that being at the wheel and having a mobster tell you what to do next will keep you alert!

This practice is important for other reasons, too. Everyone in the room should be increasing their skills at devising solutions as part of the navigating mob. Everyone in the room should also be increasing their ability to listen and translate directions into working solutions. Mobbing allows a novice or new team member to immediately begin contributing and interacting with the rest of the team.

Driving Out Fear

An advantage of short rotations is that you’re not “on point” for long. Many of us understandably feel intimidated by the prospect of having to show our dev chops — or lack thereof — in front of our peers. Half a dozen minutes or so, and you’re up out of that hot seat.

The mob driver’s seat really isn’t much of a hot seat, anyway, because of rule 1: The driver doesn’t navigate. As the driver, you needn’t have the answers; in fact, you’re not expected to. You must only listen and focus on getting better at translating concepts to code.

Regardless, a good team remembers that we all have fears. Some people will need a decent amount of sensitivity from their teammates before they can thrive in a mobbing environment. Be patient and consider all ideas without attack.

It might take a few weeks, but your team members will eventually overcome their fears as they learn that their best results come from supporting and helping each other. Distributed mobbing, a necessity in pandemic-era development, is even practical. Just remember to comply with these two rules to create mobbing success.