Three Questions You Must Ask to Ensure Mob Programming Success

Last month in a previous blog, we discussed how mob programming could be beneficial for your production team as a tool to strengthen both technical knowledge and teamwork. But in order to reap these benefits, you need to sit with your team and first ask these three crucial questions before you get the ball rolling:

• How should you get started?

• Who will handle what?

• What are the best practices?

In this blog post, we will have a few suggestions based on the best practices we have here at Niteco which could help you get mob programming started in the right away. But just remember, mob programming is a versatile tool that requires close observation and a willingness to adjust when needed in order to get the most out of it…

How to get started?

Your mob should consist of at least three people. The team composition could be varied, depending on whether members are junior, senior, or a mix of different levels. Next, a regular, everyday computer will suffice. The reason we do not encourage people to bring their own laptop is so that we can minimize the amount of customization each dev has on their computers that other people may need to adopt to. A consensus of a common working environment will provide the mob with more flexibility later on.

Every mob programming session requires a large screen TV that meets the following criteria:

• “Large screen” here means a 30+” screen / TV that you can use. Ideally, everyone should be able to see what is going on with the code in great detail. Normal 24-27” monitor is too small for a mob.

• Latest ultra HD TVs usually have cursor/keyboard lag due to extra video processing manufacturers put in, so it’s critical you make sure the following settings are enabled:

• TV must run in Game/Gamer mode

• The refresh rate must be set to 60hz (some TVs are limited to 30hz refresh rates when connecting via HDMI, so it’s mandatory to have 60hz refresh rate enabled).

• Since a TV often has a much higher contrast compared with a normal computer monitor, its contrast and brightness should be adjusted to a low enough level to avoid eye strain.

You will also need a set of wireless keyboards and mouse. They will be passed around between team members thus wired ones will be inconvenient. In addition, a mechanical keyboard is always a plus because who doesn’t love them, right?

Once the equipment is gathered, the next thing to consider is an open space. You don’t want to lock up an angry, heated mob in a room - even if that mob consists of only friendly geek! Jokes aside, there will be and should be a lot of arguments going on during a mob programming session because the freedom to express opinion is highly encouraged. And for your initial session, tackle the easy tasks first because it is always better to take it slow and easy and then speed up later.

Who will handle what?

A mob consists of one “driver”, and several “navigators”. We recommend you have the one with least experience in either codebase or the task at hand to be the first driver of a mob session. Everybody will take turns being the driver every 20 minutes or so (you can a web-based timer such as https://www.timeanddate.com/timer/ to keep track of your progress in the mob session). One person can be the driver for the whole session, but this is NOT encouraged.

In a mob, the driver will handle the keyboard and mouse. He’s the “do-er”. His job is to implement others’ solution by typing in the code and monitoring how his computer will execute the code and think as little as possible. Yes, really. The brainwork is for the navigators.

Navigators are those who will provide the solution. Together they will discuss ways to handle the task effectively and efficiently, while instructing the driver via verbal communication. By talking out loud, everybody else will have the chance to understand what is going on in a natural way. Your communication skill will be put to the test, but eventually, everyone in your team will understand each other effortlessly in any project. 

Mob programming offer us a way look at a problem from different perspectives, and practice teamwork by learning how to communicate in a large group and working as a whole unit. No one has to tackle any problem alone and every step of the process is transparent for everyone to watch and learn.

And don’t make the mistake of thinking that Mob programming is limited to just developers. It’s not. In reality, it is more beneficial to have a tester or a UI/UX designer working in the same mob if the task at hand requires their expertise. For example, the frontend team at Niteco collaborates with our UX/UI designer, helping us to quickly experiment, identify and solve problems on the interface of a website or a piece of software without the developer guessing what could be best. Similarly, a tester within the mob will be able to detect potential bugs and tell the developers to fix them even before the testing phase.

What are the best practices?

In short:

1. Thinking is not for the driver
2. Doing is not for the navigator
3. Time’s up, switch role please, immediately!
4. Everybody must join; no one is allowed to be silent and passive.

 Just like pair programming, working in a mob can feel intimidating at first, but if done right, the whole team can easily become addicted to it. After all, sometimes a team is ‘only as strong as the weakest link’, but thanks to mob programming, the team in question quickly learns how to improve and communicate properly. For that reason, everybody will benefit from this growth mindset.