The Unruly Mob

At work, we’ve always pair-programmed all our production code, so we’re already pretty bought into it being a good idea to have multiple people working on a single problem. I previously wrote about some of the reasons for pairing.

Mob Programming

Recently, having inspired by a talk by Woody Zuill, we decided to give mob-programming a go, and our experiences so far have been very positive.

Mob programming is having the whole team working on the same problem, at the same time, using a single workstation.

We’re not using it all the time right now. We’ve started doing Mob-Fridays as a way of regularly working together as a group instead of pairing. We’re still pretty new to it – only having done it for a few weeks, but I thought I’d post some of my observations thus far.

Setup

Here’s our setup. We all (4-6 of us) sit round in a semicircle, as we would when having a group disscusion. We have a big 124cm HD TV for everyone to see the code on, and a 76cm monitor for the person at the keyboard – positioned perpendicularly to the TV. This allows the driver to see the rest of the team. We also have a large whiteboard behind the team (just out of the photo) which we can scribble design ideas on.

We have been using strict 5 minute rotations for driving. Every 5 minutes the person with the keyboard relinquishes it and another team member takes over. This gives us a rhythm for continuous deployment (We try to deploy to production after between 5-10 rotations – i.e. at least once an hour). 5 minute rotations keep it very fast paced, and keeps everyone engaged.

We’ve also tried including team members with specialities in our mobbing sessions, including having them drive. We’ve had mob sessions with our product manager and UX specialist. I think it could be interesting to include our internal team customers in the future.

Why?

Efficiency

You may be thinking that this can’t possibly be efficient. Surely 5 or 6 people working individually can get more done than working together, constrained by the speed that one person can type and they can communicate. I think you might well be right, but the amount of stuff a team can get done (throughput) is not necessarily what you want to optimise. Often the speed at which we can get from where we are now to achieving a business goal is more important (latency). Anything we can do to get there faster is a good thing, even if it’s less efficient in terms of throughput.

Regardless of the efficiency of cranking out code, mobbing provides several efficiencies.

Mobbing eliminates a whole class of meetings – removing synchronisation points that slow down developers working independently. There’s no need for detailed design discussions in advance of starting on implementation, because everyone can contribute to the design while working on it. There’s also no need for traditional standup meetings to catch up on what is going on. When working together as a team everyone knows what everyone has been doing and is going to do.

There is also less time loss due to interruptions. People seem more reticent to interrupt a group session than an individual or pair – We pause to answer any questions from outside the team and have a break after each person in the team has had a driving session. It’s also less disruptive when someone’s phone rings or someone needs a toilet break. They can just nip out of the mob and let the mob continue. When pairing, work often stops when these small interruptions occur, and a lot of the context is lost.

A combination of the 5 minute cadence and having more people involved also seems to help avoid wasting time doing things that we don’t really need, which helps us move faster.

We’re also able to more rapidly adapt to what we discover in the course of implementation. Our preconceived ideas of how we might build a feature don’t always survive implementation. We often learn along the way that our original plans won’t work. When pairing we often convened team huddles to discuss these issues before continuing. When working as a mob we just press through them unfazed, without any delay waiting for input from others.

Communication

Mobbing seems great for making significant architectural changes to the system. Things that you need everyone on the team to be bought into, and ideally want as many pairs of eyes on to avoid problems. For instance, we have been mobbing on a new design for a system that processes money. It’s a core technology for us, that it’s important for the whole team to understand, and since it deals with processing money mistakes could be costly.

Mobbing also completely eliminates one of the problems I’ve observed with pair programming – that purity of design can be lost when you rotate out one of the developers from the pair and swap someone in. When mobbing everyone on the team gets to see designs through to the end.

Another reason for mobbing is that it’s great fun. Doing something together as a team makes us a better team. Mobbing is a teambuilding activity that’s actually achieving what we would be achieving if we were working individually.

Summary

Do try mob programming yourself. It’s great fun, should help you be a better team, and an effective way to build software.