TL;DR
Are you working in a remote and distributed team and you have issues with your team culture, knowledge sharing and/or productivity because of too many context switches? Try out remote mob programming!
Hybrid work
At Upvest we have a hybrid working environment which allows employees to work remotely and if they wish to, visit one of our offices. I joined the company in the middle of the pandemic when working from home was the default for most companies. However, this did not really change much after the offices were opened up again. We are still allowed to work from wherever we wish (as long as it works for the team and matches compliance and other regulations). While this has many advantages, it has some drawbacks too. The most significant ones for me are more difficulty sharing knowledge and the lack of social interaction with colleagues. As a people manager, leading a team of four people, and at the same time working almost 100% remotely, it is even more important to me.
The problem with four-eyes
Another very annoying problem (for all kinds of developers) is distractions from parallel work streams. Nowadays, many companies apply the four-eyes principle for code changes and we are even obliged to do so because we are a regulated financial company. In our day-to-day work, this means we complete some task on a branch, create a pull request for it and wait for someone to approve it after a code review. For the reviewer, this means pausing the current task and gathering enough of the context to be able to responsibly review the PR. In the meantime, the author of the PR can not continue on the current task and starts another one, switching contexts. Often such a review cannot be finished without questions or remarks, but ends up in asynchronous discussions, e.g. why did the author solve something in this way or name a variable like that?. So, both the author and the reviewer need to jump back and forth between different contexts. This is not just annoying, it costs a lot of time and mental capacity.
Mob programming as a solution
All the issues mentioned above (and many more) can be solved, while still enjoying all the benefits of working remotely, by leveraging remote mob programming. I could now give you a more detailed description of what exactly this is, however, my former colleagues Simon Harrer, Jochen Christ, and Martin Huber did a great job describing it on remotemobprogramming.org and even developed a superb tool to support developers that want to try it out, called mob.sh. At this point, I would encourage you to go there and read first or let me finish my point and make you even more curious to read about it later.
How we operate
Instead of repeating the very professional, kind of marketing material from the website, I’d like to describe to you, what a regular working day looks like for us. Every one of us has a slightly different way to start and end the day. Some prefer starting the workday early when they are mostly alone at work and do not have many distractions yet. Others are not early birds and prefer to start later and stay longer in the evening. We all have different routines and constraints in our private lives. Sleeping habits, hobbies or private duties like bringing the children to the child care. Therefore, it is natural that we like our jobs to be as flexible as possible.
However, at some point, we agreed on the day before, as a group, we will meet in a virtual room and continue mob programming, from where we left off the day before. There is no need for the whole group to be there already. As long as at least two people are present, we are good to go. This holds true throughout the day and in the evening. Team members are always free to join or leave the mob whenever it makes sense to them. In the evening, we discuss the best starting point for the following day. As long as two people are still available, we continue collaborating. Part of this collaboration is not only writing code, but also tests, documentation, deploying services and things like grooming new tickets or solving production issues, and in general every task that needs to be done as a product engineer. None of us is alone on any of these responsibilities.
Synchronous decision making
The most valuable thing here is that there are no asynchronous discussions needed to come to a decision. Instead, we discuss every topic that comes up immediately, as a group. This way we benefit from the experience of a lot of different people at the same time. Every team member is equal and we decide together. This also means that every team member can have an impact, which is very motivating. On the other hand, once we have agreed on some solution, the whole team knows about it and understands the context of the decision. This iss the main reason our codebase is very clean and consistent throughout all the different services that are part of our domain.
Knowledge sharing
A great side effect is that knowledge is shared immediately because everyone is free to ask questions at any time. Everyone is free to bring in their experience. This helps a lot in terms of mentoring junior developers and it is an awesome way to improve confidence for duties like being on-call. We can see how other team members are analysing issues and working with the tools at hand.
Team culture
Besides the more professional and task-solving part of this collaboration, another very important advantage is that we were able to build an awesome team culture by collaborating this closely. There is no cherry-picking of tasks that need to be done. No one is more important than the other. All are equal and can have an equally important impact. Issues are tackled as a team, and we own the outcome as a team, which means, we celebrate as a team. We trust each other and we value each other. If we have some spare time in between, we discuss a lot of private topics, too. This helps to prevent feeling alone or getting frustrated and lets us grow together as a team even more.
Sensible sizing
In the meantime, the team has grown so much that one remote programming mob is sometimes not effective anymore. It’s only good to have five people in the same virtual room when tackling very complex problems or knowledge sharing. For working on tickets, two to four people are a better fit. That’s why we have started to split the team and decide on a day-to-day basis, what collaboration mode makes the most sense. Sometimes we have two mobs in parallel (a two-person and a three-person mob), and sometimes some smaller or more technical tasks can be solved perfectly well by a single person.
Summing up
No one can tell you what should work for your team, but it does no harm to try different things out. If you try out remote mob programming, I’d be happy to hear about your experience.