Does Mobbing Really Speed Us Up?

Attend one of my classes on test-driven development (TDD), and you won’t be programming alone. You’ll work in pairs or if the class is small enough, you’ll participate as part of a mob as you learn how to test-drive code.

The bulk of my past students worked exercises as part of a pair. Pairing shines in a classroom environment. The book “Training from the Back of the Room,” by Sharon L. Bowman, promotes having students learn from each other as a way to increase learning. Pairing gives students a chance to interact with each other, bounce ideas off each other, and lean on each other for help without the intimidation factor of having to ask me. With pairing, my students more quickly ramp up on TDD concepts.

Mob programming, or mobbing, takes this notion of collaboration to the extreme: Everyone in the room collaborates to solve the current challenge. I’ve used mobbing as a classroom technique for a couple of years now because, for companies that want a given team to learn together, mobbing provides a way to ensure everyone turns the same page at the same time.

Leveling Out

Most classrooms exhibit a bell curve distribution. The bulk of students are capable developers who work at a steady speed, in line with the other developers. A small number of students are very experienced and more effective. A comparable few are perhaps programming novices who struggle with the exercises.

Left to work alone, the capable developers in the class finish ahead of everyone else. They become bored and sometimes end up distracting other students, or even me, as a result. Sometimes I’ll throw these overachievers additional challenges for extra credit, but that too increases the amount of attention I must give them.

At the same time, the novices in the class lag behind everyone else. They often need special attention to fix mundane and unrelated problems. Their challenges distract me far too often in proportion to the rest of the class, and often for reasons unrelated to learning TDD.

If students pair with each other, I have them swap pairs from time to time. One person stays to work the current exercise, and the other gets up and finds a different person to work with. I sell the class on pair-swapping by suggesting that the rotation helps to disseminate information throughout the team, but I have students swap mostly to ensure that the pairs are reasonably balanced. Rather than a devastatingly off-track pair of underachievers, I’ll hook up an overachiever with an underachiever.

By the end of the class, the novices have usually picked up enough knowledge and even a bit of speed. Further, the experienced developers have gotten a little better about explaining to the novices. In a software development world where the average developer is left to their own devices in a cube, any sort of increase in “code socialization” can only help us as a team.

The use of pairing has always helped make for a more effective classroom environment, partly by leveling out the pace somewhat. No student left behind!

The Overhead of Pairing

Some raise the concern that pairing takes twice the time of solo development, but that’s only true if you think programming is merely about typing, or if you think code is written once and never read again. Having two people collaborate to solve a problem definitely generates some increase in quality—both from the notion of the solution’s design and the readability of the code to implement the solution.

Other costs of solo development, some intangible, continue to represent an increased ROI for pairing. I’ve written enough about these potential benefits of pairing; see “Pair Programming Benefits,” co-written with Tim Ottinger, for a long list.

However, there are certainly maintenance costs, or overhead, involved in pair programming that reduces its ROI. Switching pairs is perhaps the most obvious overhead: Ramping up on new code doesn’t come for free, and we’re asking you to switch pairs fairly often. Risks also exist when some unfortunate pairings occur—for example, when a novice pairs with a novice (“the blind leading the blind”), or when a dominating programmer steamrolls someone too timid to speak up. Clashes over development setup can hurt effectiveness, as can discomfort due to the physical environment.

Getting a team to pair effectively demands some level of attention, whether it be from a coach or from team members savvy enough to introspect well.

The Value of Minimizing WIP

Perhaps the largest cost to pairing, however, is that it—and solo development, too—are admissions that we are probably working on more than one thing at a time.

In a typical trying-to-be-agile shop, you’ll find considerably high amounts of WIP, which can mean either “work in progress” or “work in process.” If a team consists of five solo developers or five pairs, chances are good that five stories were started at the outset of the iteration. Chances are also good that a high percentage of these stories are at risk of getting completed by the end of the iteration. Many daily standup minutes and keystrokes in Jira are spent to help track progress toward a given in-progress story.

Given the nature of software development, interruptions and blockers are common enough to increase the WIP number even more. The resulting context-switching exacerbates the overall cost, which is further compounded by the cost of ramping up again on code that has likely changed since the last time you touched it.

You’ll find numerous articles on the benefits of minimizing WIP. To cut to the important part: “Work is not valuable until it reaches the hands of the customer.” Invariably, people who have promoted limiting WIP claim shorter cycle times, shorter lead times and fewer defects.

Speeding Us Up

One thing I’ve heard a number of times from teams who mob is “We go faster.” Every time, my mind races through lots of thoughts: Fascinating! Are they making that up? How is that possible? How would they really know? Prove it!

I’ve been trying to think about reasons mobbing might increase speed, occasionally iterating them. Any one of these reasons alone might be debatable. But the aggregate list shows enough weight to convince me that there might really be something there.

Here are the things about mobbing that incrementally can increase our speed:

• We’re not blowing 15 minutes every day listening to a glorified status report.
• We’re not planning the details of a future story.
• We’re not worrying about the mechanisms of how we work together (e.g., pairing).
• We’re minimizing context-switching costs.
• We’re not reworking the inadequate design of another pair or individual.
• We’re spending far less time making sense of our own code, because everyone was on the same page when we wrote it.
• We’re not subject to the bad code of a rogue or inept developer.
• We don’t have to call special meetings to engage members of our own team.
• We’re focusing on delivering value, not getting “my” work done.
• Through strong-style pairing and timed rotation, we’re ensuring that all our team members increase in individual effectiveness (and in a minimally intimidating fashion!)
• We learn how to describe code (and what needs to be done to it) in a more effective manner.
• We produce fewer defects—and the cost of a defect is probably far larger than most people think.
• We don’t spend time reading and reviewing pull requests, and we generally don’t do code reviews.
• We don’t blow hours trying to figure out an answer on our own when the person with the answer is already on our team and available.
  We adhere to the small set of standards we value, which includes things like doing TDD or producing a solid set of acceptance tests via behavior-driven development.
  We are more likely to refactor enough toward the simplest possible design, which helps reduce the cost of introducing new features.
• We minimize the angst over estimates and weak notions of commitment because the mob finishes the current feature, ships it and moves on to the next.
• We often address interpersonal and other team challenges immediately.
• We’re generally having more fun, which means we’re not surfing the net out of sheer boredom or anxiety about work.

Trustworthy scientific research won’t exist any time soon for the vast majority of these claims. Nor does it exist for the claims of pairing, or even solo developers. But the potential time savings are many enough to convince me to continue exploring mob programming as a way of developing software (in addition to continuing to pair and solo-program occasionally). As I do, I’m sure I’ll note additional factors that can speed us up. Please send me your discoveries too!