How to use Mob Programming at the rescue of Pair Programming burnout

Full-time pair programming burns introverts out. Regular mob programming sessions yield the same benefits but are more sustainable.

As many, I got into pair programming through eXtreme Programming. I started pairing at my first XP project, almost 15 years ago, in a large bank. Since then, I’ve tried my best to find XP projects to work on. I had to take a few ‘traditional’ programming jobs though. As a consequence, I’ve alternated periods of intense pairing and solo programming. The longest streak of full-time pair programming I have done was around 3 years.

What’s great about pairing

Given enough eyeballs, all bugs are shallow. Linus Law

With this experience under my belt, the advantages of pair programming are obvious to me.

• 2 pairs or eyes catch more bugs than 1. Pairing improves quality and reduces bugs.
• Better skills. It’s natural to learn from each other when pairing. It just happens. The more senior or expert developers might have to slow down and get used to this new ‘mentor’ attitude. But it’s a habit worth taking.
• Better team work. People skills will improve while you pair. You will also discuss coding conventions. It’s going to be easy to raise a point to the team for a pair than for a solo programmer. In the end, everyone starts working more like a team. Today, I cannot feel part of a team that does not pair program!
• Smaller code base. In the end, all this knowledge exchange increases code re-use. When pairing, we’re cutting the risk of re-writing something because you did not know it existed by 2.
• All in all, it’s just more productive! I know some studies say that it’s 15% slower. In the long run, though, all these improvements compound, and more than make up for these 15%. I’m not the only one to say so.

You might think that pair programming is ponies and unicorns…

The problem with pairing

💡 Full-time pair programming burns introverts out!

Given the choice, I’d always go for the pair programming job. It’s so much more productive that it annoys me to work any other way. I’m an introvert though, and after a few years, it wears me out. This might explain why I’ve been in and out of pair programming for 15 years!

I’m not alone to think this way. Erik Dietrich comes to the same conclusion in Should You Take a 100% Pair Programming Job?

What should we do then? How good is a practice if it’s not sustainable for half the people? There’s an agile soundbite that says “If it hurts, do it more often”.

More than full-time pair programming? The only thing I can think of is mob programming!

Mob programming in the morning

All the brilliant people working on the same thing, at the same time, in the same space, and on the same computer. Woody Zuill, mobprogramming.org

I’ve been working as a technical coach for a few years now. I started mobbing as a way to coach all the team at the same time. It’s a lot more time effective to coach through a mob than an individual pair.

I often have 3 to 4 mob sessions within a single week. Up to now, I never felt it was burning me out.

Other teams have also adopted this work schedule. For example, the cucumber pro team has been doing this for a few years now.

From Cucumber pro team Far from the Mobbing Crowd presentation at QCon London 2016, available on InfoQ

How is it more sustainable for introverts

Here are a few key points:

• If you mob program for half day only, you get regular solo time to recharge batteries
• There is less personal involvement in a mob than in a pair. When a pair disagrees, it can easily slip into a me versus you argument. This is lot less likely to happen in a mob. When a mob disagrees, it usually tries to identify tradeoffs or experiments.
• Mob programming favors strong style pairing. It means that the driver only types what he understood from the rest of the mob. It makes the driver’s job the easiest! Unlike the driver in a pair, who can feel scrutinized by his buddy.
• Finally, mobsters use a timer to switch the keyboard. It’s less likely for a control freak to keep the keyboard all the time.

What about effectiveness?

Even though we don’t all agree, we need a high dose of pairing to reap all the advantages. But even a small dose of mobbing brings huge advantages. I’m always astonished by the ton of knowledge sharing that goes through mob sessions. Even in teams where people have been working together for years! Samuel Fare explains it the science behind mob programming.

Suppose you are mob programming 10 hours per week. It’s quite realistic to find topics that will leverage on everyone being together. 

Bonus: easier to sell to management

I haven’t seen many forbid morning mobbing:

• They understand the value of knowledge sharing
• They get that some complex tasks are better dealt with by all the team. For example: complex design or architecture, complex refactoring.

Need some social proof? Read Rebecca Campbell, a manager at New Relic explain what she loves in mob programming.

Remote mobbing

Even though we did remote pair programming, today, it remains very uncommon. Surprisingly, it does not seem so with remote mob programming! Many teams are embracing the practice:

• The cucumber pro team again
• There is a website dedicated to remote mob programming
• I do it at Murex with teams I coach
• I know a few teams enjoying remote mob programming

I’ve seen it myself, remote mob programming is a great way to keep team spirit within a distributed team.

💡 Remote mob programming works surprisingly well!

One more thing…

There is one topic where remote mob programming becomes magic!

It’s about inclusiveness and diversity!

People from anywhere can work together. People from different countries and cultures. Busy parents can work with startup-kids. People can setup their desk to what suits them best! The cucumber pro team (again) experienced and wrote about it themselves.

As remote work is the future, remote mob programming might become more and more relevant.

How to start?

Whatever experts say, nothing beats first-hand experience. Give it a try and you’ll know if it works for you! It’s also a lot easier to get people to try than to jump-in.

Here are a 4 steps to put regular mob sessions in place in your team:

1. Run regular team coding dojo sessions. Use Randori mode: all together on the same problem and computer. Stick to strong-style pairing.
2. Experiment a with few morning group reviews, like people at New Relic suggest
3. Run a few morning mob sessions
4. Retrospect and decide how you want to continue from there

These steps should get you through the technique, et let you make and informed decision.

However this turns out for you, I’d love to read your comments about it!

Stay up to date with content and upcoming products

I usually write about 15 minutes worth of reading per month. I won't transfer your email. No Spam, unsubscribe whenever you want.

As a gift for subscribing, you'll receive an illustrated mini-ebook "How to start a team coding dojo"!