Remote Mob Programming

remotemobprogramming.org/

New: Since COVID-19 many work from home. The typical team events are postponed or
canceled. With ‘The Remote Mob Programming Experience’ we offer a unique form of team
event which works working from home and makes a lot of fun!

Remote Mob Programming combines two ways of working: Mob Programming and working as a distributed
team. Woody Zuill describes Mob Programming as creating the “same thing, at the same time, in the same space,
and on the same computer”. Working in the same space clashes with working as a distributed team at first
glance, but actually, it goes together really well. With Remote Mob Programming, we collaborate closely in the
same virtual space. But Remote Mob Programming is more than that.

We even came to realize that Remote Mob Programming is superior to anything we ever
tried before.

— Simon Harrer, Jochen Christ, and Martin Huber

1/7
Check out our free eBook on Remote Mob Programming at leanpub and the Kindle book on Amazon.com.

Here’s how we do Remote Mob Programming

Below, we summarize the essentials of successful Remote Mob Programming as we understand them.

Remote Everybody

To collaborate well in a distributed team, it is essential that everybody works remotely by default. It does not
work if part of the team works on-site. This will lead to information asymmetry.

We all work from home, but don’t feel alone.

We enjoy working from home: a quiet environment, perfect working setup, no commuting, and more quality
time with our families and friends. In previous projects, we sometimes felt isolated from our colleagues. This
radically changed with Remote Mob Programming. It is real team work.

Camera Always On

Working face-to-face is powerful because we communicate with the whole body, not just our words. And we are
much more attentive because any distraction like looking at the smartphone during a discussion will be detected
immediately.

We activate our cameras all the time.

It felt strange at first, but after a few days, it felt natural. It gives a sense of presence in the team, almost like
working in the same room together. It’s easy to see if someone is away from keyboard, talking to their children,
or otherwise distracted.

2/7
In a multi-monitor setup, we make sure that the camera is at our main screen so that you’re looking at each
other. We mute when we go away from keyboard, but leave the camera on.

Regular On-Site Meetings

The better everybody knows each other, the better everybody can collaborate remotely. Getting to know each
other works best on-site.

We meet on-site once a month.

In the last few months, we met in awesome cities with good transport links, had barbecue at someone’s home, or
came together at one of the INNOQ events. Have fun together in real life.

Small Team

This is essential. The whole team works and focuses on the same thing.

With Remote Mob Programming, only one person can talk at the same time. With larger teams, the individual
speaking time shrinks, making it harder to stay focused. It is easy to become mentally absent. Also, expect
technical issues, such as connectivity problems or interfering noise, to happen more frequently in a larger team.
Those issues will block the whole team.

We have a team of four.

Obviously, the minimum size to form a mob is three. In our experience, teams with three to four developers
provide the best benefit-cost ratio. A team of four has the great benefit of still being able to form a mob, even if
one person is absent.

Same Time

One of the prerequisites of Mob Programming is working at the same time.

We mob at least six hours a day.

To reach these six hours, we align our core working hours. We also agree on the same lunch hour. Still, it’s
totally OK to have an external meeting, get your hair cut, or spend time with the family.

Typist and the Rest of the Mob

We adopted the terminology from Code with the Wisdom of the Crowd by Mark Pearl:

One person controls the keyboard, this is the typist. The rest of the mob discusses the problem, agrees on the
solution, and instructs the typist. The typist follows their instructions, puts them into code, and may ask
clarifying questions to understand the solution. The rest of the mob guides the typist as needed.

We value the typist as they allow the rest of the mob to focus on solving the problem.

The typist must not code on their own. This balances the participation of all team members and it reduces the
dominance of strong characters.

Screen Sharing

We feel most comfortable working in our own individual environment. It is where we are most productive.

3/7
The typist shares their primary screen, showing the IDE. It is a good practice to show the IDE fullscreen and
disable notifications.

We all look at the same shared screen.

Looking at and working on the same issue forces us to focus. It is highly efficient to work with actual code in
contrast to having abstract meta discussions.

We tried collaboration IDEs. Surprisingly, this led to worse collaboration. Impatient members of the rest of the
mob circumvented both, the discussion and the typist, by just hacking their ideas.
While the typist shares the screen, the rest of the mob has no shortcuts. Only the typist types, the rest of the mob
must explain what to do through language.

We accept the time to switch the shared screen at the start of the next mob interval.

10 Minute Intervals

Every mob session has a specific goal (e.g. to implement a feature or fix a bug) and may last several hours. In a
mob session, the typist role rotates periodically. Short rotation periods keep everyone concentrated and every
opinion in the mix.

We rotate every ten minutes.

We tried different rotation periods and considered ten minutes as a good trade-off. Shorter periods didn’t work
out for us because of the inherent switching costs in a remote team.

Surprisingly, taking your turn as a typist allows you a mental relaxation. You just wait for instructions.

Git Handover

With on-site Mob Programming, you just pass on the keyboard to hand over to the next person. This is a
challenge for a distributed team.

We hand over with WIP commits on a temporary git branch.

To have a clean master branch, we work on a temporary mob-session branch. After each interval, we push a
work in progress (WIP) commit to this branch. In this branch, we don’t care about the commit message, if the
code compiles, or if the tests are green.

A quick handover is essential. At the end of the mob session, we squash the WIP commits into expressive
commits and merge into master.

We created the mob tool to simplify this process.

Group Decisions

In software engineering, you constantly compare different alternatives and decide for one. Reversing decisions is
often expensive. Group decisions are superior over individual decisions. In Remote Mob Programming, all
decisions are group decisions.

We minimize technical debt.

With our wealth of know-how, experience, and opinions to discuss, we are able to make well-founded decisions
everyone agrees with. When we are coding, we all agree on changes and code style. As a consequence, we don’t
need code reviews or pull requests.

4/7
We document decisions with extensive consequences using Architecture Decision Records.

Constant Momentum

In a feature branch-based workflow, you are blocked waiting for the code review of your pull request. While
waiting, you start another feature and need to switch context. In a mob session, we have continuous and implicit
code reviews – no feature branches, no waiting, no context switches.

Working alone, you often end up looking up things on Google, in a documentation, or need to figure out how to
proceed. The main purpose of the rest of the mob is to make sure there is constant momentum. They discuss the
problem and think ahead towards the solution, getting rid of any obstacles.

We get into a rewarding flow every day.

As we aren’t blocked by ourselves, we make good progress. It feels great.

Learn from the Team

Sharing knowledge is at the heart of Mob Programming.

Everything the mob does is the result of in-depth discussions. Nothing is done without agreeing on the why.
That’s where everybody learns.

We get better every day by learning from each other

Because the whole teams works on everything together, we’re always on the same level of knowledge and have a
bus factor of the size of the team. We benefit from our different backgrounds and perspectives. This ranges from
learning how to write a good unit test, to debugging effectively, or learning how to prepare a successful meeting.
And we also learn a lot of keyboard shortcuts all the time.

With Mob Programming, onboarding only takes weeks, not years.

Trust

We all work remotely. The client does not see us working. So, management has a natural fear of losing control
over the team.

Also, there is inherent doubt of a team’s productivity, with all team members working on the same issue at the
same time.

In a remote context, trust in the self-organization of a team is elementary.

We build trust by actively communicating.

While management showed us some trust in advance, eventually we earned it through continuous and sincere
communication and always delivering what we committed to.

We write daily check-ins in our team’s chat channel. A check-in is a short recap of stuff that happened or hasn’t
worked out as planned. It could be some personal stuff, too. Management also reads this channel and thereby is
informed. Obviously, we have no need for a Daily Scrum.

We always take care to hold to our commitments and deliver high quality code in time. That builds solid trust in
the long term.

Save the Planet

5/7
Daily commuting causes traffic jams, crowded trains, and significant greenhouse gas emissions. Even worse,
many consultants fly to their customers’ offices.

We don’t travel, so zero greenhouse gas emissions.

No travel means no travel costs for us and our customers. And at home, we always drink our fair-traded flat
white from our Star Wars mugs.

Dine with your Family

As software engineers, we often struggle to balance challenging and rewarding work with time for family and
leisure. Sometimes, it feels mutually exclusive. From our experience, working on challenging and rewarding
projects as a part of an outstanding team requires lots of travelling, staying in hotels overnight, and sometimes
even relocation.

We enjoy more quality time with our families.

We all have young kids. They are the most important thing in our lives.
With Remote Mob Programming we get both, rewarding work and quality time with our families and kids.

Resources
New: We created the website effectivehomeoffice.com listing our equipment.

Methods we use

Daily check-ins to actively communicate our experiences to other teams and managers.
Architecture Decision Records to document the why of important decisions.
Hill Charts to visualize uncertainty and progress.

Software we use

zoom for screensharing

mob for quick git handover (developed by us)
timer (OS X only) for tracking mob intervals
Miro for collaborative whiteboard

Hardware we use

Ubiquiti AmpliFi for great wifi

Blue Yeti Microphone for great audio
Logitech C920 HD Pro Webcam for 1080p video
iPad Pro with Pencil 2 for great collaborative whiteboard

Books

Videos and Podcasts

Press

FAQ

What’s in it for me? (asks the manager / product owner)

Time to market is optimized. With Mob Programming, you minimize wait times and delays.

6/7
In addition, with Remote Mob Programming, you get access to a large pool of remote developers who spend less
on travel. But in the end, we assume it’s time to market that makes the difference.

Is Remote Mob Programming something for every team?

We don’t know.

Remote Mob Programming is intense collaboration. This can be great, or it will quickly reveal any team
dysfunctions.

We think it’s definitely worth a try.

Isn’t one of the main benefits of remote working that you can work the way you
want, and not be under constant supervision of others?
Outstanding question. Working at your own pace is really an advantage of remote work. But after having tried
Remote Mob Programming for several weeks and getting a glimpse of its advantages, we are okay to give that up.

Is it really efficient when everybody works at the same issue at the same time?
Definitely yes, if you want to optimize for time to market and knowledge.

The thought of on always-on camera makes me feel a bit uncomfortable. Do you

get used to it? Is it even necessary?
At first, we felt uncomfortable as well. But yes, you get used to it. And it is necessary because it significantly
improves communication. It really does.

My team would like to try out Remote Mob Programming. How should we start?
That’s great. We recommend selecting a medium-sized feature and try it out with your standard laptop camera
and microphone. One member should read the book Code with the Wisdom of the Crowd by Mark Pearl to be
able to act as a moderator if necessary. Regarding everything else, discover what is working for you.

7/7