In our industry, it’s often taken for granted that work can be either remote, distributed and asynchronous or collocated and synchronous. At SadaPay we’ve found a nice way to be remote-first, distributed across a large geographical area (UTC+1 to UTC+9) and still work collaboratively in real-time. It’s hard to combine these things, but as both of them provide huge benefits to our team and our business we’ve worked really hard to find a solution. Now we’re excited to share it with you!

‍

Remote Mobbing

As a starting point, it’s important that you’re familiar with mob programming. There are many benefits to mob programming, but I don’t want to make this post about convincing you to try it. For our purposes, the main thing to note is that it allows a collocated team to work on the most important thing with minimum interruption and delay. But what about a remote, distributed team?

The remote part can be solved with technology. Our mobs use mob.sh and screen sharing to switch drivers easily. Because we use mob.sh rather than remote control (we used to use Tuple, which is great when latency is low enough), the driver is working on their local machine to ensure a nice developer experience. SadaPay provides noise cancelling using Krisp and good headsets, so we can communicate easily too.

‍

‍

Distributed Mobbing

‍

But what about the distributed part? If people are in different timezones, how can they mob? Actually, the benefits of mobbing are even greater when your team spans a few time zones!

Earlier we mentioned that mobbing allows us to work on the most important thing with minimum interruption and delay. But what if we want to go faster? We can add people to the mob, but that’s an exercise in diminishing returns. We can work overtime, but that’s harmful and unsustainable.

‍

Distributed teams like ours have an interesting alternative – relay mobbing. Let’s consider an actual team at SadaPay, Cards Squad:

‍

Team Member           Time zone

‍Shoaib                       +1

Aday                          +1

Shayan                      +5

Rong Yu                    +6

‍

Now let’s see how their team’s relay mob changes shape throughout the day, passing the baton between members:

‍

Mob Duration (hours)           Activity    

0                                             Rong Yu starts the mob, continuing work from yesterday based on the detailed update left by Shoaib and Aday    

1                                             Shayan joins the mob, getting a quick briefing from Rong Yu about what she’s done so far    

4                                             Shoaib and Aday join the mob, getting a quick briefing from Rong Yu and Shayan about what they’ve done so far    

9                                             Rong Yu leaves the mob    

10                                           Shayan leaves the mob    

14                                           Shoaib and Aday write a detailed update on their progress since 9 and leave the mob    

‍

In a collocated team, the most important thing would only be in progress for 8 hours each day. In this remote, distributed team, the relay mob keeps the most important thing is in progress for 13 hours each day. We are around 50% faster! Maybe we can go faster still if additional members join the squad in slightly earlier or later timezones. As long as we have enough overlap to ensure smooth transitions as the squad changes shape, the approach is scalable.

This isn’t the only benefit. Compared to pairing, relay mobs are highly resilient. People don’t work continuously all day – they take breaks for lunch, coffee and prayer. They get sick, pick their kids up from school or just go on leave. When pair programming, this can be disruptive. Either people align their breaks, or they work alone and the benefits of synchronous collaboration are lost. But in a relay mob, it’s no big deal. If somebody has to duck out for a moment, the baton can be passed and the mob can keep going. If somebody wants to take some leave, the mob will be OK without them.

Our initial vision was to use pairing and pair rotation, but the relay mob evolved organically and became our default way of working. Teams that switched from a combination of pairing and solo work to relay mobbing saw benefits in knowledge sharing, cycle time and solution quality.

‍

Inside the Mob

Let’s look in more detail at what it’s like to be in a relay mob at SadaPay.

Our approach is outside-in, trunk-based, test-driven development using ping-pong pairing on tight red-green-refactor-commit cycles. That’s a lot to get your head around, so let’s examine the real workflow used by Cards Squad as an example. Their actual day looks like this:

Person           Activity

                    Good morning! 🌞

Shoaib         mob start 🥳

Shoaib         Write a failing test 🔴

Shoaib         mob next ⏭

Aday            Take over screen share 🎥

Aday            mob start 🫂

Aday            Implement to make the test pass 🟢

Aday            Refactor 🚜

Aday            mob done

Aday            git commit ➡️ git pull –rebase ➡️ git push
                    Red-Green-Refactor-Commit cycle complete! 🔴 🟢 🚜 🚀

Aday            mob start 🥳

Aday            Write a failing test 🔴

Aday            mob next ⏭

Shayan        Take over screen share 🎥

Shayan        mob start 🫂
                     Continue mobbing 🔁
‍

Using this technique, Cards Squad is able to focus all their energy on the squad’s most important goal for 13 hours each day. We commit a green build to trunk around every 15 minutes – true continuous integration. We move through multiple codebases together, working full stack. When making changes in each platform, people proficient in that platform provide some extra guidance and the rest of us learn by doing. It’s an approach that optimises for focus, cycle time, learning and solution quality all at once – and it works remotely!