Remote mob programming for a remote era

New solutions for a new era of work

Avenga Labs is constantly scouting for new technologies and trends in the enterprise IT world. I’ve had my own observations and opinions about the future of work in the digital era, which I shared recently.

Sometimes, the new interesting findings stem from regular news research or interesting meetings. Yet, sometimes those are the discussions with our business partners that bring about some riveting insights. Neither Avenga nor I am associated with the creation of this trend, but I’ve found it interesting enough to analyze it in my Avenga Labs work. Technologies change faster than the way of working, however the global pandemic and immediate rise of hybrid work models, also popularized new ways of working within teams. These new times mean new challenges and new solutions. Remote Mob Programming is an interesting example of a new way of working during this new era of distributed enterprise. It mainly applies to software teams and data science teams, but other types of teams can make use of it as well.

Rules of Remote Mob Programming

Remote mob programming is a set of rules and techniques that were established by its creators. Let me explain them and comment along the way. The opinions are mine and mine alone, and you are free to have your own opinion and share them with me. As always, I will try to look at both sides of the coin, however asymmetric it might be.

Everybody works remotely

The primary rule is that everyone works in their home office environment. This strong rule was created to avoid information asymmetry between the team working in one room and the team members working remotely in other locations.

I’m glad the creators addressed the elephant in the room which is unfairness, bias, and even corporate ostracism between office teams and remote teams. Of course, it doesn’t always have to be this way, but this problem has been recognized by many organizations and teams.

However, there’s also a drawback to this approach as many people do not have the right environment to work remotely at their homes, so they need to go to co-working spaces or to their offices to be able to work at all.

The camera is always on

Because there are no physical meetings at the office or coworking space, it is strongly recommended to have the camera on at all times, even if someone is taking a break (the microphone is then switched off but the camera stays on all the time).

This is expected to create a culture of mutual respect and work engagement, and I fully support this for every online meeting.

In the case of remote mob programming it means a workday-long meeting. However, there are breaks and 10 minute intervals of full-focus activity. It greatly helps with concentration on the task at hand by all the team members.

But, I have to note that staring at the screen for an entire day, every day, and talking to co-workers is not the way I’d like to do things. It’s good to exchange opinions and discuss things, but staying present with the camera on and with your constant attention on the de facto meeting, it’s not something I like to do personally.

So, I like cameras on during meetings, however a day-long meeting, which is at the core of this methodology, is not something I’d recommend.

Regular on-site meetings

Creators want the teams to meet outside work hours in order to create a bond with each other, including their families; for instance at barbecues, etc. This is something that many will like within this technique as a team-building experience, as it is simply a humanly enjoyable activity.

However, there’s also a significant group that does not want to mix their private and work lives. They have different circles of close people and want to spend more time together with their own families.

Crossing work-life boundaries requires a lot of empathy and understanding of different lifestyle choices and points of view.

Small teams

This technique only appears to work for small teams. Yes we’ve all heard that before, that small teams of 3 to 5 people are the most effective. Add at least one more team member and the efficiency drops because of the communication and synchronization overheads.

However, not everything can be done in small teams and there are large projects which need as much velocity as possible, even at the expense of the overall efficiency. This technique could be used for copious sub-teams within one project with additional synchronization layers needed to coordinate all the teams.

Close collaboration inside the small teams is an easy way to create a set of small silos. Nonetheless, it also nurtures their microcultures and growing inability to collaborate with external teams.

It also affects technical debt, as locally chosen technologies and patterns will always differ from team to team. Hence, again, architectural governance is needed to avoid messy code and unstable products.

It’s not an easy job to do, but all the mentioned challenges are always faced by a large team comprising many small teams. And yes, the issue reaches way beyond just this way of working.

Same time

Everybody in the team works during the same hours. Even the lunch breaks are synchronized. Of course, from time to time, one of the members may run on their errands during working hours, but as a rule everyone is available during a specified time window.

This greatly helps to keep the entire team in sync, when everybody is engaged, and does not wait for someone else to start working. Also, nobody gets bothered after hours.

However, I can imagine many people consider these rules as too strict and limiting, but having said that, it definitely reduces waiting times and increases engagement.

Screen sharing and the role of a typist

Everybody looks at the shared screen and works on the same code. (No matter what type of code, it could be text, diagram, data structure etc., as everything is quickly becoming a code).

The most controversial in my opinion is the role of the typist. This generally is a less technical person who types the code being suggested and which is automatically reviewed by the team members. There is no way someone can dominate the coding process, as there are always discrepancies in that team member’s skills and velocity, so no one will be left behind, let’s put it that way. Everyone is up to date with the code base and is able to contribute in real time.

Real time? Some ideas require thinking them through, sleeping on them, or taking a walk, thus suspending things and resuming them later. Real time is not the best idea for everything. Again, it helps with focus and engagement, but there are things and thought processes that require different asynchronous modes.

And, by the way, who wants to be (just) a typist? I don’t see any hands raised.

Regular intervals

Agile is nothing else but a bunch of time boxes and so is remote mob programming. Daily sessions are divided into smaller equal atoms in which the code is discussed, written and reviewed. So there’s a constant predictable heart-bit. It resembles Pomodoro and similar time boxing techniques that organize daily work.

There are strong pros to this, but also there are cons. For instance, different tasks may require different volumes of attention. Sometimes, a longer task can be deteriorated by the breaks which will seem artificial and distracting.  And then, a smaller task can create some “void” while the team is waiting for the interval to end in order to move on to another task.

Group decisions

Decisions are made by the team in real time, with consensus as the expected option.  Everybody participates in the decision making and has an equal amount of information available. Seems fair, but it is almost too good to be true, isn’t it?

There are always stronger personalities in a team and the more shy people will likely remain silent or vote for the implicit leader, as they want to be left in peace and do not want to stir up any controversy or conflict.

There’s also the case of someone who comes up with rejected ideas more often than others, and the other members of the group will either automatically downvote their ideas or agree to something just to ease their frustrations.

Sharing knowledge

This is a great benefit of remote mob programming, as everyone is equally informed and can ask questions and get answers online . . . immediately.

It sounds great once the scope is limited to a single team, but from a larger organization’s standpoint, it means there will be close to no documentation nor real knowledge flow to anyone outside the small compact team.

So, in this case, what is beneficial for a small team may, and almost certainly, will create issues when this team is part of a larger organization that is working together.

Trust

When people are not communicating with each other they often assume the worst, and thus create conspiracy theories and assumptions. In the case of remote mob programming, because of its transparency, along with the constant communication and involvement of all the team members, trust is much easier to build and maintain.

No one can accuse anyone of not doing their job, not sharing information, or not helping each other to achieve the best results. However, again, in the larger context, the small team may become a little fortress, like a silo which will reject any external ideas and roadmaps, and it may become “us against the world”.

Green benefits

Working fully remotely is definitely reducing the CO2 footprint of commuting to work every day. There are other things developers can do to help the environment, embarking on the so-called Green Development.: This time it’s a clear benefit, but it’s more typical for remote work in general than for remote mob programming, in particular.

Work-life balance

Not having to commute to and from work, and not being distracted by other team members outside working hours has a great impact on the quality of life and the ability to spend quality time with family and friends. Quality time means time without work related notifications, urgent questions from coworkers, etc.

The benefits of working within remote mob programming in regards to work-life balance are hard to deny.

Summary

The creators of the remote mob programming idea have presented a complete vision with a set of rules that enables small teams to work efficiently in a completely remote environment.

As always in IT, despite the binary nature of modern computing, it’s not that simple and not without its flaws. There are different business contexts, different people and different projects. There’s no single solution that fits all.

I believe that many of the techniques presented here can be applied to other methodologies while some are rejected, depending on the context and needs. I highly recommend at least giving it a thought.

It’s great to see the responses, also from a work organization point of view, to the new challenges of the pandemic and (hopefully) post-pandemic era of our civilization.