Lisi Hocke, a tester at FlexiBus who also blogs on testing, recently spoke at the Testing United conference in Bratislava about how she helped shape a collaborative environment with a "whole-team-approach" to testing, partly through the use of mob-programming. Hocke described how her team scaled the driver-navigator relationship of pairing across a larger mob, to maximise active involvement. Maaret Pyhäjärvi, author of the Mob Programming Guidebook, and Jeff Langr, author of Pragmatic Unit Testing in Java and several chapters in Robert Martin's esteemed Clean Code, have also recently written about their own patterns for maximising the benefits of mob-programming.
Hocke discussed how her team tried mob-programming "by the book" and found it effective. She explained that traditionally, pairing would often result in the person with the idea grabbing the keyboard. Instead, mob-programming depends heavily on the driver-navigator pattern, which she described as "strong-style pairing." Hocke explained this, saying that "for an idea to go into the computer, it has to go through someone else's hands." Her team chose to mob on-demand for activities where they felt it made sense. She said that they would also "mark a story in advance for mobbing" if it was suitable. According to Hocke, mobbing was useful for surfacing and sharing both implicit and explicit knowledge, as well as solving "tricky problems, (where) having all-brains-in really helped."
Langr recently wrote an article titled Solo Programming, Pairing, and Mobbing: Which Is Right for You?, in which he went over the theme of his 2018 Agile and DevOps East talk. He discussed three collaboration patterns, which he described as solo-programming, pair-programming and mob-programming. Langr observed that both solo and pair-programming presented communication and knowledge sharing challenges. He wrote that in situations where developers and testers build "systems containing countless interactions," any isolation can "create headaches and increase costs."
For solo programming, Langr attributes this to the higher cost of late communication and regressions caused through poor coordination. In the case of pair programming, he cites similar issues caused by the formation of sub-silos within the team, as well as the management overhead of effectively coordinating multiple pairs. He contrasts this with the benefits of a team-wide mob working on the same software increment, collaboratively at the same time. Langr observed that mob-programming removed several impediments which he had seen arise in non-mob contexts. He observed that mobbing brought about:
- Removal of coordination and personal biases over the question of "who's pairing with whom?"
- Removal of synchronisation efforts, as "everyone is in the room at the same time, so we all already know what's going on."
- Reduction in collaborative and learning-centric ceremonies, as both of these, are happening continuously.
Similarly, Pyhäjärvi's article discussed four collaboration models which testers can target or find themselves in; individual work, traditional pairing, strong-style pairing and mob-testing. She stated that the strong-style is the "foundation of mob testing (and mob programming)." Pyhäjärvi wrote:
In this style of working, you have a group of people working on one task, taking turns on the computer. Ideas come from the crowd not on the computer. This is about getting the best out of everyone into the work we are doing. Everyone takes turns at the keyboard, and if you have someone unequal at (the) task, the mob helps out navigating at an appropriate level of abstraction.
Similarly, Hocke described how her team's mobbing agreement supported a strong-style, while encouraging the driver to suggest ideas but "not rush ahead of the group." She also shared how permitting partial-mobs facilitated individuals to partake in extra-mob responsibilities, and often demonstrated their keenness to rush back.
Both Pyhäjärvi and Hocke conveyed stories of how effective mob programming had resulted in better pairing. Hocke said, "the side effect of all this (is) suddenly people pair up a lot more" in "many different constellations." Pyhäjärvi wrote about how using a strong-style of mob-testing helped her feel more comfortable when collaborating in pairing scenarios:
For me adjusting to strong-style is what made pairing turn from frustration to learning fun and something I'd volunteer for. Similarly, mobbing was the gateway to pairing, making me comfortable in a group before being alone with each of my team mates.
Hocke spoke of how she hoped to see cross-team mobs and testing as her teams continued to improve. While cautioning on the management overhead of pairing, Langr also suggested that pair-swapping was a good practice to avoid reinforcing local design biases:
Because two heads are better than one, pairs produce higher quality solutions that cost less to maintain. But it's still possible for a pair to go down a rathole with a bad design. Consequently, frequent pair swapping is a good practice: An individual swapping into a pair has an opportunity to prevent a troubled solution from reaching production.
In her talk, Hocke said that her team solved issues around the ergonomics of seating, differing tooling familiarity and inclusiveness, but that they had not been affected by common mobbing problems. She called these out as "talking over each other", "not trying junior ideas" and individuals "not getting any chance to talk at all."
Langr closed his piece with the reminder that every pattern has its place according to the situational context:
Solo programming, pairing, and mobbing—the development modes listed in order of their collaboration value—each has its place in a modern software development effort. Each is effective for certain kinds of challenges.