Mob Programming Memoirs: Agile Collaboration On Steroids!

“If you want to go quickly, go alone. If you want to go far, go together.”
— African Proverb (according to the interwebs)

The Agile Manifesto has a strong emphasis on collaboration, but how should developers collaborate in practice? It’s not an easy problem to solve. Mob programming (AKA “mobbing”) is one of the ways to go about this: it’s like pair programming on steroids. I’ve been mobbing for the past two years. Here’s what I learned along the way and how mobbing might help your team, too.

What is mob programming?

Mob programming is a collaborative way to solve problems. A team of developers works together on a single task, at the same time, using a single machine. One person is designated the “driver” (no drinks for them!) while all the others assume the role of “navigators”. The driver sits in front of the keyboard and enters code, guided by the navigators. While the navigators don’t enter code themselves, they do give the driver instructions on the best way to implement a solution. In essence, they code through the driver’s hands.

Mobbing is actually pretty similar to high-speed rally driving. The driver has the steering wheel in their hands: they handle turning, accelerating, and braking. To make good decisions at high speed, though, they need the help of the navigator sitting next to them. The navigator shouts instructions to the driver:

“Brake!”
“500m hard right!”
“Jump coming up!”

Mobbing navigators do the same thing:

“Line 50 needs a null check!”
“Lines 25 to 30 can be extracted into a method!”
“This looks wrong — let’s clarify the requirement!”

The mob switches drivers at regular intervals. The exact duration that the driver stays at the keyboard is up to the team to decide, but 10 minutes is a good rule of thumb. Regularly switching drivers ensures that everyone gets to be a navigator and thereby contribute to the solution. Constantly shaking things up also helps everyone to stay engaged. After all, we’re developers: we want to grab a keyboard and write code!

How my team and I started mobbing

I work in a team of five people; we build business intelligence (BI) solutions for the financial services industry. As far as I’m aware, we’re one of the few teams who embrace mobbing and practice it regularly.

Before I joined my current team, I had never heard about mob programming. To be fair, it is a relatively new concept in the history of software development: the first post on the Mob Programming website was only published in 2012. My team started mobbing a couple of years before I joined. One of the team members had come across the concept, and figured that it was worth a shot to try it. They decided to bring a large TV screen from home.  Because good teams are keen on regular experimentation — and I’d like to think that we are a good team! — they gave it a go. It worked out so well that the team has been doing it ever since.

The first time that I mobbed with the team felt very, very strange. It didn’t seem natural to tackle a single piece of code with a whole team of people! Mobbing also seemed hard to justify to stakeholders who don’t understand the nature of development work — more on that later.

Somehow, though, mobbing just worked.

How mob programming has helped us

1. Share domain knowledge

We work in a complex financial domain. That means we need to understand a variety of financial products to be able to implement solutions. In fact, people do entire degrees in the stuff that we as developers have to wrap our heads around in weeks! Mobbing allows us to share the knowledge that we accumulate in the team amongst ourselves. Perhaps one person understands equities well, someone else has knowledge of how bonds work, and a third team member knows everything about swaps. If we can pool our knowledge in discussions, it means that we don’t all need a degree in finance to be able to make a meaningful contribution to the team.

2. Benefit from each other’s skills

Our team is diverse: We’re from different professional backgrounds and we have different skill sets. This means we can easily end up working in silos, where it’s hard to benefit from each other’s past experience. Mobbing allows us to capitalize on the best that everyone has to offer: It’s much easier to surface each person’s unique skills. We can then learn from each other in the context of a concrete problem.

Case in point: I was a Java developer for eight years, and now I’m doing lots of BI and SQL work, with some C# thrown in for good measure. Mobbing has allowed me to quickly catch up on the BI field, greatly improve my SQL skills, and learn to work with unfamiliar tools like SSIS (SQL Server Integration Services). Without mobbing, I would’ve had to go and learn about the BI world alone, stuck with reading books and doing online courses. With mobbing, I can learn from a specialized BI team on the job while implementing real-world solutions. Conversely, the other four team members can benefit from my experience in more traditional, non-BI software development.

3. Rapidly onboard team members

Mobbing allows us to rapidly upskill new team members by letting them learn on the job, while being supervised by the rest of the mob. In fact, newbies can write production code during their first day, because they’re not doing it alone. In the process, they can also immediately start learning about our business and the financial products that we work with.

The alternative to this is that new developers would have to spend time trying to figure it out on their own, constantly interrupt the rest of the team with questions, and then go through a bunch of code reviews before nervously deploying their code to production for the first time.

4. Share productivity hacks

The knowledge sharing that results from mobbing applies to more than just the business domain. It also allows team members to share their hacks for tools, like useful IDE shortcuts, thereby allowing everyone to up their productivity. The fact that we can share these hacks in the context of a specific, shared problem makes them more useful.

5. Improve code quality

Mob programming has allowed us to deliver high-quality code with very few defects. Effectively, code reviews happen on the fly, as the code is written, and the team can quickly identify potential issues. While we are mobbing, the entire team has context on the solution. That helps them to spot and address issues.

In traditional code reviews, by contrast, people look at large chunks of code after the fact. They often skim through it and don’t really get “into” the problem that the code is trying to solve. All of this makes it a lot harder to spot problems.

6. Remove key-person dependencies

Mob programming also removes key-person dependencies: it reduces the “bus factor”. Everyone has a shared understanding of the solution, so work doesn’t grind to a halt if a particular team member isn’t available. In other words, if I go on leave and someone finds a defect in the solution, it’s not a case of “Riaan wrote this module, so he is the only person who can maintain it. The fix will have to wait until he gets back.” In mobbing, the team collectively owns the work that they produce.

7. Reduce the cost of context-switching

Context switching is bad. If you work in isolation, and you get interrupted, it can easily take a good 15 minutes or so to get back into a productive state. Context-switching becomes less of a problem when a team practices mob programming. If one person is interrupted, perhaps by a phone call, the rest of the mob just carries on. When that person rejoins the mob, they don’t continue from where they left off. They continue from where the mob is at that stage and pick up the context as they go along.

The difficulties that we’ve had to overcome

1. Getting buy-in from external stakeholders

Mob programming can be difficult to justify to external stakeholders. After all, doesn’t it look like you now have multiple developers doing the job of a single person? There is an important (and mistaken) assumption that leads to this kind of thinking: that developers are typists.

The bulk of development work lies in thinking, not in typing – and that’s where mob programming shines and allows teams to deliver great solutions. Seeing developers as typists also doesn’t take proper account of flow (work gets done) versus utilization (everybody is busy). In other words: Are we producing value, or are we just making sure that everyone looks busy? Sure, if everyone works on something different, you have a busy team, but does being busy equate to being productive?

When you mob, it might appear as though it takes longer to produce solutions. Consider the impact of quality and future benefits, though: bugs are cheap to fix during the design phase, and very expensive to fix in production.

2. It can be draining

Mobbing is a demanding social exercise in a field with many introverts, myself included, and constant social interaction can be mentally draining. Introverts need quiet time to recharge. This isn’t to say that mobbing necessarily works better for extroverts, but it does mean that you need to remain cognisant of your own individual needs. If you feel like your energy is completely drained, you might need to get some alone time. I’ve found that, after a hectic mobbing session, it sometimes helps to have lunch on my own. This is obviously different from a team where everyone works in isolation and then has lunch together.

3. Communication skills are crucial

To mob effectively, one must also develop excellent communication skills. Someone else has control of the keyboard. That means you have to master the art of expressing your thoughts in such a manner that someone else can translate them into code without misunderstandings. As a navigator, even if you know the answer, you can’t grab a keyboard and just type it out. You can’t just show someone what you mean: You must articulate your thinking sufficiently for someone else to understand it and to then type it out.

Mobbing also involves giving up control. This isn’t necessarily a good thing or a bad thing, but it does take some getting used to. As a driver, you put the code on the screen, but you don’t get to decide what it looks like; you should learn to depend on the team for that. At one stage, we tended to grab a keyboard to try and explain things on-screen, instead of talking the driver through it. In order to get rid of this bad habit, we removed all but one of the keyboards from our mobbing station. That meant there weren’t any extra keyboards left to grab!

When mobbing, the team should ensure that everyone is on the same page. It’s easy to fall behind and disengage when you’ve lost your understanding of the problem. The team should provide a safe space where someone can put up their hand at any point and say: “Listen, I don’t understand why we’re doing X in the code; please explain it to me” — without the fear of looking silly.  At the same time, if you notice someone else falling behind, you should be able to say: “Hey, are you still with us, or should we take a step back?”

When to mob, and when not to mob

Mobbing is great when working on complex tasks, but it should not be the default for a team in all circumstances – some tasks just aren’t well-suited to the approach. Everyday support tasks that follow a well-defined process — like common, recurring queries from users — are a poor candidate for mobbing, as are emails. Save your mobbing for tasks that present new problems to solve or that provide opportunities for the whole team to learn.

If the team is evaluating new tools or technology, I would not recommend mobbing either. In that case, it might be better for everyone to experiment individually and then discuss their learnings afterwards. Mobbing works well when the team is working towards an optimal solution for a well-understood problem. That means the requirements are clear and the team can start implementing the solution.

If you’re trying to learn new tech and just throwing stuff at the wall, you might be better off doing that on your own and sharing your learnings with the team afterwards.

Examples:

Good choice for mobbing: “Extract daily financial information from systems A, B, and C, and use that to calculate profit and loss.” This is a well-understood problem and everyone knows what the end goal is. Now, everyone can collaborate on how to get there.

Bad choice for mobbing: “We need a tech stack to build a new front-end; decide between React and AngularJS.” This is an exercise where people will want to play around and try different things before making a call on which framework they personally prefer, and why. The team can then make a decision based on everyone’s feedback.

How to mob

In order to start mobbing, you’ll need a couple of things:

• A large screen, in other words: a TV, rather than a monitor.
• A mobbing timer (like this one) to indicate when to switch drivers. You can keep this on a separate, smaller screen.
• Sufficient space for the whole team to sit together.
• A whiteboard, in case you need to stop and talk something through.

Once you have this in place, you can start the actual process:

1. Agree on the problem you’re trying to solve — use the whiteboard if necessary. Don’t start until everyone understands the objective.
2. Let the first driver take the keyboard and let the navigators start navigating.
3. Start the timer and switch drivers when the time has elapsed.
4. Consider taking a coffee break every 90 minutes or so, just to help everyone stay focussed.
5. Solve the problem!

Here’s how mobbing looks in practice:

Tips

• It takes a while to get used to mobbing. Try if for a week or two before deciding whether or not it works for you.
• Don’t allow one person with a strong personality to dominate the mob: It’s all about collaboration.
• Find a relatively quiet space where you can try this. If you have an open plan office, try to find a conference room to use for mobbing.
• Use tools that everyone is comfortable with. We used Vim for a while and even though a few people were really good with it, others struggled. If people struggle, the mob becomes less effective.

Try it!

Woody Zuill, the father of mob programming, nicely summarised it as:

“All the brilliant people working on the same thing, at the same time, in the same space, and on the same computer.”

Mob programming has delivered great results for my team. It’s allowed us to produce quality software, eliminate defects, and learn rapidly. Perhaps it can do the same for you.

In the very least, it’s an experiment worth trying.

Resources

• Agile Alliance’s overview of mob programming: Useful reading to understand the origin of mobbing.
• InfoQ interview with Woody Zuill: Woody is the father of mob programming.
• A presentation on mob programming at Agile Africa 2016: Shows how mobbing has benefited a real-world team, based on concrete metrics.
• Video: A day in the life of team that practices mob programming. See if you can spot some tips to try out for yourself!
• Mark Pearl’s book about mob programming: Code with the Wisdom of the Crowd: Get Better Together with Mob Programming.

Riaan has been developing systems for the past decade, dabbling in everything from ERP’s to integration to financial systems. He also writes about and teaches online courses on programming-related topics.