Mob programming revisited
Tags: mobprogramming, pairprogramming, productivity, teamwork
Published: 2021-05-02 19:58:44

---
title: Mob programming revisited
published: true
description: 
tags: #mobprogramming #pairprogramming #productivity #teamwork
cover_image: https://team-coder.com/images/posts/2015-10-20-mob-programming/title-image.jpg
---

At the beginning of the year, I wrote a post about the [first mob programming session](https://dev.to/albertowar/lessons-learnt-from-my-first-mob-programming-session-5hjf) that I organized with my team.

The results were promising, yet we never had a chance to use it in real world examples.

That changed last week.

# Background story
For the last 6 months, my team has worked on a project that had a very optimistic deadline from day one.

We had to take many shortcuts in order to make it and one of these shortcuts was **siloing**. 

In order to ship the required features on time, we distributed the ownership of the different parts of the application across the team and worked on them **separately**.

![Isolated](https://media.giphy.com/media/na5eo4HbIVO7K/giphy.gif)

# 💩 Shit storm 
Fast forward to a week ago, we were in a tricky situation. We had:
* One component in our application that **only 1 developer** knew how it worked.
* A bunch of **new features** lined up in our roadmap that we committed to deliver by the **end of May**.
* The need to perform a **significant refactor** on that component to prepare for those features.
* The main SME was off **sick**.

![Chaos](https://media.giphy.com/media/zPOErRpLtHWbm/giphy.gif)

# Mob programming to the rescue!
The situation was less of ideal. This was the result of team debt accumulated over time, and it was time to pay it off.

I brought up the idea of using mob programming for the refactoring work. In my mind, this would improve the [bus factor](https://en.wikipedia.org/wiki/Bus_factor) since:
- All engineers would work **together** on the same task at the same time.
- Refactoring forces you to **understand** the code **before changing** it to ensure it still behaves in the same way after the changes.

Gladly management bought onto the idea and we spent a full week working on it.

# Retrospective
## 💻 Preparation 
In order to save valuable time, make sure you share instructions on **how to set up the development environment** prior to the session.

I forgot to do it, therefore we had to repeat the same steps every time we rotated to a new driver 🤦‍♂️.

## ➡️ One direction
It is important that all navigators follow the same **train of thought**. 

![Together](https://media.giphy.com/media/iRzlyqHL8hJTy/giphy.gif)

It's hard follow the conversation when different people are trying to tackle different parts of the problem, specially if you are the driver.

## ⚖️ Facilitation is key
I found it really hard to contribute to the session and facilitate it at the same time. However, having a facilitator is critical to ensure you make the most of your time.

![Meditation](https://media.giphy.com/media/zhRA0okWxTGiu78uSk/giphy.gif)

The facilitator will be in charge of the following.

### 🎯 1. Defining a goal for the session
At the beginning of the session, the facilitator should **state** what you want to **achieve** by the end of the **day**.

This will help to prioritize the areas of focus and when it is OK to move on.

### ☮️ 2. Creating a safe environment
As a facilitator, you need to ensure everyone in the room has an **opportunity to share their ideas**. 

In every team, there will be people with stronger voices in the room. As a facilitator, you can intervene with prompts like:

> *Hey X (person who has been silent), what are your thoughts on Y (the problem at hand)?*

> *Excuse me X (person who's speaking over somebody else), I would like to hear what Y has to say, I think they have a valid point.*

Occasionally, people may get hung up on some details, react sarcastically, make negative remarks about the code that's been written or the driver.

This can be quite **distracting** and some people might **not feel safe** sharing their ideas in such an environment. 

If you, as the facilitator, observe this is happening, you should also intercede in a respectful way:

> *Apologies for interrupting, I would like to kindly ask that we leave sarcasm or non-constructive feedback outside of this session. It is distracting some members of the mob and we all want to get the most out of this session.*

Then, to avoid an awkward silence, you can quickly redirect the attention back to code:

> *So, Y (navigator), how do you think we should solve X (problem at hand)?*

### 🛣️ 3. Staying on the right track
Although one of the main values of mob programming is the discussion that takes place while multiple people are working on the same piece of code, it is also important to ensure the mob doesn't get **stuck** with things that are not relevant.

As developers, we sometimes get hung up with details such as variable names, libraries to use, etc.

If this happens, the facilitator should intervene and bring the session back on track. Here are some ways you could do it:
> *Hey folks! I think you all have valid points. Also, we have been discussing this point for a while now, can we compromise on one solution and move on to the next problem?*

> *It seems this topic needs more discussion. Should we keep track of this item and come back to it at a separate meeting?*

### 📝 4. Track decisions
During the session, the mob will make **decision** that impacts the feature or product that's been developed. 

This could be anything from the programming language to use, structure of the code, picking a library to solve a problem, the architecture of the system ...

When that happens, the facilitator should make sure that such a **decision** and the reason behind it are **tracked**. 

For this, you could use an [architectural decision record](https://adr.github.io/).

### ℹ️ 5. Progress updates
Mob programming is still a fairly new way to solve problems and many people are still unfamiliar with its value.

An easy way to keep everyone informed is to send a **recap** at the end of the mail. 

Here, you can share:
* What the mob **accomplished** during the session.
* What is still left **to do**.
* Any **questions or potential blockers** that might have popped up during the session and need to be **addressed separately**.

# Conclusion
![Victory](https://haste.net/wp-content/uploads/2017/08/haste-league-of-legends-victory.png)

Having a practical example where we could apply this way of solving problems was quite illustrative.

Not only we **achieved** our goal of **sharing knowledge** across other engineers, but we also **learnt** more about mob programming and what **type of problems** are best suited for it.

With that said, there are still some details that aren't quite clear to us yet. 
* Should the driver also be part of the discussion? 
* How often should we rotate?
* Should we involve people from other disciplines?
* What's the optimal number of engineers?

# Next steps
To continue discovering more about mob programming, I plan to:
1. 👀 Continue looking for **more opportunities** to put it into practice at work.
2. 📖 **Read** [The Mob Programming Guidebook](https://www.mobprogrammingguidebook.com/images/mobprogrammingguidebook.pdf) and [Remote Mob Programming](https://www.amazon.com/dp/B081F5FVTZ) to see if I can find answers for the questions above.