On Mob Programming

I think the idea that stuck with me the most from this year’s Craft Conf was Mob Programming. It’s like pair-programming, but much better. Here’s how and why.

Rules

There’s only one computer that we write the code on and there’s only one person at one time that’s allowed to touch it — the Driver. Their role is to type in the Mob’s ideas.

If the Driver were following what everybody in the Mob is saying, there would be chaos. That’s why we have the Navigator, whose role is to decide which of Mob’s ideas we’re gonna use now and tell the Driver what to do exactly. Once the team gets accustomed to mobbing, Navigator will probably have less and less to do. However, in the beginning, when the team is learning the dynamics it’s useful to stick to the rule that the Driver only listens to the Navigator. It makes sure also the quieter teammates have their say.

The rest of the team forms the Mob. They’re responsible for actually solving the task that’s in front of them, by generating ideas and disussing them. Although Navigator is free to do anything that the Mob does, the Driver should refrain from doing so. This rule helps to make sure any idea passes through other person’s hands to get into the code. If Driver were to join the Mob’s discussion, sooner or later he’d resort to saying: “Just let me show you” and implementing his solution — throwing the whole discussion off balance.

These roles are by no means permanent, Mob should frequently switch (maybe every 5-15 minutes) between the roles: Navigator becomes the Driver, Driver joins back the Mob, next person from the Mob picks up the Navigator’s responsibilities. Having regular switches where everyone passes through every role helps spreading the knowledge and letting everyone participate.

Of course, rules are meant to be broken. Once the team gets comfortable mobbing they might decide to ignore some of the rules while introducing others of their own. It’s a healthy thing to do - adapting the solution to the team’s preference. The only risk is doing it before you give the “standard” version a solid try.

Benefits

There are various benefits to mobbing. It helps to build common code ownership. We no longer have a situation that a particular piece of code “belongs” to somebody and other people are afraid to change it when they’re on holidays.

Knowledge spreads better — be it particular syntax in the programming language we use, tools we use for debugging, viewing documentation, etc., or any tricks people might use in their daily workflow. If a Driver does something on the big screen in front of everybody, those things are in the open and anybody can introduce them into his own workflow. Also, anybody from the Mob might help simplify a task by offering an alternative way of doing things to the Driver, be it a useful git shortcut, or a deploy strategy.

Mobbing keeps the team focused on what’s important. They choose the most important thing from their backlog nd concentrate all their effort on getting it done. This also means that features get delivered faster - in terms of the time when the work has been started and when the feature was done. It helps with planning the roadmap as the team’s results are more predictable.

Also, any debugging is easier. You don’t have to wait for an appropriate time to ask your teammate a question if you get stuck, because the whole team’s alongside you, working on the same task.

Why is it better than pair-programming?

You might say that most of those benefits we can also get from pair-programming in rotating pairs. That’s probably true and the teams who pair-program on a daily basis don’t see as many benefits from adopting mobbing as teams where everybody works on their own. However, mobbing has a few advantages over pair-programming.

For one thing, it’s less intense. When you pair-program for a few hours you feel exhausted, as you’re operating near your 100% all the time, trying to keep up with your partner or lead him. When mobbing you’re free to let the others take over for a while, limiting your suggestions to your area of expertise. It allows you to rest a little bit and recharge while still participating.

It’s also less intimate. Unless you have really fancy pair-programming setups in your office (and few companies do), you’ll be forced to sit close to another person for along time, sharing the same display. Some people might not be comfortable with that. Other people might have health (back, for instance) issues that prevent them from doing so. With Mob programming you’re forced to use a bigger screen anyway, so everybody gets to sit however they feel comfortable.

Also, in some team there might be a situation when people form “permanent” pairs they program in, limiting the knowledge sharing to only those two people. In case of mobbing, the whole team reaps the benefits.

Trying it yourself

If you’re interested, it’s easy to try it in your team. You just need to find a conference room where the team won’t be disturbed (or disturbing to others!), a big screen and an interesting tasks that needs to be implemented across your whole stack (for example a feature that changes both the frontend, backend, maybe also changes in the database). The last thing is important so that everybody feels they’re contributing and not wasting time on something they’d do faster on their own.

I encourage you to give it a go, good luck and have fun!

Written by Wojciech Ogrodowczyk who takes photos, climbs mountains, and runs Brains & Beards to help companies deliver better mobile applications faster.