Mob Programming is a software development approach where the whole team works on the same thing, at the same time, in the same space, and on the same computer. This extends the concept of pair programming from two people working together to the entire team continuously collaborating on a single computer to deliver a single work item at a time.
In addition to coding, teams practicing Mob Programming works together on almost all the work of a typical software development team including defining stories, working with customers, designing, testing, and deploying software. This work is accomplished in workshops or “working meetings.”
The team consists of everyone involved in creating the software, including customers.
The Mob Programming approach relies on concepts such as face-to-face and side-by-side communication, team alignment, collaboration, whole team involvement, continuous code review, and self-organizing teams in order to be effective.
Expected Benefits
The collaborative nature of Mob Programming causes many problems that software development teams generally face to “fade away.” These problems include:
Communication Problems such as waiting for answers to questions, the time involved in back-and-forth email conversations, and the chance of misunderstanding arising from communicating via documentation. These problems are all reduced or eliminated by the collaborative face-to-face nature of communication in Mob Programming.
Decision-Making Problems such as reluctance to make decisions and the need to defend decisions that are made. Because the entire team makes decisions, those decisions are made with much more current and relevant information. Also, teams using Mob Programming view decisions as an opportunity to learn and to continuously steer to a better solution.
Doing more than is barely sufficient causes waste. When a team works on one thing at a time and aims to deliver something to actually use every day, the team tends to keep things simple and prevents the addition of unnecessary things. Involving the entire team, including the product owner in these daily efforts prevents someone from inadvertently adding more than what is truly necessary.
Technical Debt is anything in the code that makes it harder to maintain. Mob programming places many sets of eyes on the current work and dramatically reduces the chances of many types of technical debt from being introduced in the first place. The many sets of eyes also increase the chance that the team identifies technical debt somewhere else that is slowing their progress on the current work.
The thrashing of team members, and the team from context shifting results in a loss of time and focus. Mob Programming prevents thrashing through its use of single-piece flow and reduces the impact of thrashing because others on the team can continue on even if one team member is asked to switch contexts.
Politics at the individual developer level, such as how much people will help each other, can have a detrimental impact on the effectiveness of teams. Mob programming reinforces the work of the team and encourages people to figure out how they are best suited to help the team.
Meetings can lead to a separation of work and knowledge creation from decision-making. Ironically through the use of ongoing, “working meetings” Mob Programming ensures that work, knowledge creation, and decision-making are joined together thus leading to much better alignment and more effective action.
Common Pitfalls
There are some things to consider when adopting Mob Programming:
An approach to working where you are in a state of constant collaboration with your team for the entire day may not appeal to everyone, and some team members may find other opportunities, or cause disruptions because they are not comfortable with this way of working. The team may be able to address these concerns with working practices that leave it up to team members to withdraw from the group during certain periods if they need focus time, or those members who are not comfortable with this way of work may find a different group to work with.
When a group of people works closely together day in and day out, there is an increased risk that contagious illnesses will run rampant through the team. Team practices that acknowledge this fact and account for it can lessen the probability and impact of this risk.
Mob programming will only work if the team sees value in this approach and chooses to work in this manner. Because Mob Programming involves commitment and changes in work style for everyone involved, the change will not be nearly effective if people feel they are being forced to make the change.
Origins
2011 A Software development team at Hunter Industries happens upon Mob Programming as the evolution from practicing TDD and Coding Dojos and applying those techniques to get up to speed on a project that had been put on hold for several months. A gradual evolution of practices, as well as a daily inspection and adaptation cycle, resulted in the approach that is now known as Mob Programming.
2014 Woody Zuill originally described Mob Programming in an Experience Report at Agile2014 based on the experiences of his team at Hunter Industries.
Signs of Use
A team that is using Mob Programming effectively will exhibit the following characteristics:
- Members of the team approach all of their interactions with each other with kindness, consideration, and respect.
- The team’s physical space is set up such that the entire team can work on the same thing at the same time on the same computer without ergonomic issues.
- The team practices single-piece flow by starting, working on, and delivering one work item before moving on to the next item.
- The team is always seeking to improve through frequent retrospectives matched up with concrete action items.
