New: How to act as a typist and a rotation timer
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
Check out our free eBook on Remote Mob Programming at leanpub and the Kindle book on Amazon.com.
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
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.
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 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.
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 the mob tool 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 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.
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 every day.
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.
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
- Code with the Wisdom of the Crowd by Mark Pearl
- Mob Programming by Woody Zuill and Kevin Meadows
- Ensemble Programming Guidebook by Maaret Pyhäjärvi
- Debugging Teams by Brian Fitzpatrick and Ben Collins-Sussman
Articles
- Remote Mob Programming at Shopify
- Remote Mob Programming at INNOQ
- Round-robin coding (INNOQ)
- Mob Programming – Remote Teams in the Flow (T-Systems Multimedia Solutions)
- Our experience with Remote Mob Programming (PayFit)
- Mob programming builds better remote development teams (Upvest)
Videos and Podcasts
- Remote Mob Programming (EN) – INNOQ Technology Day
- Mob Programming: A Whole Team Approach by Woody Zuill
- Leaping back into the code via Remote Mobbing by Sal Freudenberg
- Episode 'Mob' in Agile in 3 Minutes by Amitai Schleier
- JCon 2019: Remote Mob Programming by Jochen (German)
- Interview of Simon Harrer by Marc Löffler on the Passionate Teams Podcast (German)
- Episode 'Remote Mob Programming with Jochen Christ, Franziska Dessart, Simon Harrer, Martin Huber' in Software Architektur im Stream by Eberhard Wolff (German)
- heise.de article (German)
- Interview on the INNOQ podcast (German)
- Interview on the Mob Mentality show
- Interview on the whereby.com blog
Time to market is optimized. With Mob Programming, you minimize wait times and delays.
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.
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.
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.
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.
Design by Sonja Scheungrab.