Remote Mob Programming
Remote Mob Programming
Simon Harrer
Martin Huber
Remote Mob
Programming
At home, but not alone
Jochen Christ
Simon Harrer
Martin Huber
Our Setup 19
Video Conferencing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Microphone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Camera . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Whiteboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
FAQ 25
Resources 31
Foreword
When I was first introduced to Mob Programming, it was as something we did together
in person.
Because of the benefits I had seen from mobbing I decided to write a book on it.
One of the first questions my editor had for me was could this be done remotely?
My own team had experimented with mobbing remotely with limited success and I was
doubtful if remote work and mob programming could ever work effectively together.
I’m happy to see that Simon, Jochen and Martin have proven me wrong.
They are the first team I’ve come across to document how to mob effectively for long
periods of time while working remotely.
I’m very pleased to see them share their insights with the rest of the world.
Turns out it is possible to have the convenience of remote work and the power of mob
programming at the same time.
Mark Pearl
Author of Code with the Wisdom of the Crowd1
1
https://pragprog.com/book/mpmob
1
Remote Mob Programming
Remote Mob Programming combines two ways of working: Mob Programming and
working as a distributed team. Woody Zuill describes Mob Programming1 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, a team
collaborates closely in the same virtual space.
In August 2018, three of us started a project together. For the project kick-off, we came
together on-site for two weeks. We quickly decided that we wanted to develop the
first components together to discuss architecture and find a common code style. For
that, we used Mob Programming on-site. This worked out pretty well, so we wanted
to continue working so intensely together from our home offices. So we simply tried
out Mob Programming remotely.
We’ve written up our experiences. And we’d like to encourage you to try it out as well!
Happy reading!
1
https://mobprogramming.org
3
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 shares a room. This would lead to
information asymmetry2 through communication shortcuts. That typically happens
in on-site meetings with a few remote attendees.
The issue with working from home is isolation. It lacks the exchange with colleagues
in the hallway, during lunch, or after meetings.
2
https://en.wikipedia.org/wiki/Information_asymmetry
4
Camera Always On
Working face-to-face is powerful because we communicate with the whole body, not
just our words. Rolling eyes, yawning, looking pensive, or raising an eyebrow are just
a few examples for that.
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 our microphones when we go away from the
keyboard, but leave the camera on.
5
Regular On-Site Meetings
The better everybody knows each other, the better everybody can collaborate re-
motely. Getting to know each other still works best on-site. Drinking cold beverages
together online with a virtual fireplace running on the shared screen just isn’t the
same.
3
https://www.innoq.com/blog/st/2012/09/innoq-company-events
6
Same Time
One of the prerequisites of Mob Programming is working at the same time.
7
Typist and the Rest of the Mob
We prefer the terminology from Code with the Wisdom of the Crowd by Mark
Pearl4 :
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.
4
https://pragprog.com/book/mpmob
8
Screen Sharing
The typist shares their primary screen, showing the code, ticket, or wiki the team is
working on. It is highly efficient to work with the actual artifact in contrast to having
abstract meta discussions.
We accept the time penalty to switch the shared screen at the start of the next mob
interval.
9
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.
Surprisingly, taking your turn as a typist allows you a mental relaxation. You just wait
for instructions.
10
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.
A quick handover is essential. At the end of the mob session, we squash5 the WIP
commits into expressive commits and merge into master.
We created a small command line tool mob6 to simplify the handover through git.
5
https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History
6
https://github.com/remotemobprogramming/mob
11
Small Team
The whole team works and focuses on the same thing. 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.
Regardless of your team size, make sure that every member takes on the typist role
every 30 to 45 minutes to stay focused. Our team of four works well with a 10-minute
rotation.
12
Group Decisions
In software engineering, you constantly compare different alternatives and decide for
one. Reversing decisions is often expensive. Group decisions are superior over indi-
vidual decisions7 . In Remote Mob Programming, all decisions are group decisions.
7
https://environmentalevidencejournal.biomedcentral.com/articles/10.118
6/s13750-016-0066-7
8
http://thinkrelevance.com/blog/2011/11/15/documenting-architecture-
decisions
13
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.
14
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.
9
https://en.wikipedia.org/wiki/Bus_factor
15
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.
We write daily check-ins10 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 Scrum11 .
We always take care to hold to our commitments and deliver high quality code in time.
That builds solid trust in the long term.
10
https://basecamp.com/features/checkins
11
https://www.scrum.org/resources/what-is-a-daily-scrum
16
Save the Planet
Daily commuting causes traffic jams, crowded trains, and significant greenhouse gas
emissions. Even worse, many consultants fly to their customers’ offices.
17
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.
18
Our Setup
A variety of software and hardware make our way of working possible. We evaluated a
range of services and devices, and even created a small software tool by ourselves. In
this section, we describe the tools we ended up with to mob together remotely every
day.
Video Conferencing
We use video conferencing and screensharing all day long. That’s why the tools must
be reliable and usable.
We started using Whereby. The concept of virtual rooms as URLs, not bound to a single
person, has been and still is a perfect fit for Remote Mob Programming. At the start
of the day, the room simply fills up until the mob can start after a little bit of small
talk. Technology-wise, Whereby uses WebRTC within the browser supporting up to
19
12 people. This allows anybody to easily join the virtual room without installing any
software, simply by entering the URL of the virtual room in the browser.
Life was great until a Linux-developer joined our team. WebRTC requires so much
processing power on Linux that it slows down everything else. That’s why we had to
have a look around for alternatives.
We ended up using Zoom. Simply because it works well on Linux as its native client
requires less CPU. Plus you can have up to 100 people in your session, although you
probably don’t want to. So, in summary, Zoom works for us, but it has its limitation as
well. It lacks the concept of virtual rooms so you need a host for every meeting. And
because it requires the installation of a native client, it’s a little bit of a hassle to get
people in our session for a quick help.
20
Microphone
Great audio is essential. Background noise or echos all day long is really exhausting.
That’s why we all bought a studio microphone, the Blue Yeti Microphone. This micro-
phone felt like a liberation, because we no longer had to wear headsets all day long,
every day of the week. It works great in our quiet home office environment. And it
even generates a feel of sitting right next to each other.
Make sure that you configure it right. Set the input pattern to cardioid mode, optimized
for voices directly in front of the microphone. But be aware that the microphone is very
sensitive – it will transmit even smaller noises quite clearly, such as eating crisps.
21
Camera
We feel most comfortable having the camera on eye level. But that’s really hard with
laptop cameras, as they often result in a frog perspective. And in our home office, we
enjoy working on our large external screens. We recommend the Logitech C920 HD Pro
Webcam as it can be mounted on top of external screens.
22
Whiteboard
Quickly sketching out an idea is important. We missed the whiteboard in our remote
setting and looked for solutions. We haven’t found a perfect replacement yet. The best
alternative we did find, however, is using an iPad with an Apple Pencil in combination
with a collaborative whiteboard such as Miro.
23
Handover
A quick handover keeps the flow. We developed a small tool called mob that simplifies
a handover through git. It pushes any changes to a temporary branch from which
the next typist pulls. And it starts a timer. It’s written in Go and freely available on
GitHub1 .
1
https://github.com/remotemobprogramming/mob
24
FAQ
How to convince my boss?
Don’t ask. Just try it out. And then share your experiences with your boss.
And with Remote Mob Programming, you get access to a large pool of remote develop-
ers who spend less on travel. But in the end, we assume it’s time to market that makes
the difference.
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?
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 at its advantages,
we are okay to give that up.
25
How did you end up using Remote Mob Programming?
In August 2018, the three of us started a new project. Until then, we haven’t worked
together yet. We started with a kick-off week at the customer. For us, it was essential
to discuss and make all fundamental decisions like service boundaries, technologies,
naming, coding styles, and first and foremost, and spaces vs. tabs together. For that,
we wanted to build our very first service collaboratively, and Simon had the idea to
use Mob Programming. This felt so good that we continued to use Mob Programming
back in home office. Until now.
Is Mob Programming simply a fit for your current task or a fit for
any task?
We believe that Mob Programming is suitable for any complex task. It, however, is
paramount that the team size is right (read: not too big). From our experience, we
recommend a team size of four. In addition, we form a cross-functional team of
an independent domain at our customer, meaning we implement clear and specific
business functionality and run the software as self-contained systems.
How did your customer reacted to the fact that you’re coding
everything together?
Our customer invests heavily in self-organizing teams. They trust us that we do all
things necessary to make the project a success. They, of course, raised questions and
had comments on our way of working. But we actively communicated our progress.
And it helps to deliver.
26
Do you feel a sense of peer pressure always sitting in front of
your screen at the same time? What about breaks?
Somewhat yes. And sometimes it’s annoying, because there is peer pressure. On the
other way, this leads to discipline and focus, keeping Twitter and co at bay. Because of
this, breaks are essential, especially for feeding the social media dragon. And, to our
regret, we neglected making sufficient breaks at the beginning because of the flow. But
over time, it evened out and we take a break every two hours.
27
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.
1
https://pragprog.com/book/mpmob
28
About the Authors
Jochen Christ Jochen is a senior consultant at INNOQ. As a specialist
for modern Java technologies, he creates elegant solutions
with innovative architecture concepts, such as Microser-
vices, Docker and cloud computing. Jochen is interested
in agile methods, clean code and usable security. He is a
F jochen_christ speaker at international conferences and enjoys partici-
pating in local meetups.
1
https://java.by-comparison.com
29
Resources
Books
• Code with the Wisdom of the Crowd by Mark Pearl1
• Mob Programming by Woody Zuill and Kevin Meadows2
• Mob Programming Guidebook by Maaret Pyhäjärvi3
• Debugging Teams by Brian Fitzpatrick and Ben Collins-Sussman4
Videos
• Mob Programming: A Whole Team Approach by Woody Zuill5
• Leaping back into the code via Remote Mobbing by Sal Freudenberg6
Podcasts
• Episode ‘Mob’ in Agile in 3 Minutes by Amitai Schleier7
• Episode ‘61 Remote Mob Programming - Home but not alone’ in INNOQ Podcast
(German)8
1
https://pragprog.com/book/mpmob
2
https://leanpub.com/mobprogramming
3
https://leanpub.com/mobprogrammingguidebook
4
https://shop.oreilly.com/product/0636920042372.do
5
https://www.youtube.com/watch?v=SHOVVnRB4h0
6
https://www.pscp.tv/w/1kvKpEEklQQGE?t=24s
7
https://agilein3minut.es/32
8
https://www.innoq.com/de/podcast/061-remote-mob-programming/
31
Remote Mob Programming combines two ways
of working: Mob Programming and working as a
distributed team. Jochen Christ, Simon Harrer
and Martin Huber share their experiences with
their working model – and why they don’t want
to work differently anymore.
innoq.com/remotemob 978-3-9821126-0-2