Mob programming involves gathering the entire team in a shared space, giving them a single development machine and asking them to collaboratively build software. How bizarre. The use of the word mob adds to the bizarreness, with its connotation that the team does 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.

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.

We’ve seen pair programming 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 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 derive.

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 they must relinquish 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. Just don’t forget to comply with these two rules for mobbing success.

Watch our on-demand webinar

Get to Know Ranorex Webtestit: Learn how to build robust and reliable Selenium test suites from installation through to execution with Ranorex Webtestit

About the Author

Jeff Langr has spent more than half a 35-year career successfully building and delivering software using agile methods and techniques. He’s also helped countless other development teams do the same by coaching and training through his company, Langr Software Solutions, Inc. In addition to being a contributor to Uncle Bob’s book Clean Code, Jeff is the author of five books on software development: Modern C++ Programming With Test-Driven Development, Pragmatic Unit Testing, Agile in a Flash (with Tim Ottinger), Agile Java, and Essential Java Style. He is also on the technical advisory board for the Pragmatic Bookshelf. Jeff resides in Colorado Springs, Colorado, US.

You might also like these articles