Remote Mob Programming

Remote Mob Programming

Remote Mob Programming combines two ways of working: Mob Programming and working as a distributed team.

The basic idea is the same, the techniques differ a bit.

“All the brilliant minds working together on the same thing, at the same time, in the same space and at the same computer

Woody Zuill

The concept is the same: we optimize for the flow of work, rather than the output of the individual.

Benefits of Remote Mob Programming

A part from the benefits of mob programming like writing the best code your team is capable of in real time or reducing meetings, doing it in remote gives additional ones.

One of the big benefits is that is fun. Working remote could be quite lonely and one can feel isolated. Working together with a group, instantly fixed that.

Remote mob programming is a resiliant thing in front of losing an individual people for periods of the session. People can very easily leave for a period (to attend his child or whatever) as the shared knowledge is in the rest of the mob. This gives the freedom to people to drop in&out as they need. It is easy to take breaks in case one feels saturated.

Remote Everybody

To collaborate well in a distributed team, it is essential that everybody works remotely by default. It does not work if part of the team shares a room. This would lead to information asymmetry through communication shortcuts. That typically happens in on-site meetings with a few remote attendees.

Camera Always On

Working face-to-face is powerful because we communicate with the whole body, not just our words. Rolling eyes, yawning, looking pensive, or raising an eyebrow are just a few examples for that.

Activate your cameras all the time!

At the beginning it may feel strange, but after a few days it will become natural. It gives a sense of presence in the team, almost like working in the same room together. It helps to see if someone is away from keyboard, talking to their children, or otherwise distracted.
In a multi-monitor setup, ensure that the camera is at the main screen so that you’re looking at each other. Mute your microphones when going away from the keyboard, leaving the camera on.

Remote Mob Programming Session

A remote mob programming session has same structure than an in-site mob programming session. Set the stage, mob intervals and retrospective.

Once defined the session in the first part (setting the stage), mob intervals start. The Driver shares his primary screen, showing the code, ticket, or wiki the team is working on. It is highly efficient to work with the actual artifact in contrast to having abstract meta discussions.

All the team looks at the same shared screen.

Looking at and working on the same issue forces the team to focus. It is good practice to use fullscreen and disable notifications.

Finished the mob interval, shared screen is switched at the start of the next mob interval.

Rotation

Every mob session has a specific goal (e.g. to implement a feature or fix a bug) and may last several hours. In a mob session, the driver role rotates periodically. Short rotation periods keep everyone concentrated and every opinion in the mix.

Surprisingly, taking your turn as a typist (driver) allows you a mental relaxation. You just wait for instructions.

In the Remote Mob Programming book it is recommended a 10 minutes period for a mob interval, i.e. typis is changed every 10 minutes. Other resources recommend longer periods: 25-45 minutes. The mob should experiment and decide the best period.

Git Handover

With on-site Mob Programming, you just pass on the keyboard to hand over to the next person. This is a challenge for a distributed team.

In order to have a clean master branch, it is recommended to work on a temporary mob-session branch. After each interval, changes are committed to this branch. In this branch, we don’t care about the commit message, if the code compiles, or if the tests are green. A quick handover is essential.

At the end of the mob session, we squash the WIP commits into expressive commits and merge into master.

We created a small command line tool mob to simplify the handover through git.

Remote Mob Programming – At home, but not alone

How To Do It

A mob programming sesssion can address different subjects: coding, testing, deploying, designing, … in all cases, following receipt can be applied:

  1. Pick your team’s most important piece of work
  2. Get on a group call
  3. Decide what you are going to try to achieve in the next period (10-25 minutes)
  4. Start a timer
  5. Someone starts a screen share
  6. Hack!
  7. When the timer goes off, stop!
  8. Take a break, stretch
  9. Go to 3

Team Size

The whole team works and focuses on the same thing. Only one person can talk at the same time. With larger teams, the individual speaking time shrinks, making it harder to stay focused. It is easy to become mentally absent. Also, expect technical issues, such as connectivity problems or interfering noise, to happen more frequently in a larger team. Those issues will block the whole team.

Ideal team size for a remote mob programming session is 3-5.

Regardless of your team size, it is important that every member takes on the typist role every 30 to 45 minutes to stay focused.

Ideal mob is composed by the number of people needed to have all the skills required to work on the selected problem.

Trust

Remote working requires trust. Management has a natural fear of losing control over the team.

Also, there is inherent doubt of a team’s productivity, with all team members working on the same issue at the same time.

Built trut by communicating actively:

Write daily check-ins in team’s chat channel. A check-in is a short recap of stuff that happened or hasn’t worked out as planned. It could be some personal stuff, too. Management also reads this channel and thereby is informed.
Take care to hold to team’s commitments and deliver high quality code in time.

That builds solid trust in the long term.

Remote Challenges

  • Working as a team
  • Keyboard and screen sharing
  • Using drawings and diagrams
  • Maintaining healthy interactions
  • Sharing ideas remotely
  • Remote conversation

Tools And Environment

Regarding the environment, you need a fast internet connection, have powerful computers. You also need high quality audio, having good quality microphones.

Sharing screen and keyboard: “The same computer”. There are several tools that gives you those sharing features, … try things:

Other tools:

  • Whiteboards: Miro, Mural
  • Shared docs: drive, dropbox, …

More info at Effective Home Office.

Tips And Techniques

Create Team work agreement

In order to find team boundaries, write 5 to 10 rules to define how to behave with the other.

Hold short and daily retrospectives

Hold a quick and short retrospective (10-15 minutes) every day at the end of the session. It is a quick way to define how the team feels. Doing at the end of the day helps obtaining real data, real feelings (normally bad feedback minimizes with the pass of time).

Use Strong-style

The person that knows what to do, should not touch the keyboard.

The person with the most to learn (because is new to the code base or to the problem domain) or just joined* does the typing.

Having that spectrum (the person that know what to do as navigator and the person with the most to learn at the keyboard), everybody else is going to be somewhere in between, everybody will be able to follow alone, nothing is going to be too fast or too slow.

*A great way to pick up on the context is to take the keyboard and start typing the teams ideas

Use a timer and be disciplined about breaks / swaps

It is very important to stop. Mob can give 1 or 2 minutes more once timer goes off, just to finish a task.

It is very important to take breaks (specially in remote communications) and get away of the screen.

You can continue with same driver in case everybody is happy.

Have a shared to-do list or mind-map

Team has to know where he is right now and what do you is needed to do.

Use a virtual whiteboard to have a temporary memory location. Where everybody has same memory, avoiding to have everything in someone’s head.

Get a professional microphone

Having a good quality sound is a must.

Use TDD/BDD

Both techniques slice problems into very small ones. They facilitate switching.


References

Leave a Comment

Your email address will not be published. Required fields are marked *