Remote Mob Programming Slack Status

New: How to act as a typist and a rotation timer

Remote Mob Programming Screenshot

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

Book on Remote Mob Programming

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.

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.

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.

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

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

Software we use

Hardware we use

Books

Articles

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.

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.

Authors

Simon Simon Harrer is a senior consultant at INNOQ. As part of a remote mob, he fights everyday out for simple solutions with domain-driven design, fitting architectures such as microservices or monoliths, and clean code in Java, Ruby or even JavaScript. He wrote the book Java by Comparison that helps Java beginners to write cleaner code through before/after comparisons, and most recently, co-authored the website Data Mesh Architecture.

Jochen Jochen Christ is a senior consultant at INNOQ. As a specialist for modern Java technologies, he creates elegant solutions with innovative architecture concepts, such as Self-contained Systems, Kubernetes, and cloud computing. Jochen is interested in agile methods, clean code and usable security. Jochen is a speaker at international conferences and enjoys participating in local meetups.

Martin Martin Huber is a senior consultant at INNOQ. More than a decade of his professional life is filled with the design and creation of integration applications in Java. His main focus is on Java EE and web technologies for complex integration challenges. In his free time, he likes to ponder around with Python and to play and coach American football.

Design by Sonja Scheungrab.