Mobbing (not just for programming) [webinar recap]

In these uncertain times, many testers are looking for innovative ways to collaborate and move their projects forward while working remotely. Especially as organizations are feeling the pressure to develop and launch new applications for their audiences as quickly as possible, it’s essential for testers to be as productive as possible to speed up software releases.

Two weeks ago, we had the exciting opportunity to host a guest webinar with Lee Marshall, also known as The Pirate Tester, about mobbing in testing. He discussed how testing teams, as well as organizations at large, can leverage the principles of mob programming to encourage stronger collaboration, receive immediate feedback, and ultimately allow the best work to happen. Speaking from his own experience of implementing mobbing at his company, he presented a strong case for using mobbing outside of a programming setting and gave those in attendance a step-by-step overview of how to start a mob at their own companies.

Here is a brief summary of what Lee discussed in the webinar below, and you can also watch the full recording here.

Strong-style pairing as the basis of mobbing

Lee started out his talk by explaining the difference between mobbing and another popular method of collaboration: strong-style pairing. He noted that strong-style pairing actually serves as the basis for mobbing, but is done on much smaller teams (ideally teams of 2). Strong-style pairing is an attractive way of working because it helps build stronger communication skills and trust between team members.

In a strong-style pair, there are two distinct roles: the driver and the navigator. While the driver is the one physically using the keyboard, mouse, and other tools to perform the actual actions, the navigator is the person who gives instructions and drives the strategy of doing the task at hand. By dividing up the responsibilities this way, a strong-style pair ensures that the navigator is giving clear instructions, as well as placing full trust in the driver to perform the tasks correctly.

How mob programming is different

A mob, also known as mob programming, takes these basic roles of a strong-style pair and applies them to a larger team of 3 or more people, while also adding two more critical roles. While mobs still use a driver and navigator, everyone else is assigned another role, known as the “mob”. The mob is the group of people who come up with the ideas, and the navigator still maintains his or her strategic role by choosing which direction to go in after weighing the mob’s different options. Another role that can come up in a mob is that of a “facilitator,” who keeps the mob focused on their goals and enforces the rules within the mob. Especially with a larger group of people that is just getting started, a facilitator can be a great third-party player that helps the mob mature over time.

Another important difference between a mob and strong-style pair is that in a mob, participants change roles frequently. Lee noted that he tries to keep people in the same roles for 4 minutes at a time, but also suggested other ways that teams could switch roles by tasks or allow for longer stints of time before changing roles when there are fewer people. This gives everyone the chance to contribute their thoughts and get hands-on experience in dealing with each aspect of the task.

Why start with mobbing at all

After describing the basics of mobbing, Lee made the case for why testing teams (or any other team for that matter) would want to start mobbing in the first place. The first major reason Lee is a major advocate of mobbing is that it lets everyone in the group voice their opinions. As opposed to a brainstorming session where more outspoken team members control the meeting while the team introverts are left unheard, mobbing eliminates this issue by requiring everyone to change roles. When an introvert has their turn as the navigator and an extrovert has their turn as the driver, there is a lot of room for communication that may not have happened in any other setting.

Other advantages of mobbing are that it lets you get the best out of each team member and reduces wait-time for feedback. Lee explained that in mobbing, there is a concept that if one person in the group knows a skill, it’s as if everyone in the mob has that skill. While the mob is in session, team members have the opportunity to learn skills from one another and bounce around different ideas. Additionally, since everyone who is relevant to getting the task done is taking part in the mob, team members will receive immediate feedback on their work. This way of working will increase productivity both in the short term (for the task at hand) and in the long term (for future projects).

Finally, Lee is a major proponent of mobbing because it doesn’t require coding or other special skills to participate. When pitching the idea to his own workplace, Lee noted that the main reason mobbing garnered so much interest was that it is not tool-specific, role-specific, or domain-specific. While mob programming is typically a way that developers or other technical people can work together, mobbing takes the structure of mob programming and makes it more accessible.

Getting your mob started in an age of remote work

While mobbing is normally done when a team is physically in a room together, Lee assured those in attendance that testers can still mob successfully while working remotely. When working together physically, a mob requires a few different tools to get started: a whiteboard and marker, a single computer, and a room with a screen. The whiteboard and marker are used by the navigator to track the mob’s suggestions and drive the mob strategy, the computer is used by the driver, and the room will ensure everyone is in one space and can change roles.

While working remotely, Lee suggested having a suitable method of screen-sharing (such as Zoom) and a shared area where everyone can show their work, such as a Git repository or even Google Docs. The driver will share their screen on Zoom while in a remote mob, and everyone who becomes the driver afterward will take control of Zoom when it’s their turn. The one main point to remember when running a remote mob is to make sure that people who aren’t the driver aren’t doing things outside of their roles without other people knowing. This should either be made clear at the start of the mob session, or the facilitator can monitor the tools you are using to make sure that everything is happening smoothly.

Questions about mobbing from the audience

At the end of the webinar, Lee reiterated that mobbing is a great way to keep people together, especially when so many people are working remotely for an indefinite period of time. With mobbing, not only will team members have the opportunity to improve their work individually, but they will also be able to move their work forward faster and more smoothly as a result.

Lee then concluded by answering questions from the audience. For your convenience, you can read the questions and his answers below:

When remote mobbing, isn’t it better to do an event-based rotation, especially if the mob was sharing a distributed source control system?

“The important thing to remember is that the suggestions I gave during this webinar are purely guidelines. Rotations can either be after a few minutes or event-based if that works better for your team.

If you choose to go with an event-based rotation, I would recommend that you think about how long people will be working on activities before changing roles. If things take too long, people may lose focus and interest. But with everything, you can always try it out and see if it works.”

Should everyone from mob have similar levels of expertise? If there is a junior or newer person on the team, shouldn’t they act as the driver most of the time in order to gain knowledge?

“That’s a good point. But it’s important to remember that if a junior person is always the driver, then they won’t be able to share their ideas. By being part of a mob, more junior or newer teammates will have the chance to share their opinions with fresh eyes. By going through all roles, everyone will have the chance to gain a greater breadth of knowledge without depriving them of other opportunities.”

How can I convince my boss to start mobbing? Alternatively, what reasons as a manager would you let your team start mobbing?

“It depends on how much your manager trusts you and what drives your management team in general. If you have a team of 4 or 5 people and do a 1-hour mob, you can show different levels of achievement when working together in comparison to 5 hours of individual billable time. You can also pitch mobbing as a helpful way of getting new or more junior people up to speed. If your management team is more outcomes-focused, you can emphasize achievements such as accomplishing team goals more quickly, developing clearer objectives, and gaining skills more quickly.”

Which types of testing can benefit most from mobbing?

“There isn’t a type of testing that won’t benefit from mobbing. In exploratory testing, a mob can help determine what the charter is and decide how to achieve that charter. It’s also a great tool for test design by making sure tests fulfill the necessary requirements, plus allowing the opportunity to bridge gaps within tests and take away unnecessary steps.”

In practice, how often should teams use mobbing before picking up a user story?

“It depends on the team and the organization. Some may find it better to do more mobs for shorter amounts of time every few days, whereas others may find that it’s better to run mobs less often but for a half-day or full-day. While I prefer the former, there is no hard and fast rule; rather, it’s what is better for your team.”

How is mobbing different from brainstorming?

“The main difference between mobbing and brainstorming is the structure of fixed roles. Because you have enforced roles with mobbing, you don’t run the risk of some people being too passive or dominant within the group. Mobbing is also more consistent and helps everyone add more value. You can’t necessarily brainstorm to achieve more practical goals, but you can do so with mobbing.”

Are there mobbing best practices that you would recommend specifically for testing?

“Make sure you know what the mob is trying to achieve. Like with any type of testing, it’s important to set clear goals from the beginning. Otherwise, you will waste time and resources, and not get as much out of mobbing as you can.”