I attended my first Agile conference in the summer of 2016. I was lucky enough to be sent to the Global Scrum Gathering in Orlando. I learnt a huge amount during that week. A couple of things still stand out today, over 3 years later. In this blog post I want to explore the power of Mob Programming. I've already written an entry about Mob Programming on the Open Practice Library. This blog is an expansion of that entry.

What is Mob Programming?

Mob programming is a way of writing software as a team. To me, it is an extension of pair programming. A process where two people write software together, with one person giving instructions and one person 'driving'. Mobbing is an extension, because it involves the whole team writing code together. As with Pair Programming, a mob has a single 'driver' who is typing at the keyboard. Everyone else is watching, participating and discussing the changes being made.

Why use Mob Programming?

I am a huge fan of Mob Programming and its power. I have encountered a few key scenarios, which I'd like to share with you, where I think Mob Programming is essential for success.

Writing code as a team when a new member of the team joins. This will help them familiarise themselves with the code structure, best practices and standards

Refactoring a crucial part of the codebase. I worked on a project that was dependant on huge amounts of reference data to work. We loaded this data from a set of services. After some performance analysis we decided the way we were loading the data was incredibly inefficient. It was also difficult to understand, which meant it became a black box. As a team we came together for an afternoon and mobbed a new solution. The new implementation was simpler, more efficient and better understood that the previous implementation.

Similar to the previous idea, when the team is worried about a complex new feature. It can be a good idea to mob the implementation. This is especially true if the new feature will be deeply integrated into the codebase in future. This will help everyone properly understand the feature and how it works.

Finally, as with Pair Programming, this is great way to learn new shortcuts, hints, tips and cheats.

All of this being said, I don't advocate for a team to use mob programming all of the time. I'll expand on this during the post.

How to make Mob Programming successful?

Now that I've shared some examples of when to use Mob Programming. I'd like to share some thoughts on how to make it successful. These thoughts are roughly split into two categories. The Physical environment for the Mob and the emotional environment of the Mob.

Physical Environment

To make Mobbing successful the team needs to ideally be colocated. It isn't to say that this wouldn't work with remote teams but they'd need to be a well-established team to start this practice as a distributed team.

The team needs to be in a large, well-lit room with a large, high-resolution display/projects. Everyone except the 'driver' should leave their laptops outside the room and the driver should close all applications except those necessary for development.

Mobbing is a very intense practice requiring a lot of interaction and focus. The team should take regular breaks. Something similar to 45minutes on 15 minutes off should be sufficient to allow the team to be productive. Every time the team take a break the 'driver' should change.

Emotional Environment

Having a safe emotional environment is also crucial for Mobbing to be successful. Team members both inexperienced and experienced need to feel safe to make mistakes, ask questions and explore new ideas. This practice isn't suitable for teams that can't discuss and work openly with each other.


Used at the right time, with the right team Mob Programming can be an incredibly powerful tool. If you think your team is ready for it, give it a go. As with everything, this is only my opinion on the topic. Please read other articles and guides. I particularly like this article from New Relic about Mob Programming from a management perspective. Try things out, gather feedback and improve for the next attempt.

Thanks for Joanna Hodgson for proof reading this post.