Mob programming is based on solo programming
The core principle of mob programming is that minimizing handovers improves workflow. Handovers typically occur when one person completes a piece of work and another person needs to understand it subsequently. This necessitates explanation because the person taking over wasn't involved in the initial work and lacks context. In such scenarios, individuals must communicate to understand the tasks they are about to undertake. Consequently, a team relying on individual assignments first decides who should tackle which task. This approach often operates under the assumption, "Now that each member understands their part, the tasks can be completed separately."
In contrast, mob programming employs a completely different work style. Mob programming teams avoid assigning tasks individually. Instead, they work on tasks collectively as a single unit, without assigning specific roles for each piece of work. The entire team tackles the work together.
I believe a fundamental concept underpinning mob programming relates to the inherent efficiency observed in solo work. Consider a team with only one developer and a backlog of items. The developer picks a task from the top of the backlog. After completing the task, the developer selects the next item. This process repeats. Throughout this workflow, no task assignment occurs because there's only one developer. This illustrates the core concept that, I believe, inspires mob programming. Although teams usually consist of multiple people, when they work together as a mob, they function as a single entity. It's like a virtually single person. Therefore, there's no need to assign specific tasks to individuals. They simply start working from the top of the backlog as a unit.
So, what distinguishes mob programming from solo programming, given that its core idea seems to draw inspiration from the solo approach? In mob programming, multiple brains and sets of eyes are engaged simultaneously. This collective environment facilitates a process similar to internal brainstorming or rapid idea exchange, akin to synapses transmitting signals between neurons. This dynamic can significantly boost speed. Furthermore, multiple perspectives continuously review the work in real-time, which contributes to the quality of the output. Conversely, in true solo programming, the developer works completely alone, meaning there's no one immediately available for consultation or real-time quality checks. Of course, a solo programmer can seek input from others, but this requires explaining the context and the work accomplished up to that point, often involving a delay in receiving feedback. Mob programming aims to enhance speed while simultaneously reducing errors through this continuous, collaborative review.
Some argue that parallel work is faster, but that perspective often ignores the cost of coordination. Mob programming focuses on eliminating these coordination costs, specifically by minimizing handovers and the associated waste. Parallel work inevitably requires integration points or 'joins'. Just as in software development, synchronizing separate processes can be costly and complex.