At the beginning of the year, I wrote a post about the first mob programming session 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.

💩 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.

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 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.

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.

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.

ℹ️ 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

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 and Remote Mob Programming to see if I can find answers for the questions above.