Mob Programming Is Quicker Than You Think

Anything done async requires a resync.

Mob programming is an expansion of the pair programming paradigm where instead of two developers working on the same task, three or more developers are working on the same task. Quite often this includes the entire team working together with one person controlling the workstation.

What are the benefits?

In a 2006 study that evaluated the effectiveness of individuals and groups solving complex problems, it was determined that:

We found that groups of size three, four, and five outperformed the best individuals and attribute this performance to the ability of people to work together to generate and adopt correct responses, reject erroneous responses, and effectively process information.

But what are the reasons for this improved quality and performance? Why are they able to reject erroneous responses and effectively process information simply by being in a group?

First, the cognitive load of development is shared among all of the active participants so that no one or two people are entrusted with designing the implementation. This cognitive diversity leads to better solutions in general since more consideration can be made about possible mistakes and pitfalls of the solution.

Second, knowledge about the solution is easily shared and understood. In fact, understanding of all individuals happens in real-time so no additional documentation needs to be created and read for the team to understand the implementation.

Third, the skills that are required to solve the challenge are available in real-time so that no additional communication is required. No meetings must be set to discuss an impediment, no tickets need to be created to hand off tasks to other individuals, and no management need be involved in communication hand offs.

Fourth, individuals can come and go as necessary to attend to outside duties that might otherwise halt progress on the task. This helps alleviate the stress often associated with the demands of hyper-focused development.

Fifth, team members can research ahead of an impending blocker to the task so that when the time arrives, they can have sufficient knowledge to overcome the blocker quickly.

Sixth, newcomers to the team can easily get involved and begin to contribute to the code base right away since they will be actively involved in it’s development the moment they start.

There are several additional benefits to mob programming that we simply cannot cover in this article, but by now it should be apparent there are many reasons to organize this way.

The Setup

All the members of the team should be in a single room, either physical or virtual. There should be no barriers between them such as cubical walls or monitors so that everyone can see each other. At the front of the room should be a monitor large enough for all individuals to see. An additional whiteboard is also helpful for when conversations enter the theoretical or abstract.

A mob session involves much the same roles of a pair programming session where one individual acts as the driver, another individual acts as the navigator. However, in a mob the rest of the group remain active observers.

The driver controls the computer that is managing the screen at the front of the room. They operate the mouse and keyboard, typing all of the code being suggested by the navigator and move the items around on the screen for everyone to see clearly what is happening. They are effectively focused on the “present” code being written.

The navigator is the primary person in charge of reasoning. They are determining what to do next, what the next problem is to solve, how to solve it, and what additional resources may be needed to solve it. This is where it’s incredibly handy to have the other experts in the room to ask questions or to point out upcoming challenges the navigator may not have anticipated.

Sometimes the role of navigator will shift to one of the active observers should their particular skill set be necessary to advance the solution forward. However, much like with pair programming, it is typical for rotation to occur at controlled intervals. Switching of roles regularly between all individuals in the mob is paramount in order to achieve the best outcomes. As a general rule, the larger the mob, the shorter the rotation interval should be. Long intervals can lead to disengaged participants who are waiting their turn for too long.

Won’t we be slower?

As with pair programming it is sometimes difficult for management to see the benefit in the arrangement of multiple developers working on the same task as this seemingly limits the overall throughput of the group. Instead they want to divide up the tasks among the team and have the team work independently in an asynchronous fashion. This would seem to be the most logical way to get the most work done.

But there’s a catch, anything done async requires a resync.

The time required to bring together all the different independent pieces is often not accounted for or underestimated. Code reviews, adding comments to tickets and reading them, change approval processes, meetings to discuss where each person is at in the development of their piece, dependency blockers when one person is running behind and others need their code done before they can proceed on their own code, etc. These issues are rarely taken into account but actually result in much larger dedications of time.

When consideration is given to the time reduced for things such as communication gaps, meetings, code reviews, less technical debt produced, and documentation, the overall throughput remains about the same.

For example, with a team that performs mob programming there is no need to do daily stand-up meetings since everyone is working on the same task.

There is no need for code reviews since all potential reviewers were involved in the development.

The developers do not need to take the time to comment on a ticket for tracking impediments or progress on that ticket, nor do any developers have to take the time to read those comments.

There is no need for external communication via email, Slack, meetings, or other communication pathways for handoff and questions to other developers on the team.

By eliminating a lot of the communication gaps, meetings, and code quality controls we actually improve the flow of development.

Take a break whenever you want

When working as a mob it is important to keep in mind the mental drain this continuous working environment can have on some individuals. Many folks simply do not like the idea of being stuck in a room with the same people all day. This is an understandable situation and should be accounted for by the team.

As a general rule, the mob must accept that any individual of the team has the autonomy to leave at any time and without question. In fact, mob programming feels much more liberating because of the ability for members to leave any time they feel overwhelmed. In non-mobbing teams, there is no such consideration for timeouts away from the difficulty of work. If an individual on a non-mobbing team is tasked with some work and decides to leave temporarily then the work is halted, and no further progress is made. However, in a mob programming scenario work can continue in their absence giving them relief from the pressure to perform. Mob programming eliminates a lot of emotion and feelings of burnout as a result, despite the counter-intuitiveness.

Conclusion

Mob programming allows for more efficient communication across the team to accomplish the tasks more quickly. There are fewer non-coding-related activities such as meetings, or documentation of progress. There is less strain on any one individual to perform. Time can be taken off from the mob to manage outside responsibilities and yet work will still continue. The quality of the code produced is considerably higher and with fewer uncaught mistakes that lead to time lost later. There are a number of benefits both articulated here and unarticulated. The only real way to know for sure is to TRY IT. If it doesn’t work for you then you can always go back to the way you were doing it. But I can tell you that after working with many teams in large enterprise organizations, not a single one of them has ever wanted to go back.