While most of our time was spent mob-programming as a whole, on occasion, we would deliberately turn the “parallel” mode on. The most important difference in this approach compared to traditional or even pair or mob programming team setup is the fact that the team as a whole is always focused on a bringing a single work item to a close. However, they still might focus individually, in pairs or in smaller groups to remove different impediments that stand in the way of completing the current work item.
Probably the most important benefit of the ability to react and reorganize was the capacity of the main group to continue working on current items in “business as usual” fashion, while a few members would deal with impediments and urgent or unplanned issues. This means that the normal team dynamic remains unaffected, learning continues and all members are still very much aware of the current work in progress. Here are several patterns I was able to identify.
Some kind of impediment appears, preventing a team from bringing certain item to a close. A member, pair or a group will break out from the team and work on removing the impediment. After the impediment is removed, those who branched out return to the main mob.
Another situation when branching out is warranted is when some routine, low-complexity work needs to be performed. Such work presents only a small opportunity for learning. Performing it in unison does not provide interesting benefits when all team members are already familiarized with the procedure and automation is not warranted.
In those situations a member “branches out” to perform the work and joins the rest of the team once this “solitary” work is done. A similar approach would take place when some urgent issue was reported: one or two members would branch out to investigate and, if possible, resolve the issue. In the meantime, the rest of the swarm would carry on with original work.
From time to time a defect was discovered that was uniformly applied across the code base effectively forming an anti-pattern. In such a situation, after resolving the first occurrence as a group, the team would “spread out” to apply the solution to the rest of the defect instances. After the work is done, the team would join to comment on different facets of the defect and how these were resolved, as well as to document the experience. Spread out is similar to branch out, however, spread out implies putting parallelism to maximum use. Branching implies a small group dedicated to resolving a tangent issue.
Keep one in the dark
Some people argue that groups can stifle creativity and lead to irrational decisions, motivated by conformity, a phenomenon known as groupthink (Janis). In order to avoid this happening to our team, from time to time one person would purposefully abandon the swarm until a certain task was finished. After completing the task, a code review would be performed where the solution was presented to the team member temporarily excluded from the swarm and where he was able to question the decisions taken. His suggestions would then be incorporated into the solution if warranted.