Mob programming

Mob programming was first suggested as a software development practice by Woody Zuill in 2011. It sees the whole team working together, "all the brilliant minds working on the same thing, at the same time, in the same space, and on the same computer".

Mob programming is basically an extreme form of [pair programming]. Mob programming emphasized the [Agile Manifesto] principle of "individuals and interactions over processes and tools". In its implementation of this principle, mob programming is arguably even more extreme than the [Extreme Programming] approach.

In his conference talks, Zuill’s explains that the agile movement was an attempt to break down the silos of work, in which different people work on different parts of the same problem at different times (in different phases of the development lifecycle of each change). The motivation behind the mob programming approach was to bring together all the different skills and expertise involved in software development, not only programmers but also architects and testers and people representing the users (eg. product managers or product owners), and have them all working together on one problem at a time, seeing through the delivery of each incremental changes through its complete development lifecycle before moving to the next increment.

Zuill developed the mob programming practice through experimentation while working on a project for a company called Hunter Industries in San Marcos, California. After experimenting with different ways of working, Zuill’s team settled on a practice where they were able to turn around whole stories, from the beginning to the very end of their whole lifecycle, within an hour or two.

Originally, Zuill’s teams literally sat around the same computer. But with modern screen sharing and video conferencing technology, mob programming can be implemented by remote teams, too. On-site mobbing benefits from spacious but private spaces, and very large monitors (80" 4k, or thereabouts).

Different teams may implement mob programming in different ways, and use different tools to support the process. Teams should continuously experiment with changes to their ways of working, until they settle on a process that works consistently well for them. But the general approach of mob programming involves the following elements:

A driver works at the keyboard. In the mob programming model, the driver is solely responsible for the production of code – for the typing of clean code. The driver does not have to think about other things, such as the design or testing of the code.
Other members of the team – not necessarily the whole team – are navigators. These people think about the solution and its design, and they instruct the driver about what to type.
The rest of the team are observers. Not everyone may be able to contribute to discussions all of the time (for example they may be newly onboarded and lack the context or domain knowledge to do so). Their role is to learn by watching the rest of the team do the work.
Team members rotate through these roles. In particular, the person doing the driving should change over regularly (because this work requires the most concentration). The cadence of the rotation may change depending on the task at hand, but changeover could be as short as every 10 to 15 minutes, and should not be any longer than the duration of a task (ie. the current driver must have a break once a task is complete).
Product managers should also spend at least some time each day with the delivery team.

This way of working was inspired by strong-style pairing, which was conceived by Llewellyn Falco. Strong pair programming can be summarized by its golden rule that, for an idea to go from your head into the computer, it must pass through someone else’s hands.

Zuill says that mob teams should get good at retrospectives, and these should be conducted regularly – ideally at the end of every day. The idea is that ways of working should continuously evolve to better fit the problem at hand, and to respond to changing environmental conditions such as new team members. Ideas should be implemented as experiments, which the team can try the next day and reflect on at the end of that day. Good ideas should be maintained and improved upon further. Bad ideas should be discarded quickly.

To implement mob programming fully, therefore, teams require complete autonomy over their ways of working. "The people doing the work can best determine how to do that work."

Zuill also argues that teams should have dedicated learning time, and they should do this together, also. He observes that, when a team develops a good dynamic for learning together, those dynamics tend to spill over into their working mode, too. Positive collaboration emerges out of low-pressure environments, which is provided by the learning time.