Mob Driven Development

For most of us, thinking about a mob, we probably picture Italian crime syndicates of New York or Chicago in the prohibition era. Men in suits bootlegging, shooting tommy guns, running protection rackets, smoking cigars and drinking in speakeasies with Frankie Sinatra. Or Marlon effing Brando making an offer he can’t refuse.

‘Make him an offer he can’t refuse’

But the truth is, that’s just our non-native english speakers’ idea of what a mob is, as a quick consultation of Google tells us, it can also mean a large disorderly group of people.

Now think of developers as a mob. Without the rioting and molotov cocktails thrown at police.

What I mean by that is whole team working together on a particular problem solving it collectively.

Something like pairing, on steroids.

Benefits of mob sessions

Apart from the obvious facts that it strenghtens team bonds, and allows us to drink illegaly imported Canadian whiskey, mobbing works on the principle of ‘more eyes see more’.

Oh that sweet illegally imported Canadian whiskey

Simple as that. If you’re learning something by trying collectively, it goes faster and you spot patterns (or anti patterns) you wouldn’t have otherwise.

Another one works especially well in teams where not everyone is up to speed with the codebase, language or coding in general, and we bring the team’s skill bar higher together in a short session.

Good opportunities for mob sessions

In our Android team we like development as a mob on hard problems, new problems or just topics where not everyone is up to speed.

The possible reasons for a mob session include:

making architectural decisions in a team, based on everyone’s experience and by answering juniors’ questions - that was the case with our MVP design pattern

introducing and experimenting with a new library or framework - we did that with RxJava and Dagger 2 as we started using them

planning and kicking off the refactoring or reorganisation of codebase

But not all mob sessions need to be coding sessions per se. If you think of them as get everyone on the same page sessions rather than strictly development, you can use these things to do other cool things as well.

We used one session to improve our technical documentation regarding our build process and bring everyone up to speed with it, at the same time.

Preparation

Ancient wisdom of mafia bosses says preparation is king.

The saying then goes on about how it’s better to assassinate your rival mob bosses and seize their assets preemptively than to wait for their attack, but the punchline is the same.

There can’t be a mob session without some prep. That’s where it differs from an ad-hoc pairing exercise, where you just grab a colleague with no headphones on and ask them to pair with you on a problem.

prepared for some mob coding

First of all, you need to organise everyone’s time. That’s why it’s better to start a week or so before, ideally before the sprint has begun so you can plan it in (if you do sprints).   Make sure you talk to the team about it, explaining the reasons for doing a mob session, and informing your product owner that you’ll be taking n-points for a mob session that will take 3 hours of everyone’s time. In practice, it’s good to have a large chunk, like half a day, but rarely less than 2 hours.   On a team of 4, that’s effectively 2 person-days of work. Sounds quite costly, because it is, so use it wisely.

Have a topic and goals that are clearly defined. Otherwise it’s going to be just another meeting and that’s the last thing we want. So let’s say we’re trying a new library, or concept.   For Android, the new data binding library sounds good, so we’ll grab that, and the goal is be to have a prototype feature using this library at the end of the mob coding session, so that anyone in the team can start using these concepts right away, in the same fashion.   Get everyone to read up on the topic, and make some preparation. Don’t have to be much, an hour per person will suffice. (That practically counts towards that half day as well). Read blogs, experiment yourself, share cool findings with the team so we can all hit the ground running.

Get a room. (And other things)   Book it. One with a working projector. And power sockets. Make people bring laptops - at least more than half as many laptops as there are people, but ideally one for each person.

In the session

Like with pairing, it’s all about the discussion. One person drives, the rest are talking, and googling.

After a bit is done, change the driver. Let everyone have a go at it, and don’t hog the keyboard.

If you’re not driving, use your computer for bringing up content relevant to the discussion, something you can help the person who’s coding with.

Also, an extremely important point - make sure you’re having fun. This is not a business people meeting. Observe them giving you jealous glances as you’re actually in a meeting room having a good time and working on real stuff. It’s priceless. For everything else there’s Mastercard.

Danger (high voltage)

watch out for stuff

Number one danger with mob sessions is it turning into a meeting. If you do the prep correctly that’s not as likely, but it’s still best to be vigilant about it.

If you’re the person organising the session, just keep an eye on people paying less attention, and kindly ask them a question or two, just to get them back into the loop, or suggest they take the driver’s seat next.

Also, suggest regular breaks, as these things can be pretty intensive, and 5 devs in the zone collectively can forget about time and space, let alone the need for food, water and toilet. Be clever.

Lastly, don’t overdo organising the mob sessions. Make sure the entire team benefits from it, otherwise you’re just wasting real time.

tl;dr;

• Mobs are not just the well dressed people smuggling whiskey and running protection rackets
• Developer mobs can be really effective
• Just get people in a room working on the same problem
• Pick a good topic, keep it fun, let everyone take turns driving and don’t let it turn into a meeting