Blogg » Remote Mob Programming – insights captured during a webinar with Woody Zuill

Remote Mob Programming – insights captured during a webinar with Woody Zuill

By Olof Bjarnason

26th of March 2020 I attended a webinar on the topic of challenges and findings when doing Mob Programming remotely. I want to share some of the things I took note of during that seminar in this blog post.

But first things first – what is Mob Programming? In a nutshell, it is a software development practice where the whole team (including testers, developers, product owner and any other specialities necessary to develop the product at hand) sees the same screen at once, focusing on one problem at once, limiting ”work in progress” to exactly one thing. One could see this as taking agile/scrum/kanban practices as if you really meant them: a single problem at a time! Woody Zuill is one of the focus figures when it comes to Mob Programming and it was he who shared his findings in this webinar.

There is a lot more to say about (co-located) Mob Programming, but this blog post is not about that but about applying the technique remotely. If you want to read more on Mob Programming, you could start by reading the Wikipedia article on the topic.



Without further ado, here are the notes I took during the webinar!

  • His team currently prefers Zoom or Whereby for sharing screen and video
  • There is one driver at a time, and the driver is the one that shares screen
  • All others are navigators, and the one who is expert in the task at hand will navigate driver
  • Rotation frequency slightly longer than for physical meetings, on the scale of 7 minutes instead of 4 minutes per driver
  • Switching amounts to checking in code, switching screen sharer/keyboard user (driver), with new driver getting latest changes
  • A philosophical point of view of the driver is that (s)he is an extension of the computer
  • In remote setting, we need to be a little slower about sharing our views, ideas and comments, at times holding it back for the right timing. It can help to use post-its on your own and wait
  • Also pacing ourselves, letting others talk and finish their sentence, leaving space for others
  • Use finger signals (one finger meaning ”I have a comment” and two fingers ”I have something REALLY important and want to talk NOW”)
One finger means ”I want to talk soon”
  • Using communication cards which are held up to webcam is another useful technique
  • Most viable whiteboard so far Google Docs
  • Team & personal health and a sustainable pace even more important than for physical mobbing. Kindness, Consideration and Respect considering the worry in world currently
  • Avoid ”side” conversations, stay on topic
  • Let people finish their ideas – not just sentences
Two fingers means ”I want to talk NOW”
  • You don’t need to understand everything
  • Take breaks before you need them!
  • Keep webcams always on!
  • Fast internet connections
  • Important: be clear about what equipment is expected, and the interaction protocol
  • Do retrospectives more frequently, e.g. after every session instead of daily
  • At first, smaller team is easier, or even pairing to start out
  • Powerful computers (most importantly, a big enough screen; remember it should replace the giant shared screen of a traditional mobbing session!)
  • Avoid audio feedback loops, use the mute function

He also brought up some general topics about having discussions about development (and discussions in general):

  • When someone doesn’t understanding you, assume it is you and not them
  • Find alternative ways to make your point (after repeating once)
  • Try all ideas
  • Make it easy and safe to share ideas
  • Include and honor every voice
  • Listen as if the next thing said is the most important thing you will ever hear
If you don’t get the reference, google ”get up stand up lyrics”

The webinar strengthened observations I’ve made myself during remote meetings – including remote mob programming – last few months. Doing things remotely is, contrary to what may be the gut feeling, more intense than in the same room. I speculate this may be because we are actually seeing each other directly (including ourselves at times), plus having super sharp focus on code / whiteboard / topic. This means, taking breaks and ”leg stretchers” are even more important to keep in mind and get a practice around. I have made up my own rule of ”a remote meeting is 45 minutes then there is a 15 minute break”. I wouldn’t necessarily think things go slower because of these frequent breaks though, since the 45 minutes are more focused than ordinarily.