Remote Mob Programming at INNOQ

Dr. Simon Harrer

Jochen Christ

Niko Will

Andreas Wissel

Franziska Dessart

Daniel Westheide

Vera Peuntinger

Tina Schönborn

Joshua Töpfer

Martin Huber

Dieser Artikel ist auch auf Deutsch verfügbar

At INNOQ, some teams successfully use Remote Mob Programming in customer projects, some of them even for more than two years. Here are the experiences of four such teams.

It was Woody Zuill who coined the term “Mob Programming” as: everyone on the team working on the same thing, at the same time, in the same place, and on the same computer. Remote Mob Programming uses Zoom instead of a meeting room and the shared screen instead of a shared computer. The team collaborates intensively in this method.

At INNOQ, some teams successfully use this method in customer projects, some even for more than two years. We have collected our experiences on www.remotemobprogramming.org and recorded a podcast on the topic (in german). For this article, we asked four teams from three different industries what their experiences with this particular work method have been. Happy reading!

Team Pluto, e-Commerce industry

How is your team structured?

In the beginning our team consisted of 3 developers from INNOQ and one external product owner. Over the course of the project the customer hired their own people for both product owner as well as developer roles. At peak times we had 4 developers from INNOQ and 3 from the customer. In the meantime, there are only 2 developers from INNOQ in the project.

How did you introduce Remote Mob Programming?

During the project kick-off at the customer’s site, we three INNOQ developers started to develop the first service together to create a common and unified understanding for the further services. After that, everyone went back to working from home and it just felt right to continue working together. And that’s how it stayed.

How has it benefited you?

Out biggest fear was that working from home would become lonely for everybody. This concern has completely disappeared with this method, on the contrary, we feel a very strong team spirit - probably even stronger than working together on site in a team without mob programming.

But maybe there is another reason: A developer in the team became a father and had to take care of his daughter during working hours and carry her around in his arms. Thanks to Remote Mob Programming, this was no problem, because the developer could simply continue to see the shared screen in the Zoom video conference and contribute to the discussion, while the others in the team did the typing.

What challenges did you face and how did you deal with them?

In the beginning, we took too few breaks in the rush of the mob programming flow and brought our team to the brink of exhaustion. That was a tough experience, and after that we were very careful about taking breaks.

There was a time when our team was very big with 7 developers. Too big for a mob. We experimented a lot, and finally came to the following solution: at the beginning of the day, we randomly split the team into two sub-teams. The first sub-team does the next story while the second sub-team does everything else, keeping the first sub-team from being disturbed. It wasn’t always optimal, and we suddenly had much higher coordination needs, but it worked well enough.

What does the customer say?

The product owner is very satisfied. The customer’s developers are too. Here is a little anecdote. We had an event with INNOQ and for a few days the developers of the customer were among themselves in the office of the customer. And although all of them were on site, they decided to continue using Remote Mob Programming.

Would you recommend Remote Mob Programming to others?

Yes. We don’t want to work differently anymore.

Team Saturn, Pharma industry

How is your team structured?

Our team consists of one INNOQ frontend developer and two frontend developers from the customer. Our product owner and scrum master are provided by the customer. The team works completely remote.

How did you introduce Remote Mob Programming?

We had tried Remote Mob Programming several times in our team. The first time was quite chaotic, but ultimately quite enlightening because it exposed poor communication in the team. With a lot of coaching to improve team communication and with the argument “this/that wouldn’t have happened with Remote Mob Programming” everyone could be convinced to try the method a few more times. Now we work exclusively with Remote Mob Programming.

How has it benefited you?

Ultimately, the biggest change for us has been the drastically reduced need for coordination. Dailies have been eliminated, decisions are made ad-hoc instead of requiring dedicated meetings, and everyone knows what is being worked on at all times. The crazy thing is that even though Remote Mob Programming feels slow, time-consuming and a bit unproductive at first, it actually saves time overall. This has impressed us time and time again.

What challenges did you face and how did you deal with them?

We first had to improve communication in the team, because in this way of working you work together so intensely that you can’t simply ignore conflicts. We successfully got to grips with that with a lot of coaching. Apart from that, we generally had a few teething problems because we had little prior knowledge. But now there is the workshop ‘The Remote Mob Programming Experience’ ;-)

Oh yes, bad audio and/or video all day long is a real pain. Investing in good hardware pays off here!

What does the customer say?

“Good idea! The quality of the software product increases greatly and people work together better and more productively” – says the customer’s product owner.

Would you recommend Remote Mob Programming to others?

It doesn’t fit for some activities, especially when you have to think hard. Otherwise, this is already the variant of our choice.

Team Mars, Pharma industry

How is your team structured?

Our team consists of 3 backend developers from INNOQ, distributed all over Germany. Our product owner and scrum master is provided by the customer. Since we are currently still working as a feature team, we occasionally bring a frontend developer into the mob to be able to do the work in the frontend with good quality.

How did you introduce Remote Mob Programming?

At the beginning of the project, we sat down together virtually and talked about how we could imagine working. Since the three of us come from different areas and also call different INNOQ offices our homebase, distributed collaboration was the way to go from the beginning. We heard a lot of good things about Remote Mob Programming from other INNOQ teams and some of us already had first positive experiences with remote pairing and temporary mob programming. We also saw it as a chance to use the different levels of knowledge in the team in the most productive way.

The fact that the corona virus was already raging in Germany at the time certainly contributed to the customer’s acceptance.

How has it benefited you?

A very big and important advantage is the knowledge transfer that takes place automatically. Each project member is an expert in one or more areas, which in fact hardly overlap in our constellation. In the daily doing, one thus gets a very practice-oriented knowledge transfer in a very natural way. The respective knowledge carrier has to verbalize his knowledge and is of course also challenged and questioned by the others.

Three pairs of eyes see more than one ;) Small mistakes, which happen to just about every developer from time to time, can sometimes hold things up for quite a long time. Through the instant review of the written code or the way of working, errors are detected early and can be eliminated. In practice, this saves a lot of time.

At work, you also often come across problems where you have to decide on a solution path. If the three of you weigh up the possible solutions at such points and also discuss the problems of the respective ideas, the probability of deciding on the wrong implementation due to a lack of background knowledge is significantly lower.

Major architectural decisions can also be made faster and better this way. Together, an Architecture Decision Record is prepared in which the possible options are considered and listed with advantages and disadvantages. Then you can directly move on to the decision, since all those who should be involved in the decision are already integrated through the working method as a mob. The decision is then documented in the Architecture Decision Record and implementation can begin.

The fact that in distributed teams with little real social interaction this creates more of a feeling of team membership and trust also helps on the interpersonal level.

What challenges did you face and how did you deal with them?

Working together all the time requires a lot of concentration and costs a lot of energy. Especially in the beginning, it took us a while to realize this and consciously build in breaks. The introduction of an extended, two-hour lunch break also helped us.

Another challenge is the high level of coupling between the customer’s applications. For example, there are always times when we as a team need to make changes to another team’s application. All changes we make there, we discuss with the team beforehand and also expect a code review afterwards. Unfortunately, this costs a lot of time and leads to context changes. This challenge is currently being addressed in the project, so we have identified bounded contexts through event storming and are now re-cutting the applications to be able to deliver features from one application if possible. As a result, our features will only entail changes to our code. This should make working in the mob even more productive.

Unfortunately, by working from home, we don’t see when our product owner is at his desk and not in a meeting at the moment. This makes it difficult for us to get answers to questions from the Product Owner Of course, you can try to call him, but you don’t know if that will be successful. Therefore, we have agreed to schedule a 15-minute slot at the beginning of our workday where the PO is available to us. When we have issues to discuss, we write a message to our product owner and he just comes into our virtual room. Likewise, this time slot is also used when the product owner would like to have an interim status from us.

What does the customer say?

Our customer likes Remote Mob Programming very much, because it is mandatory that people exchange information and thus no knowledge silos can develop. Code reviews have often led to great frustration. Be it conceptual errors that were found relatively late or simply the waiting time until the review was done. This is now a thing of the past, since all team members are involved in the development process and uncertain points can be discovered and clarified at an early stage.

Would you recommend Remote Mob Programming to others?

Yes! :)

Team Jupiter, Online marketplace

How is your team structured?

Our entire team consisted of three backend developers, one frontend developer and one product owner - all from INNOQ. The frontend developer mainly worked alone, while the three backend developers worked together as a mob.

How did you introduce Remote Mob Programming?

In the beginning, we discussed which mode we wanted to work in. The service was quite small, so it wasn’t good to work on it in parallel anyway. Also, since we used a new technology, Kotlin, it was important for us to distribute the knowledge within the team. That’s why we decided to work in a mob. For the first six months, we were present in the Berlin office. It wasn’t until the lockdown that we moved to Remote Mob Programming.

How has it benefited you?

A big advantage that became apparent quickly was the better distribution of knowledge in our team. The fact that we worked almost permanently in the mob prevented knowledge islands from forming in the code base of the new service. In addition, it was much easier to make small and large architectural decisions together, since everyone involved had the same level of knowledge. Through this, we have also made more well-founded architecture decisions than we would have been able to as individual team members.

Another effect that became noticeable was that technical gaps and ambiguities were identified more quickly and clarified accordingly. In our experience, if you work alone, you often overlook these at the beginning and only come across them late in the development process, when you have been going in the wrong direction for a long time.

By constantly working together in the mob, a common code style also developed quickly, as no one could push through their personal preferences. This of course made it easier to find your way around our codebase, even if you were absent for a while, for example due to illness or vacation. In general, working in a mob made our code easier to read and maintain - the mob was simply a more direct and rigorous quality control than a code review in the pull request model usually is. This was also due to the fact that feedback came immediately, rather than after the feature was already implemented.

By eliminating code reviews, we were also able to get features implemented and into production faster. There was no waiting for code review and no merge conflicts - and, of course, no context switching when someone had to go back and forth between developing one feature and reviewing an entirely different feature.

Although parts of the mob were absent on different days due to part-time work, at least one person was constantly present on each consecutive day and could thus carry on the knowledge of what was done on the last day. Even in the case of vacations or other absences, the joint work in the mob eliminated long handovers.

When we left the project, we also used mob programming for the handover. To do this, we formed a large mob from our subteam and some people from the team that was to take over our services. In the process, we consistently suspended at the typist role. Gradually, we were also able to hold back more and more on implementation suggestions until the other team was finally able to implement features completely without our support. The other team was as enthusiastic about this approach as we were. It turned out that the advantages that Mob Programming offers in terms of knowledge distribution also prove very useful when handing over to another team.

What challenges did you face and how did you deal with them?

During the phase when we worked on site in the office, it was not always easy not to disturb the other people present in the open-plan office. Although we had access to a separate meeting room with a large screen, this was not always available to us. In addition, the different keyboard layouts on the various computers caused us difficulties, as we did not have a dedicated mob computer available.

When we did work remotely, our Git handover was not very efficient. The main reason was that the client’s VPN slowed down the transmission of our video calls and screen transfer so much that we were forced to connect to the VPN exclusively for pushing - a big overhead that also always interrupted the video call for the person in question.

What does the customer say?

The customer had no interest in micromanagement. Instead, the focus was always on results. What counted was that we implemented our features on time - and that always worked wonderfully in this constellation.

Our product owner was able to overcome his doubts quickly. In a retrospective, he was very positive about the speed at which features were implemented and put into production. He was also impressed by the fact that he always had at least one person who could provide him with information on all aspects of the new service.

Would you recommend Remote Mob Programming to others?

Basically, Mob Programming is the best of all working modes for us so far, and we wish to work only in this mode. Of course, this only makes sense if everyone involved has a similar attitude towards Mob Programming. While we tend to prefer to do Mob Programming in presence, Remote Mob Programming has also proven successful for us. In the future, however, we would probably consistently use the mob tool to achieve faster handovers.

The Remote Mob Programming Experience

Got interested in Remote Mob Programming? INNOQ offers a workshop called The Remote Mob Programming Experience to get to know the method in one day with a realistic case study – and it’s fun too, we promise.