Remote Mob Programming Research & Experience

This is just some thoughts on how to make mob programming work with fully remote teams. I have had some conversations with teams that were used to working in mobs and then went remote and read some articles from people on those teams that have done some trial and error with remote mobbing as well as some experiences with the teams I am working with now to come up with some basics that seem to be working right now.

Have cameras on since it provides that face-to-face conversation. People communicate with body language and facial expressions just as much as words and often those factors add context to the spoken words. It also helps with focus. How many times at an in-person meeting, or mob programming session if you’ve done it before, have you pulled out your phone and started looking at twitter? Probably never. When you need to step away, go on mute, but leave the camera on.

A mob should also be a small team. Your team should be a small team anyway, but in case it is upwards of 10 or more people, I would say about 5 is a good mob. The minimum size is 3, but at least 4 is desired since once one of those people are out it would still be a mob. But a pair is still preferred over solo style hero work whenever possible.

When we have people in different time zones it gets difficult to align for mob programming, or even pair programming, so the team must find a suitable time to be on-line together to mob or pair. It seems like a good duration for a mob session is 5-6 hours, but I would say ease into it if you are not used to it and perhaps do a couple hours and take a break, completely up to the pair or mob. If going with a 5-6 hour mob time, agree on a time to stop for lunch and step away. Since you are remote, and if you have family in your house, have lunch with them and enjoy the fact you can do that. If we need to go to a meeting, then go, need to do something with the family, go do it. It is fine, we respect each other as people and understand that life happens. We are not drones on an assembly line pumping out code, and sometimes you just need to step away.

Yes, there is one person that actually writes the code at a time, it isn’t 5 people hacking away at the same section of code on their local and then meeting together to see whose solution works best. The one person codes via the instruction of the mob. The mob discusses best possible solution, guides the person coding, the person coding asks questions about the solution and provides input as well, or how to do things they may not be familiar with.

Added bonus to the mob, code review happens live and isn’t a separate process. With TDD included, the testing is sorted out as well.

For obvious reasons, when you are the person coding, you must share your screen with the rest of the mob. I haven’t found a good collaborative IDE as of yet that beats the simplicity of a screen share. If anyone reading this has any suggestions I would be excited to hear about it.

Work in intervals towards solving a specific goal of adding a single feature or fixing a bug. Since this single feature or bug could take several hours or sessions to get done, implement a rotation of who is coding. Switching who is coding for the mob is an inherent cost of time, so you need to find out which interval works best. I think 20 or 30 minutes could be good. Adjust as needed.

How does the switch work remotely? There is a pretty cool tool GitHub – remotemobprogramming/mob: Tool for swift git handover. for Git handover. Create a mob branch from master. At the end of each interval, push a WIP commit to the mob branch, do not worry about the commit message, compiling or the tests passing. We are just looking to make the hand off. If we were mobbing on site, somebody would just hand over the keyboard. When the mob session is over, squash the WIP commits into expressive commits and merge into master.

An additional note I think I missed in here. The “mob” in mob programming does not need to be restricted to developers. Product Owners, UX, QA, anyone else on the team can contribute. Context is key though. Instead of having refinement sessions to discuss what to build in the next sprint, and then going back your separate ways to continue working on the current sprint items, discuss this one story or bug, design it, build it, test it all in the mob right now. If you can’t drive the session due to technical skill set or context, then pass on driving. If we are working on designing the solution, then a UX person can drive. Or if you need to walk through the existing system and get contextual questions answered, the PO can drive.. But just like anyone else in the mob, if anyone needs to drop, they can. Pretty much, take that refinement session from scrum you are doing now and instead of discussing something to build in the next iteration, start building it now. I need to find a better term for mob programming that doesn’t seem like it exclusive to developers. After all, one of the greatest benefits to mob programming is NO SILOS.

I am sure I will expand on this topic more in future posts.