We were huge advocates of pair programming and have directly experienced the many benefits of pairing, but when we first heard about mob programming with thought it sounded crazy! Perhaps… so crazy it might actually work. Mob programming is a software development practice in which the whole team works on the same code at the same time. In our experience, mob programming can be significantly better than programming alone. While mobbing, we’ve created some of the best code our team has ever written faster than the typical code review cycle. We’ve explored new domains and architectures quickly. We’ve helped individuals feel more confident in their ability to change the system and built strong bonds within the team. In addition to these huge wins, we’ve also experienced a few bitter failures. Mobbing can be a tremendous waste of time in some circumstances. Not all mobs can work on all problems. Sometimes people forget how to be a good teammate.

In this report we explore a set of mob programming patterns discovered by two different teams and two different companies — LendingHome and IBM — after more than a year of practice. Patterns we found include emergent roles in the mob such as the recorder, researcher, and facilitator, collaboration patterns such as create a punch list and form splinter groups, and driving patterns such as think out loud and asking the mob to tell me what to write. While the patterns themselves proved interesting and useful, we were surprised at how much our mob programming improved after even modest reflection regarding our practice. In addition to the mob programming patterns, some of which corroborate experiences shared by other teams, we discuss the benefits of pattern harvesting as a mechanism for supporting reflective practice and general process improvement.

You must be a Member to view this post and you are currently not logged in.

You can either log in below or sign up here.