Maaret Pyhäjärvi, F-Secure tester and co-author of the Mob Programming Guidebook, recently wrote about her experience with mob testing, and her team's journey from scepticism to improved personal and team competence across a cross-functional skillset. According to Woody Zuill, father of #NoEstimates and a co-creator of the Mob Programming practice, it not only offers real-time upskilling of team members, but also presents an effective collaboration model for delivering software through a succession of small and releasable increments.
Speaking on a two-part episode of the Agile Uprising podcast in February, Zuill described the practice as:
Everyone on the team is collaborating together to come up with "what is it we're working on?" and "what are we going to do to make this into something we can deliver?" It's all the brilliant minds working on the same thing at the same time in the same space and at the same computer
At GOTO Copenhagen, Zuill gave a talk in which he pointed out that a "continuous integration of ideas" is a major characteristic of mob programming, where the presence of key perspectives naturally "shifts left" the feedback loops. He explained this further on the podcast, pointing out that a mob requires a broad complement of skills to achieve a deliverable increment of working software:
Not only the coders, but a tester, a database expert, the product owner, or a product expert who understands what they want this thing to do, and whoever else is needed to make this software go from the idea that it is into something somebody can use.
Zuill explains further that in order to collaborate effectively the team needs to work in small releasable steps which can be rapidly delivered to provide feedback:
As we start on some work, we take a small chunk to accomplish. We want to go from beginning to end of a small chunk. This has to be cohesive. The things have to belong together and can't be decoupled. It's in the doing of the work we discover the work we must do. Not matter how much we think we know about something and imagine how we want it to be, we still need to work on it in steps. If we get good at separating things into potentially usable bits, we can take that bit from beginning to end as directly as possible and get it into use by someone. That will give us feedback as to whether we're stepping in the right direction.
In telling her own tale, Pyhäjärvi writes about having been focused on her journey to mastery as a tester, and how she had "no intention of becoming a programmer. Not for lack of aptitude, but for lack of interest and time." When initially introduced to mob programming, she convinced herself that it was solely valuable for "programmer-tester communication," but that she was "convinced it was time away from things (she) loved, mostly testing." Looking back, she writes:
Little did I know that something no one could convince me of, learning to program and becoming a programmer, would be a reality a year later.
Pyhäjärvi described her own team's collaborative approach:
Mobbing (Mob Programming or Mob Testing) starts with the idea of a group of people using a single computer, forcing a true single-piece flow. Each member of the group sits in front of that computer, when it's their turn, rotating on a timer every few minutes, continuing to work on the same task until completed. Instead of using a round-robin mechanism to taking turns of who works while others watch, mobbing makes everyone work together through strong-style navigation.
Pyhäjärvi described how her mob, in a fashion similar to pair programming, applied the driver-navigators paradigm where:
Whoever is on the keyboard (the driver) is not allowed to decide what happens on the keyboard. The instructions come from the group (the navigators), which guides on the highest possible level of abstraction. The idea is not to get most out of each individual but to get the best idea into the work the team is doing, to avoid having to go back and revisit it, by having everyone's ideas available in a timely manner.
Zuill explained that when his team originally discovered Mob Programming, it was through an exercise of "read by refactor":
You learn about the code that you need to work on by starting to refactor. It allows you to read it in a much more complete way. As soon as we started refactoring and the navigator was navigating it, someone would chime in. We started trying different ideas and sharing them in real time. After an hour we saw great progress in what we'd been doing. And we'd acquired this shared understanding as a whole team.
Pyhäjärvi explained that in order for her team to effectively navigate their driver, the team chose to communicate with an awareness of three levels of abstractions:
- Intent: "the first step, when we explain what we want"
- Location: "used next if intent alone was not enough to make the action happen exactly as we intended, e.g. use the search with a keyboard shortcut instead of menu."
- Details: "used as low-level explanations of what to do if we still fail to get movement in the intended direction, e.g. Type control + F."
Pyhäjärvi described how a mob scenario encourages a bias towards action and the necessity to communicate:
The group usually starts with a clear task. For programming activities, a simple refactoring of code is a great thing to do in a mob. Any of the programming Katas or practice exercises can also work. Testing activities could include an automation script or a focused charter for exploratory testing. Whatever we chose, the first challenge is usually communication.
Pyhäjärvi elaborated on the communication challenges which arise as the team calibrates to working effectively together:
As a mobbing session begins, it is hard to find the words to say. Someone might not know what to call the thing next to line numbers in our IDE (gutter). We seek words to clearly state what we want to be done. Similarly, some are not used to listening patiently and attempting to follow someone else's intent. While mobbing allows the driver to speak back and suggest better ways, the power of deciding what to do next is on the navigators.
Despite the initial challenge in communication, Zuill discussed the advantages of an effective mob over a serialised workstream, with the communication overhead of individual team members working independently towards later convergence:
A funny thing happens when we focus all the brain power, skills and abilities into one thing. We go very directly and very rapidly to something we can use. If we'd separated the work up, it might take a week or two to accomplish it, because of the cost of the communication, coordination and everyone working on different things. If we go from a week, to two or three hours, there's a huge win in the rapid feedback loops."
Pyhäjärvi also discussed how her mob managed to unblock itself in the face of disagreements by taking an approach which biased itself towards action. She writes of the two mob rules which they applied in these situations:
- "Yes, and"-rule: "The group is working in a mindshare. When something is started, it is finished, but we can add to it."
- "Do Both"-rule: "If given two ways of doing something, list them, and then do both. Start with the one you find less likely, or just random. The goal is to give everyone a voice which is acknowledged."
Pyhäjärvi emphasised that the onus of these rules was on doing, because "as the team does, the work unfolds in ways they did not see before."
Pyhäjärvi recognised that, as a tester, the mob dynamic also allowed her to champion and ensure that an appropriate mindset and level of quality was being applied to the solution. She also observed the mob upskilling, through their asking very testing centric questions and demonstrating a maturity in how they validated their solutions.
Commenting on the size of a mob Zuill points out that this can be decided by asking the question:
If we can't go on it from beginning to end with the knowledge of this group of people, then we are missing someone from the team.
Zuill will be facilitating at the hands-on Mob Programming Conference in Burlington, Massachusetts, this April.
