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.
Below, we summarize the essentials of successful Remote Mob Programming as we understand them.
For Remote Mob Programming, 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.
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.
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.
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.
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.
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.
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.
We feel most comfortable working in our own individual environment. It is where we are most productive.
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 lead 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.
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.
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 a small tool mob to simplify this process.
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 are happy with our decisions.
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.
We document decisions with extensive consequences using Architecture Decision Records.
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 everyday.
As we aren’t blocked by ourselves, we make good progress. It feels great.
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.
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.
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.
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.
Videos and Podcasts
Software we use
Hardware we use
Design by Sonja Scheungrab.
Supported by INNOQ.