After a more than a decade in software development, I finally got the opportunity to mob program.

I was skeptical at first. I had seen contractors pair programming and many people made jokes and cast doubts on how that could be viable - surely it must just be a clever way for them to bill more hours? And if pair programming was dubious, surely mob programming was even more so.

I had a few major concerns:

  • How is it cost-efficient to have 3-6 engineers working on one task?
    • Won’t we move too slow?
    • Will there be too many cooks in the kitchen?
    • Will everyone hate each other by the end of the day?
  • What is everyone else doing when just one person is typing?
  • How does everyone stay engaged and contributing?
  • How do you prevent one person from dominating the session?
  • How do you prevent groupthink?
  • How is this way of working perceived by the those not in the mob?

It took about 3 months and several discussions with my manager before the idea really started to gain favor in my mind. Funny enough, my manager also said 3 months is about the amount of time it takes for someone who doesn’t like the idea to bail on it. I definitely don’t think mob programming is for everyone as it takes a constant high level of communication, emotional intelligence, and humility to be successful.

In addition, it takes alignment across the organization that this is a viable way to work. Frustratingly, some people on the outside looking in may think it’s resource mis-allocation or, “it’s like those construction sites where everyone stands around watching one person work.”.

While it may not be a panacea and necessarily the best tool for the job at all times, I do think I generally prefer it and I hope more of the software industry starts to experiment with it!

How is it cost-efficient to have 3-6 engineers working on one task?

The best way to tackle this question is to ask, “What is the most expensive part of software development?” It shouldn’t be a surprise to many that maintenance is often sited as the primary expense. Or bug fixing and rework…

Most of you have probably seen a chart like this…

Software Development Costs

And here is where mob programming can shine. You no longer have just one guru/rockstar/wizard that knows how to fix an issue or maintain the software. You have a team with a shared understanding of the codebase and the problem domain, and ideally they have flushed out a lot of the bugs and edge cases together already.

Now people can take vacations, sick days, or leave the company and the team will still move forward.

Another phrase that really resonated with me was “divide and conquer”. We don’t want to divide our people. We want to divide the work into small batches and conquer it together. Always work on the most valuable thing

Won’t we move too slow?

It depends?

The team is likely talking through issues together in more depth than if it was just an individual doing the work, and the likely-hood of needing rework or bugs slipping through should be greatly reduced - at least that’s what I noticed. More time may be spent upfront but if the quality is higher and there is less rework, then the team is actually moving faster - especially if you account for things like a senior person leaving and not having to spend months trying to figure out what they did and how to back-fill them. If quality work is paramount (and when isn’t it?) then mob programming is a great tool to achieve that. The team gets as much context as possible, and you should get the best from each person which should show through in the final product.

Is your team’s main job to give the impression 10 things are getting done at once, and you don’t care how much rework happens? Or are the people on the team not able to get along with each other, so they have to work on separate things at all times? If so, then yes maybe mob programming is too “slow” for your team.

Will there be too many cooks in the kitchen?

Quite possibly, yes. With the mobbing I’ve seen, there’s a navigator and driver. The navigator is typically the one talking and giving direction. Inevitably, others will want to speak up or be queried for their opinions.

There will likely be multiple opinionated voices in the room and ideas will have to battle it out to find a path forward. This is where humility, emotional intelligence, and consensus building skills come into play. Whenever conflict appears, the team needs to find a way to move forward, and mechanisms such as “fist of five” can provide a way to quickly move forward. This requires a call to each side to present their case and then call a vote.

Ask yourself which you’d rather have - a synchronous discussion where people can quickly come to a consensus or days of github PR back and forth with walls of text.

Again, this takes some skill from individuals on the team to recognize when a situation can benefit from voting and how to quickly move forward.

Will everyone hate each other by the end of the day?

Look, you’re on a Zoom call, Google meet, or whatever for 6-8 hours a day, 5 days a week with these people. There will be times that something triggers you, and other times you’ll be the one doing the triggering. During the storming phase of team development, this may become extra painful.

The two mechanisms I’ve seen help with this are:

  1. Short Frequent Retros - I saw a lot of benefit from frequent “mob” retros, which are focused on how the mob is working, not what the mob is working on. Our team would often do this at the end of the day for ~15 minutes and it was a great way to clear the air and make sure the team is working in a sustainable way.

  2. Breaks - The team I was on would take a 10-minute break every hour. This may sound like a lot, but it was crucial when you consider how exhausting challenging technical work can be - both socially and mentally.

What is everyone else doing when just one person is typing?

Like in pair programming, you at least have the navigator and driver. The navigator is typically the one talking and giving directions while the driver is the one typing.

If the navigator is unsure what to do next, they query the rest of the team.

If you have an engaged team, they will be thinking of how they would tackle the problem, and as things play out, they can compare and contrast how they would have done it with what is currently being done. This constant feedback loop is what allows the mob to “get the best from each person”. the best of the whole team

There will also likely be points in the process where less than ideal solutions are temporarily provided, or loose ends remain, and these are natural things for non-driver/navigator to spend their time doing - thinking about how to improve the current solution.

How does everyone stay engaged and contributing?

Ultimately it’s the individual’s responsibility to stay engaged as much as they can. To make it easier, the team often observed it being more difficult to stay engaged as the number of members increased, or if the mob timer (the time a person is allowed to be the driver) was too long. The sweet spot for our team was usually around 5-10 minutes and 3-5 team members.

How do you prevent one person from dominating the session?

This is another issue that is great to handle during mob retros. It may be uncomfortable to bring it up directly, so another idea is to have stricter mobbing, in the sense that only the navigator has the talking stick. They can still query the group when desired, but the idea is this limits the amount of interruptions that may be coming from a particularly chatty individual.

How do you prevent groupthink?

Psychological safety is a key component of mob programming. If people are afraid to speak up, or have given up on putting their ideas forward, the creativity and innovation that can come from a mob is lost. Maintaining a welcoming environment where everyone has the chance to provide input can go a long way in preventing groupthink. Also, simply trying things occasionally, even if they might not be your first choice, can help prevent groupthink. If it really is not ideal, then the mob will likely be open to trying something else.

How is this way of working perceived by the those not in the mob?

Mob programming is still rare in the industry. It’s likely that people outside the mob will be skeptical about it. I was skeptical at first too! It’s important to have a way to communicate the benefits of mob programming to those who are unfamiliar with it. Transparency can go a long way here. Invite someone who is unfamiliar with mobbing to see what it’s like as an observer - or participant if they’d like! Even then it may take time for people to understand, and other departments in the organization may think it’s a waste of resources.

Alignment is key. People within the mob need to be open to it. People outside the mob need to trust the developers that this is a viable way to work. If the organization is not aligned on mob programming, it’s likely the concept will eventually meet some resistance. You’ll need a lot of support from management to make it work. You’ll want support and understanding from the product managers too. Pretty much everyone up and down the chain will need to be on board with the idea or at the very least open to experimenting with it - or critical resistance and doubts may remain.

Conclusion

More companies should experiment with mob programming. It takes a team of people with high emotional intelligence and alignment from the organization to give it a chance of success - which I admit can be extremely rare! Considering the pros, I think it’s worth the effort to try it out…

Pros:

  • Shared context - no more “bus factor of 1”, people can take vacations and join and leave the team without catastrophe
  • Higher quality work - with the full team context, amount of rework and bugs are likely reduced
  • Quicker decision-making - with a synchronous discussion, decisions can be made quickly
  • PRs are near instant and don’t languish for days with walls of text and back and forth
  • Quick shared learning - everyone on the team is learning from each other

Cons:

  • Skill-set for team members is demanding - high emotional intelligence, humility, and communication skills are required
  • Alignment across the organization is required - if the organization is not aligned, the concept will struggle
  • Risk of groupthink if individuals are not engaged and if psychological safety is not maintained
  • New way of working that many people will struggle to understand. There may be perceptions of slow progress and resource mis-allocation

Given the cons can be mitigated with the right communication and training, I think the pros generally far outweigh them. My initial skepticism for mobbing has been replaced with enthusiasm and I hope more companies give mob programming a chance!

Resources