Introduction

The benefits of pair programming are documented: better, simpler code written in less time; improved interdeveloper communication and feedback; and shared code ownership, to cite a few [Williams+2000; Cockburn+2001]. We have undertaken an experiment on our development team to see if some of these benefits remain when the programming group grows beyond two people. This experiment evolved from regular developer lunch meetings originally run in a presentation format, with one member of the team presenting code familiar (usually only) to him or her. At the time, we were not employing XP practices but had vague plans to do so at some point in the future.

Since then, the team as a whole not just the developers has begun to take the first steps toward XP. We now have iterations and some form of continuous integration; we are writing unit and acceptance tests; and we have dabbled in pair programming. Because our team is unfamiliar with and therefore unsure of XP's benefits, it is useful for us to find ways to experiment with and eventually to reinforce beneficial XP development practices.

To this end, we have identified long-term and short-term goals. Regular developer meetings cannot achieve all these goals on their own. However, we intend for the meetings to facilitate this achievement in the context of a broader set of XP practices. In the long term, we want to decrease individual code ownership, to encourage pair programming, and to improve unit test coverage. We want to improve the overall quality of the code we write. Formal mentoring is not an option, so instead we want to provide greater opportunity for developers to work together, enabling them to exchange information about coding standards, helpful programming patterns, and design decisions. Finally, we hope that working together regularly will build our sense of ourselves as a team.

In the short term we want these meetings to be fun and interactive. We want the format to respond to our needs and interests as they evolve over time, so that the meetings do not feel forced. We also typically set a small practical goal before ourselves to provide something as a focus for our attention. In the beginning this practical goal was the short presentation but has recently evolved into what we have capriciously termed "mob programming," the refactoring of a small piece of code in groups larger than two people.

The formation of this weekly ritual has been an iterative and ongoing process as we continue to strive for a format that feels "natural." We have by no means arrived at this desirable goal, but we hope that an account of our experiences is nonetheless interesting to the reader. Therefore, we begin with a historical description of our efforts. With this picture, we move on to compare an idealized view of mob programming with the values of XP and to discuss the lessons we have learned that help mob programming be more productive. Before concluding, we discuss some of the problems we have encountered during our experiments.