Other Considerations

Pair programming

Pair programming is a practice in which two developers sit side by side, one writing code and the other playing a role of realtime reviewer. The roles are sometimes described as pilot and navigator. Pair programming is especially associated with Extreme Programming.

Industry data on pair programming has shown for many years that the output of two people working as a pair is roughly comparable to the total output of two people working individually, the quality is higher, and the work is completed more quickly (Williams, 2002), (Boehm, 2004).

Despite it being strongly associated with Agile development, I have not emphasized pair programming as a more effective Agile practice because in my experience most developers do not prefer to do most of their work in pairs. The result is that pair programming in most organizations has settled into being a selectively used niche practice—mainly for critical or complex parts of the design or code. Beyond that selected usage, if I had a team that wanted to use pair programming extensively, I would support that, but I wouldn’t insist on it.

Mob programming and swarming

Mob programming is a practice in which the whole team works on the same thing at the same time on the same computer. Swarming has the whole team work on the same story at the same time, but each team member works on their own part of the story at their own computer. (Usage of these terms varies, so you might have heard them used differently than I’m using them here.)

A few teams have experienced success with these practices, but efficacy is still an open question. Even among reviewers of the pre-publication draft of this book, advice ranged from “don’t use at all” to “use only with new teams” to “use only with experienced teams.” I don’t see any clear center of gravity for these practices yet, and so overall I regard both mob programming and swarming as niche practices that should be used selectively or not at all.