Mob Programming

For those who are not quite familiar with the term, it is a particular way of working that promotes team collaboration.

As a sequence of pair programming, where two people get together to share a coding experience ( both looking at the same code whether it is remotely or not) there is Mob Programming.

Mob programming is a technique where the majority of the team works on the same technical problem or feature, altogether looking at the same big screen. In the beginning, it might sound like a complete waste of resources or overkill, but as soon as you start working this way the more you see the benefits. 

First things first, this particular way of working is not always a good fit. We need to understand the context and the circumstances where this can really shine so that I truly recommend this for tasks or assignments that are not straightforward for any of the developers of the team, and where decisions that will impact the future of the platform need to be made. Otherwise, it can evolve into an unproductive situation and an overhead of capacity. 

It all starts with a task that the devs would like to fix as a team effort, so they get together, similar to a whiteboard session, but with a screen and more hands-on. Before everyone starts shouting different solutions and opinions, a driver needs to be designated. The driver will be the one using the keyboard and the mouse, aka typing the solution and leading the team in the right direction, translating the thoughts of the rest into code. Although it is not mandatory, all the devs should take turns and rotate the driver in order to make this a more balanced experience, every 15 minutes or so, depending on the case.

Once the driver schedule is decided, and with everybody else looking at the same screen the development starts. Anybody can start the conversation or point out different ideas, the focus here is on sharing the experience of the issue and addressing all the problems from different points of view.

Here are some benefits and improvements we have achieved by doing Mob Programming:

• Fewer knowledge transfer sessions, because we were all together for the most difficult decisions
• Helped us understand and get to know the way the rest of the team thinks and how they approach things differently, especially when dealing with really old bugs or technical debt
• Less time-consuming Pull Request, because we spend less time getting the context of what we are reviewing, so the bottleneck was no longer there for us
• Enhanced the team's dynamics, and helped us to find common agreements easily

Of course, there were times where we did not use this, and as it was mentioned before it could not work for all teams, but I encourage you to try it out at least two or three times, and I hope you can start noticing the benefits of it.

To wrap up, I would like to mention that beyond the benefits that were already shared, one of the focuses of this is promoting team collaboration and potentially point to red flags of particular team members' behaviors. In where following this technique develops toxic arguments within the team, people trying to impose solutions rather than sharing, not treating feedback as a gift, among other things social-related that we can think of.