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 contradicts with working as a distributed team at first glance, but actually, it goes together very 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
Below, we summarize the essentials of successful Remote Mob Programming as we understand them.
- Remote Everybody
- Camera Always On
- Regular On-Site Meetings
- Small Team
- Same Time
- Typist and the Rest of the Mob
- Screen Sharing
- 10 Minute Intervals
- Git Handover
- Group Decisions
- Constant Momentum
- Learn from the team
- Trust
- Save the Planet
- Dine with your Family
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 due to information asymmetry.
We all work from home, but don't feel alone.
We enjoy working from home: 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 one'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 can talk at the same time. With larger teams, the individual speaking time shrinks, making it harder to stay focused. It is easy to get mentally absent. Also, expect technical issues, such as connectivity problems or interfering noise, to happen more frequently, that blocks the whole team.
We have a team of four.
Obviously, the mininum 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 that with one being absent, the rest still forms a mob.
One of the prerequisites of Mob Programming is to be working at the same time.
We mob at least six hours a day.
To reach these six hours, we align our core working time 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 adopt the terminology from Code with the Wisdom of the Crowd by Mark Pearl:
One 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 indiviual 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 enforces us to focus. It is highly efficient to work with actual code in contrast to have abstract meta discussions.
We tried collaboration IDEs.
Surprisingly, we even noticed 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. 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 about, 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 severe 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 the 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 for things on Google, in 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, over debugging effectively, to prepare a successful meeting. And we also learn a lot of keyboard shortcuts as well.
With Mob Programming, onboarding only takes weeks, not years.
We all work remote. The client does not see us working. Management had a natural fear of losing control over the team.
Also, there is inherent doubt on 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 gave us some trust in advance, eventually we earned it through continuous and sincere communication and always holding to our commitments.
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 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 coffee from our Star Wars mugs.
As software engineers, we struggle to balance challenging and rewarding work with time for family and leisure. Often 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 overnight in hotels, 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.
Books
- Code with the Wisdom of the Crowd by Mark Pearl
- Mob Programming by Woody Zuill and Kevin Meadows
- Mob Programming Guidebook by Maaret Pyhäjärvi
- Debugging Teams by Brian Fitzpatrick and Ben Collins-Sussman
Videos
- Mob Programming: A Whole Team Approach by Woody Zuill
- Leaping back into the code via Remote Mobbing by Sal Freudenberg
Software we use
- appear.in for screensharing
- mob for quick git handover (developed by us)
- timer (OS X only) for tracking mob intervals
Hardware we use
- Blue Yeti Microphone for great audio
- Logitech C920 HD Pro Webcam for 1080p video
Content by Simon Harrer, Jochen Christ, and Martin Huber.
Design by Sonja Scheungrab.
Supported by INNOQ.