The Power of Mob-Programming: Effective Development through Collaboration

Collaboration and teamwork are essential in any software development project. However, while effective teamwork plays such a crucial role, the traditional software development approaches can feel rather uncollaborative and distant. After spending 6-months as part of a remote Mob-Programming team I’ve learned that collaborating on large software projects can be easy, effective but also fun and rewarding. In this blog, I aim to share my experience with Mob-Programming, how it solves some of the common challenges teams face and talk about the lessons our team has learned along the way. 

What is Mob-Programming?

Mob-Programming is a software development approach where a group or “mob” of developers comes together to collaboratively solve a software-related problem. While many teams might be familiar with the practice of pair-programming, where two developers collaborate on a single problem, mob-programming takes collaboration one step further by having 3 or more people work on a shared objective. Mob-programming was first put into the mainstream through developer and agile guide Woody Zuill, who held a series of influential talks about mob-programming and its benefits starting in 2014. 

Zuill describes the basic premise of mob-programming as:  

“All the brilliant people working on the same thing, at the same time, in the same place and at the same computer.” 

How it works?

1. The Roles

Similar to pair-programming the team is split into the role the typist, the person writing the code, and the navigators, also referred to as the mob. In this setup, the navigators brainstorm ideas and discuss potential solutions. Meanwhile, the driver’s responsibility lies in listing to the mobs’ discussions and translating their proposals into code. This approach requires precise communication, and navigators must ensure that they share their ideas at a speed and level of abstraction that the driver can follow.  

2. Mob Rotations

After a certain period of time, the designated driver relinquishes their role and joins the mob, while one of the navigators takes over as the new driver. The Rotating of roles is an essential part of the mob-programming workflow and is typically done after a set amount of time and until all team members have had their turn as driver, at which point the rotation starts over again. Having everyone take up the role of driver ensures that engagement among all mob-member stays high, as everyone will be tasked with coding up the solution at some point. 

Benefits of Mob-Programming

Through my time working in a mob-programming team I have experienced firsthand the incredible benefits this collaborative approach offers across multiple dimensions. Let’s explore some of these advantages and the secrets behind its success! 

1. Code Quality & Effectiveness

Continuous Workflow

Mob programming offers the distinct advantage a seamless workflow. With multiple team members involved in the coding process, the likelihood of work interruptions or delays due to individual absences decreases. If a team member is unavailable, others can quickly step in to maintain the momentum. Overall, the uninterrupted flow of work has contributed to faster development cycles, without having to worry about pesky handovers. Additionally, this has had a positive effect on the generally atmosphere and culture within our team. Given that a tasks completion does not rely on a single person’s presence or absence, our team has experienced a more relaxed approach towards taking time off for personal appointments, vacation, or sickness. 

Continuous Code Reviews 

In traditional development workflows, code reviews are a time-consuming process that occurs after the implementation is complete. Meanwhile, in mob programming, code reviews occur naturally during the collaboration process. As the team works together on the codebase, continuous peer review takes place in real-time. This eliminates the need for traditional code reviews, as the code is reviewed as it is written.  

While some might voice concerns about code quality, our experience has proven otherwise. Although we no longer rely on code reviews, our team regularly engages in refactoring sessions. During these sessions, we review code, discuss potential improvements, and implement them to ensure high-quality code. 

High Truck Factor 

The term “truck factor” describes the number of team members that must be (metaphorically) struck by a truck before a project experiences a major setback. Since our team shares knowledge while working together on a daily basis, our high truck factor is extremely high. As a result, our project is less susceptible to unforeseen events and is guaranteed to continue even in the event that one of our team members is absent or unable to continue working on the project. 

2. Communication

Decreased Communication Overhead 

By working together in real-time, the need for separate communication channels like email, chat, or meetings has significantly decreased. The direct and immediate nature of communication within the mob eliminates the need for lengthy explanations or clarifications, reducing the number of confusions and misunderstandings that often arise because of asynchronous communication. 

Continuous Learning 

Joining the mob, one of the immediate advantages I experienced was the dynamic learning environment. Collaborating with colleagues on various tasks allows us to share expertise, insights, and ideas. This has expanded our understanding of the codebase, programming techniques and has helped us become more well-rounded developers over time.  

Furthermore, the collaboration has helped us deal with the complexities of the domain we work in. On our journey from laymen to domain experts, working together forces us to constantly align our mental models and interpretations of the business logic. These continuous discussions clear up misconceptions about processes or terminology, thereby refining our domain knowledge and preemptively clear up misunderstandings before they evolve into more significant problems. 

Easier Decision Making 

During a coding session, it is quite common to encounter a variety of decisions. Typically, these decisions are technical in nature and arise once the business logic is clear. One might ponder:  

• should this be part of service A, or should I create a new service? 

• Should I create a new method or refactor an existing one? 

Often multiple solutions exist, but choosing the right solution, which is the most efficient, intuitive or just consistent with the code base is hard. Through collaboration decision making becomes easier and approachable. When faced with decisions, team members can immediately discuss possible solutions. By involving multiple points of view, the team can find a better solution faster while minimizing the risk of making costly mistakes or overlooking critical aspects of the code. Over time this has helped us develop a concise and uniform code style as a team, improving the readability and consistency of our code base. 

3. Team

Social Connection (when remote) 

The social connection established during these collaborative sessions helps strengthen working relationships, even when team members are physically separated. Overall, the sense of connection and teamwork has contributed to a positive team culture and has significantly diminished the sense of isolation that is often associated with remote work. 

Easy Onboarding 

New team members have been able to jump right into the mob sessions instead of focusing on independent study or separate training sessions. By actively participating and working with more experienced colleagues, new team members have been able to quickly grasp the project’s context, codebase structure, and working norms within the team. This hands-on learning approach has made the onboarding process efficient, enjoyable and has decreased some of the frustrations associated with joining a new team.  

Remote Mob-Programming 

During my research, I was surprised to find a prevalent belief that mob programming is ineffective in remote settings. Many sources suggest that it is best suited for on-site work, with all team members physically present. Despite these claims, our remote mob work has proven highly effective and has reshaped my perception of remote work. In the follwing section I would like to share the stand out aspects of our remote mob. 

No hard Driver-Navigator Pattern 

In Mob-programming the driver/navigator pattern involves the navigator’s proposing solutions which the driver translates into code. For us as a team it quickly became aparent that we dont want to strictly adhere to this pattern. 

We have found it more beneficial for the driver participate in discussions and share their ideas while writing the code. This approach avoids the feeling of being “remote controlled” by others, which can often feel frustrating, especially in remote settings. 

With this approach, effective communication has gained increasing relevance. As the driver is able to formulate the solution as he is coding, it is crucial for him to clearly articulate his train of thought, ensuring that all team members feel engaged throughout the mob-session. As such it is important for the the team to establish a habit of thinking out loud and working at a suitable easy to follow pace.  

The Virtual Office 

Woody Zuill’s vision of everybody working in the same place at the same computer was made before remote work became common practice. While working on the same computer is impossible in a remote environment, it is possible for the team to work in the same (virtual) place. Within our team we use a virtual office as a common space for us to meet and collaborate. 

The virtual office is always open, and its participants can be seen from the outside. The use of a virtual common space cuts down the communication overhead organizing group calls. Additionally, it serves as a space that all team members naturally gravitate towards. When we are not in a meeting or busy with something else, everyone meets in the virtual office. 

Finding the right rotation

Choosing the optimal rotation times in mob programming is not a one-size-fits-all approach. Our team has experimented with rotation times of 5, 10, and 15 minutes to find what works best for ous in various situations. Through this we have been able to identify 2 key aspects to consider: 

1. Mob Size:

The size of the mob plays a crucial role in determining the ideal rotation time. In larger groups, quicker rotations tend to be more effective as they help maintain focus and engagement. With more people involved, shorter rotations ensure that everyone gets an opportunity to actively contribute as the driver. 

2. Task Complexity:

The nature of the task being tackled also influences rotation times. For simpler tasks that require less discussion, shorter rotations of 5 or 10 minutes may be sufficient. Generaly we have found that shorter rotations increase the pace at which the team works. However, for more complex tasks that demand in-depth discussions, longer rotations of 15 minutes or more slow down the pace, giving everyone more time to discuss their thoughts. 

Things to consider 

Team Size 

When implementing mob-programming, team size is an important consideration. As a team composed of 9 developers, we have had frequent discussions on the ideal number of participants and have experimented with mob sizes ranging from 3 – 9 people in one session as well as multiple smaller mobs working in parallel. Over time we have found our sweet spot at around 4 – 5 people. While working in very large mobs is feasible, our experiences have shown that the added benefits of collaboration begin to drop off for groups exceeding 5-6 people. Beyond this, discussions tend to become chaotic, resulting in decreasing contributions from parts of the team. Moreover, waiting times between rotations can become rather long. In a mob of 6 people rotating every 10 minutes each person must wait 50 minutes between their turn as the driver, leading to reduced engagement. 

So, is mob-programming only feasible for small teams of up to 5 people? As hinted to earlier, we have found our solution by primarily functioning as two separate mobs. Each mob works on separate tasks, which don’t intersect. Large mobs have subsequently been reserved for special tasks, such as the implementation of foundational features, which benefit the entire team and ensure that all team members have a solid understanding of our applications core mechanisms. Nonetheless, by splitting into separate mobs we have managed to retain mob-programming as our primary mode of work, while maintaining small and efficient sessions.  

Busyness vs. Effectiveness 

Before concluding, I would like to address the question of efficiency. Without a doubt the number one response I receive when explaining mob-programming tends to go along the lines of “that can’t be efficient”. While people generally see the benefits of collaboration and the sharing of knowledge, they struggle to see mob-programming a viable alternative to or improvement over the traditional mode of work. And of course, why would they not? Surely, 5 people working on one task won’t be as effective as 5 people working on separate tasks, right? This train of thought seems intuitive, however, it wrongfully equates busyness with effectiveness. Simply said most believe that a higher utilization of resources will lead to more progress. While this assumption might hold true for simple and repetitive task, often seen in manual labor, it is not to case for knowledge work such as software engineering.  

A single developer working on a problem is more likely to encounter problems, will have to submit his code for reviews and is more likely to overlook an important detail. This decreases velocity, requires loop backs and thus leads to waiting times all while enforcing siloed knowledge. Therefore, it is important to not place to much emphasis on achieving a high resource efficiency, but to focus on achieving a high flow efficiency, the time spent in value-added activities. When thinking in terms of continuous flow, mob-programming becomes a much more sensible approach. Less time spent waiting, less time getting stuck, increased knowledge transfer and more time actively adding value.  

Not for Everyone 

Too wrap up this article, it’s crucial to name some of the limitations of mob-programming and acknowledge that it is not a universal solution. 

Firstly, not all tasks are suitable for mob programming. Through our experiences, we have found that tasks which are unstructured or have a high degree of complexity and require deep focus don’t align well with constant collaboration. Mob rotations in particular, can feel unnatural at times, especially when working on tasks that require a lot of trial and error. 

Moreover, it’s essential to recognize that mob programming isn’t for everyone. Some individuals may find it overwhelming or uncomfortable, and some just don’t like the dynamic of constantly working in a group. No matter what the reason, it’s important to respect individual preferences. 

As such, we have chosen a pragmatic stance towards mob-programming and avoid rigid dogma. When a task can profit from collaboration, which most can, we work as a mob. If the task requires a lot of tinkering, we switch to individual work or pairing. Occasionally, a team member might opt to go off on their own because they have the desire to delve deeply into a problem or simply because they need a breather from the group, and that is perfectly fine as well. In conclusion it is important to remember that mob-programming is a tool and as such is a means to an end, not the other way around. 

Get in touch with us

---