Q&A on the Book Remote Mob Programming

In the book Remote Mob Programming: At home, but not alone Simon Harrer, Jochen Christ, and Martin Huber share their experience doing mob programming while working from home for over a year.

InfoQ interviewed Harrer, Christ, and Huber about what a day in their life looks like when they’re mob programming, their time slot for rotating roles, documenting decisions, prerequisites to make remote mob programming possible, tools and equipment for remote mob programming, meeting face-to-face, benefits of remote mob programming, and getting started with mob programming.

InfoQ: What made you decide to write this book?

Simon Harrer: For over 1.5 years we’ve been working full time using remote mob programming. At one point, I realized that I didn’t want to work differently anymore. It fits perfectly to my way of living: I have a family with two very young kids, live in the countryside, and still want to work with awesome people on great projects. I wanted to share my experience so that it would help others in similar situations.

Jochen Christ: Many people are skeptical about working from home for different reasons. The most pressing issue typically is (social) isolation — being disconnected from the others in the team. To be honest, I was skeptical, too, about whether working full time from home was right for me. I always felt as though I was working alone when I worked from home, not together as part of a team. This changed with remote mob programming. It’s real team work. To me, this is the solution for making home office work. That’s why I wanted to share what works for us.

Martin Huber: At first, I was very skeptical, too, especially with regards to it being live and on camera all the time. It was very strange to be watched all the time and the sort of working discipline that comes along with it.

But once we got into a marvelous programming flow, you forget about all of this. It is very energizing for me when we program, create things and learn from each other all within one frame of time. At the beginning it was not easy to align our personal needs and the needs of working together, but I am proud of how we pulled this all together. It definitely is worth talking and writing about.

InfoQ: For whom is this book intended?

Harrer: We’ve written the book primarily for software engineers like us who are curious about better ways of collaborating. But I think it may also help managers and agile leaders to enable remote teams.

InfoQ: How would you define remote mob programming?

Huber: We extend Woody Zuill’s definition of mob programming: "All the brilliant people working on the same thing, at the same time, in the same [virtual] space, and on the same [shared screen]". As you can see, it’s not limited to coding - it’s working together on the same architecture decisions, stories, testing, and documentation.

Christ: Remote mob programming is real team work in a distributed team. The team is together all day and helps one another and has one goal in mind: finish the task at hand in the best possible way. And the best possible way is the conjunction of the wisdom of all team members.

InfoQ: What does a day in your life look like when you're mob programming?

Christ: I start my computer, open Zoom, and join our virtual meeting room. It's a great time for small talk until everybody arrives, and then we start. We try to start around 9 am. Normally, we simply resume yesterday's work. When a feature is done, we directly push it into production and move on to the next most important thing to do.

Huber: Normally, I’m either the typist (the person sharing the screen) or part of the rest of the mob. When implementing a feature, the typist’s role rotates regularly. That’s what it makes so varied. I think it’s important to mention that when working together so closely, issues quickly arise. That’s why it’s critical to address them right when they occur with a short retrospective, so that the team can resolve it and just continue afterwards.

Harrer: Just two things to add: one about remote mob programming is that we have to align our working hours, including lunch. That was strange at first, because home office typically means a lot of freedom in choosing your working hours. But to us, the trade-off is really worth it. Another thing: at the end of the day, we all write a short summary of the day in a company-wide chat channel. You can write anything, from reporting that an important feature is now done, ranting about another useless meeting, to talking about your delicious lunch. It’s similar to the checkins by Basecamp, but we like to call them checkouts. And it turns out that a lot of people read them to get insights into how our project is progressing.

InfoQ: What's the time slot for rotating roles? How did you come up with this?

Huber: We rotate the typist every 10 minutes. It was painful to get to this interval. We started with longer periods (30min, 1 hour, even 2 hours), but this was just too exhausting for everybody. Shorter periods were annoying and inefficient, as the remote handover takes way longer compared to on-premise mobbing. This broke the flow too often.

Christ: By the way, we made some optimizations to automate the handover of the code in a temporary git branch with a little tool called mob. Currently, we "lose" 20-30 seconds during a handover, which is acceptable for us.

Harrer: Rotation depends on the team size. We’ve got the rule of thumb that everyone should be typist every half an hour. We are a team of three. That’s why we ended up with a 10-minute rotation interval.

InfoQ: How do you document architectural and other important decisions?

Christ: We use Architecture Decision Records to elaborate decisions with severe consequences. We document records in a Wiki. Fun fact: we even share the screen while writing and discussing the decision records, so that everybody is involved.

InfoQ: What are the prerequisites for making remote mob programming possible?

Huber: It works best when everybody works remotely and has a fast and stable internet connection.

Christ: But most important, you need your employer’s trust. You are not working in the office; your manager does not see you working. And the inherent doubt: is it really efficient when all team members work on the same issue? (Spoiler: it is.)

InfoQ: What tools and equipment do you use for remote mob programming?

Harrer: A good microphone is the most important equipment. Sound quality matters when you have to listen to your team all day. That’s why we invested in a professional microphone with sound direction and noise cancelling. We can recommend the Blue Yeti.

Huber: We use Zoom.us all day for screen sharing and video conferencing. We prefer an external camera that we mount on eye level. For that, we recommend the Logitech HD Pro Webcam C920.

InfoQ: You mentioned in the book that from time to time you do meet each other face-to-face. What activities do you prefer to do when you are together?

Christ: We prefer planning our retrospectives on these days. Talking about sensitive issues is just so much easier in person. Also, online whiteboard solutions like miro.com are good, but not great. A whiteboard in a room full of people works far better than any online solution. So, we like to schedule planning and architecture workshops for these days.

Harrer: And, we use the common time to socialize. Getting to know each other still works best while having a barbecue or enjoying drinks in a bar. :)

InfoQ: What benefits does remote mob programming bring you?

Huber: As already mentioned, we get into a rewarding programming flow. It feels great to deliver new features with superior quality into production within hours.

Christ: And, we don’t waste time commuting. We have more time with our families.

Harrer: For me, it’s like being on the learning highway. I’ve learned more in the last year than ever before. While collaborating so closely, you get a sneak peek into your colleagues’ thoughts and ways of thinking; like how they approach complicated stories, handle hard-to-deal-with stakeholders, or they simply show you new keyboard shortcuts in the IDE.

InfoQ: If people want to try out remote mob programming, how can they start?

Harrer: Obviously, we recommend reading our book. ;-). Choose a medium-sized feature and discover what works for you.

Christ: Don’t buy hardware right away. Just start with what you have. You can upgrade when using remote mob programming more often.

Huber: It really helps, from my perspective, to have someone on your team who has invested some time in reading about mob programming in general. I can recommend the book Code with the Wisdom of the Crowd by Mark Pearl as a starting resource.

About the Book Authors

Dr. Simon Harrer (@simonharrer) is a senior consultant at INNOQ. Sharing knowledge is his passion, be it through books, articles, talks, or even tweets. From his experience as a lecturer at the University of Bamberg, Harrer has co-authored the best-selling book Java by Comparison that helps Java beginners to write cleaner code through before/after comparisons. Apart from co-authoring the book on Remote Mob Programming, he has co-started a microsite on GitOps to clear up the confusion around this term. When he is not building microservices on Kubernetes, you might see him moderating event storming workshops or helping young PhD students to document their research prototypes with arc42.

Jochen Christ (@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. Christ is interested in agile methods, clean code and usable security. Christ is a speaker at international conferences and enjoys participating in local meetups.

Martin Huber (@Waterback) 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 over Python and to play and coach American football.