Mob programming benefits for Agile development teams

What is mob programming?

Woody Zuill, who has contributed to the idea and popularized it, describes mob programming as "a development practice where the whole team works on the same thing, at the same time, in the same space, and on the same computer." Zuill noted that this approach involves the whole team in all the aspects of software development, including design; coding; test; and working with customers, users and other stakeholders.

In an in-person mob programming scenario, the team is in one room, with the code projected on a screen or otherwise visible to all. As remote software development has grown in popularity, screensharing tools make remote mob programming possible. Everyone actively contributes to the work.

The most common approach to mobbing has two specific roles: the driver and the navigator. The driver role is a noncritical follower of instructions. The navigator tells the driver what to type. The mob, a third role encompassing everyone else on the team, provides advice to the navigator, spots bugs, and thinks at the higher and lower levels about code construction. Team members rotate roles every 15 minutes or so, and the entire process is usually scheduled as an hourlong session.

Rotating prevents certain problems, such as one person dominating the session by programming while everyone else watches. Smaller teams -- for instance, groups of three or four -- might find these rules overly rigid and adapt accordingly.

Benefits of mob programming

Teams are compilations of diverse skill sets. The distribution of skill on a development team does not always align with a role hierarchy. For example, a junior programmer might lack experience but know keyboard shortcuts that a senior colleague does not. With varying capabilities from one person to the next, teamwork can lead to one programmer producing clean code only to have it ruined by another person when they do maintenance on that code. The same is true for unit tests.

Pair programming doesn't solve this potential issue, as paired team members could have the same weak spots. The pairs do not pick up new techniques as fast as when the whole team is involved, and they still have skill gaps. Plus, going from primarily working alone to working with a partner for most of the week is a jarring experience that could lead to resistance.

Instead, mob programming enables the team to build off the greatest experience in the room, without requiring constant teamwork throughout the week. The best SQL programmer, for example, gives advice on how to construct SQL. Everyone on the team benefits from learning new techniques and practices from their colleagues. In a way, mob programming is similar to a learning exercise but one that results in quality production code.

Mob programming can also produce a subtle benefit for both supervisors and workers. Supervisors who are frustrated that workers are not following a new required practice can reinforce the requirement during the hourlong session. At the same time, workers frustrated by a practice can demonstrate to their first-line supervisor what the issue is with the approach.

If the entire team engages during meetings, mob programming produces working software that is great quality and structure while building shared knowledge among the team. It is also a productive way to disrupt programmers' routines, breaking up the workday as a part-time activity while providing working code.

How to implement mob programming

Any team can start mob programming by pulling a new feature into development and working together on it.

First, pick the most important story on the board. In e-commerce, for example, choose a story that touches checkout. For a traditional productivity software, pick the piece of the system most likely to change. Having the entire team work on this feature alleviates worries about the author taking vacation or leaving the company because the whole team gains knowledge on the feature.

Next, schedule a single one-hour meeting for the entire team -- ideally, three to nine people. A colocated team should reserve a room with a projector or otherwise shared screen and classroom or conference room setup; a remote team needs both meeting software and a multiuser workflow.

One common technique for collaboration is to use version control for the handoff. At the end of a 15-minute period, the person who is the driver commits the work to version control and hands the meeting host role to the next driver. Given 15-minute rotations and a bit of time for the switch, it might make sense to schedule 75 minutes for each "hourlong" meeting.

To be successful, the process often requires at least one champion within the company: someone with team communication and observation skills to notice exactly who is -- and who isn't -- fully participating. This is especially true for remote mobs.

Mob programming can become a daily event in the right conditions. While daily meetings can be challenging, most people can handle one hour of a new workflow. This arrangement asks much less of people than continuous pair programming, which can occur for the majority of the workday. The team can work together as a mob for one hour and then go back to their other tasks. In the face of resistance, explain that it's only one hour at a time.

Include everyone on the team who can write code. Graphic designers, technical writers and Scrum Masters might not have an interest. The main issue is if the team is willing to slow down and explain. If not, those groups may find their time best spent elsewhere. But forcing the team to explain their thought processes reveals gaps and creates better ideas. It is better to slow down and explain than to leave some people behind.

Making mobbing work

Because mobbing is just programming, it fits the workflow of software development. Programmers write code and send it into version control. That said, teams likely have more work to do at the end of a 75-minute session. The feature the team has been working on may not be complete. They could stick it into a branch and pick it up tomorrow or hand it to a programmer to finish today. It may be best for the last navigator to take over the story and finish it.

To adopt mob programming, what's needed most is a genuine willingness to try it, plus discipline by team members to participate actively when not in the driver or navigator roles. This is probably best suited to truly collaborative teams, where lines of responsibility are intentionally blurry and individuals' contributions are welcomed. That means team members aren't overly possessive of specific parts of the codebase.

Then again, teams that have strong code ownership could greatly benefit from mobbing, as every feature defined by the mob has joint ownership. The core requirement is a willingness to learn and try new things.

Mob programming isn't the answer for every project. When Agile teams incorporate mob programming, they forego other programming techniques. If the team doesn't fully support this new method, there's a high probability of a decrease in the overall amount of code written. The team is also more likely to lose interest in the project if they aren't fully on board with mob programming.

It's an intense process that requires everyone on the same page, but when implemented correctly, mob programming can serve as a beneficial practice for an Agile project.