Why you should start mobbing

In software development, collaboration and knowledge sharing are crucial for creating high-quality software and building a cohesive team. In this blog post, I'll explain what mob programming is, how we implemented it in our team, and the pros and cons we discovered.

I want to explicitly say that a lot of it is opinionated and mainly based on my own personal experience.

What is mob programming?

To start off, I want to answer this question with what mobbing (also called ensemble programming) means to me.

For me, mob programming is a practice that involves a group of developers working together on a single task or project. The idea behind this practice is to bring together the collective knowledge, skills, and experience of the team to achieve a common goal and level.

During mob programming, the team members work together in a collaborative and supportive environment. One person serves as the "driver", who is responsible for writing the code, while the other team members contribute by reviewing and providing feedback, mostly called “navigators”.

The team members rotate being the driver or navigator(s), and the process continues until the task is completed.

The main benefit of mob programming is that it promotes collaboration and communication among team members, leading to better results in less time. It also helps to distribute knowledge and expertise across the team, making it easier to resolve issues and prevent mistakes. Additionally, it can be an effective way to onboard new team members or bring everyone up to speed on a project.

However, there are also some potential downsides to mob programming. It can be challenging to maintain focus and engagement among team members, particularly for those who may not be as interested in or passionate about the task at hand. There may also be issues with power dynamics, as some team members may feel hesitant to speak up or offer their opinions in the presence of more dominant personalities.

Despite these potential drawbacks, I have found mob programming to be a valuable practice for improving collaboration and productivity. In this blog post, I will explore the benefits and challenges of mob programming in more detail, and offer some practical tips for teams looking to implement this approach.

How it started...

Three years ago, our team consisted of six developers. Most of the time we were split into two groups to focus on different tasks. The team configuration varied between two and four developers per team. We aimed to avoid any individual developers working on a task alone, although this was not always feasible given the varied workload of a development team. Our workload typically consisted of maintenance, bug-fixing, and support for other teams. Aside from feature development.

Through our experiences, we learned that certain tasks were better suited for collaborative work, or "mobbing", as it facilitated knowledge sharing among team members. We found it beneficial to begin each task in a mob, and when necessary, split into smaller groups to work on two tasks asynchronously. Even seemingly easy or tedious tasks were not exempt from mobbing, as we recognized that the process of working together ultimately resulted in much better outcomes than individual work.

To promote (domain) knowledge sharing and ensure that all team members were exposed to a variety of tasks, we rotated developers between tasks whenever possible. Ultimately, by prioritizing collaboration and knowledge sharing, we were able to achieve better outcomes and a more cohesive team.

How it's going...

Over the past two years, a lot has changed within our team. We've had two different product owners and a new scrum master, and the team of developers has undergone a lot of changes as well. Some developers have left, while others have come on board, bringing new ideas and perspectives to the team. However, with these changes, some of the team chemistry that had existed before has been lost. In order for a very collaborative to be successful, the members need to be on the same page or be able to reach consensus when in disagreement. The new team setup has led to more disagreements and longer discussions, resulting in less productivity. Whereas before we were able to build multiple solutions to find the best one, we now just build a solution without a real consensus.

Another major change that has occurred in the past two years is the COVID pandemic. We used to work one day from home every week, but now we only have one office day per week, and the rest of the time we work remotely.

While remote working has its benefits, I've found that remote meetings can have downsides. In a remote environment, group conversations often result in one person speaking at a time, and side conversations are not able to happen. These side conversations can often lead to better outcomes for the general discussion.

I would say we are still a collaborative team, working together on the same tasks. But, sadly, we’re not really mobbing anymore. Often times someone takes the keyboard for hours and hours and the other persons in the call are just there as rubber ducks for the ‘driver’.

Still, I do believe in the power of mobbing and I still think that what we are doing right now is still better than everyone working on their own and making pull requests and doing code reviews.

What makes mob programming successful?

I do think there are a few things you should do when you are mob programming:

Limit your rotation times

The time between being the driver of a navigator shouldn't be too long. This keeps everyone in the mob engaged and give you the opportunity to switch between roles often enough. I’ve experienced that the rotation time should be somewhere around 5 to 30 minutes.

We’ve experienced with shorter and longer rotation times aswel, but sometimes switching roles takes some time, which results in you being in a certain role for a very short time.

Longer than 30 minutes is not recommended because people tend to zone out a lot more.

In my experience, the optimal rotation time for mob programming is on the lower side of this and I would say it’s 10 minutes. This grants you enough time in your role and has some buffer for switching between roles.

Build more, discuss easier.

Often times, there are multiple technical ways to reach a certain goal or task. In a mob there are different people, resulting in different skill sets and opinions. To see if one solution is better than the other suggested solutions, I would recommend you build them all as a mob. It's easier to see what's better when there's code in front of you and it also makes the implementation details visual. This way, the discussion can be more in dept and this will lead to an implemented solution that is carried by the whole team.

Take breaks

When you rotate a lot, sometimes it feels like you're not programming a lot of consistent hours. Though, I've experienced that our mob sessions tend to take a lot longer than when you are programming on your own. Breaks are very necessary to keep focus and energy in the mob, which is very important. Plan your breaks with tools, like I suggest later in this article, so you don't end up being in a very long session.

Limit the size of the mob

We've tried multiple setups. With the whole team (6 people) and split up setups. I think the ideal setup to keep everyone engaged is a mobbing group of around 3-5 persons. This will make everyone inside the mob feel engaged.

Tooling

Pop or Around for screen sharing. Good quality is necessary in a remote environment for the others to see what the driver is writing. Pop also has the ability to take over the screen which can be useful sometimes. They both have a pencil which allows the users to draw on the screen, which can be useful for designing or clarifying things out.

mob.sh makes the rotation process seamlessly. It creates mob branch when the command mob start is entered. The driver can use mob next when his session is over, this commits and pushes his changes as WIP to the created branch. When the session is over, mob done can be used to squash the commits and remove the remote branch created. This has been very helpful to us as we're mostly doing trunk based development.

Mobster has an intuitive UI to set up your mob session and notifies you when to rotate.

Small retrospectives after each session will make you do better in the next session, and isn't that what we all want?

Conclusion

The key takeaways for me with mobbing is to get as little interruption and to maintain focus as much as possible. This something that has to be achieved by the whole team, not only the developers. Clear sprint goals and good refinements can lead to a better performing team. Tools, like described before, can prevent interruption inside of the mobbing process. Mobbing, as well as working in a team in general, required good communication skills. These skill differ on personalities and even on seniority. Mobbing is a very good practice to become better at communicating with other people.

And the last conclusion, just do it, it's awesome!