Power Hour – Pairing & Mobbing

On the 22nd of August Lisi will spend an exciting hour on The Club tapping away at her keyboard answering your questions related to pairing and the mob approach and how all roles can benefit from this kind of close collaboration. Ask your question to get it answered.

Hi everyone, my name is Lisi. :slight_smile:

Back in the day, I started out as a strong individual contributor. I was always passionate about the whole team approach to testing and quality, yet remained working solo in an asynchronous way. During more recent years, however, I discovered pairing and mobbing – and it changed my world. I’m here to answer your questions about:

  • What pairing and mobbing is all about and how it works
  • When to pair or mob, when not to
  • What makes it easier or harder
  • How to get started yourself
  • Why it’s worth a try

Get all your questions in by 22nd of August before 7pm BST and I’ll do my best to answer them during my power hour!


I have no immediate questions to this, but I’m looking forward to this, as pairing and mobbing are great ways to work, and something that more people should try out!


I’m going to start with a few simple questions:

What is Pairing? What is Mobbing?
Are they the same thing?
What are the benefits?


Hi Leslie,

What are your recommendations to use the concept of pairing and mobbing outside working project but in building stronger testing communities of practice?
How can we apply it in that case if we are not focusing on a project?

1 Like

My team have recently started doing a lot of pairing/mobbing sessions. I mentioned this power hour, and asked for some questions. Someone asked “What about Swarming?”

What is swarming? How does it differ from mobbing/pairing? What are the benefits?


Other than programming, what sort of activities could pairing/mobbing be applied to?

We’ve recently started bug hunt days with a mixture of time boxed individual testing/pair testing/mobbing sessions. Any other suggestions?

Any activities which are not suitable for pairing or mobbing?


People seem to be afraid to do this. How do you recommend asking people to do pairing and / or mobbing in the least threatening way? For context, I mean paired / mob testing. We don’t have on-site access to developers.


I have a lot of experience pairing and some experience mobbing. My previous teams either had a company policy of full time pairing or had committed to doing some pairing, and had the infrastructure for it like pairing stations. My current team doesn’t pair, every dev has their own snowflake laptop (mac or Windows, whatever IDE they want, directories organized however they like) and there are no pairing stations set up. And, I’m not actually ON the Engineering team and I’m remote! How would you encourage pairing or mobbing in this scenario, do you have any ideas?


At the moment, I’m finding it very easy to persuade the team to try run pairing and mobbing sessions. We have a couple of new members of the team with limited experience of the application. I’ve been able to persuade the team to try out mobbing/pair testing as part of a bug hunt, by selling it as a way to learn more about the application as well as find new bugs.

I fear this may become harder as they gain more experience.

How else might you encourage the team to try out pairing and mobbing?


How would you suggest conducting pairing/mobbing on testing teams which have a lot of friction? ie teams which don’t always get along.

Curious as to how that would work :slightly_smiling_face:


How would you keep someone who can’t seem to learn the rules (describing intent first and keystrokes when the driver gets stuck, not taking actions as a driver until the mob decides, etc.) integrated in the mob?

1 Like

Hi everyone, the Power Hour finally arrived! Thanks a lot to all of you who already asked some questions. This gave me a chance to prepare some answers already so I hope to answer any others that have come up. Now, let’s get it started! :slight_smile:

A very simple way to see it is this: Pairing is two people working together on the same thing at the same time, and mobbing involves at least one more person. Now, as this is a very simplistic view, let me elaborate a bit.

The first form of pairing I learned about was pair programming, which got generalized to pairing as programming was not the only activity to do together. There are many different ways how you can pair up: different setups, different collaboration styles, collocated or remotely, and so on.

The same applies to mobbing, which I came across in the form of mob programming which as of now is the most commonly known term in my experience. As this collaborative approach is not limited to programming but can also be applied to testing, code reviewing, creating presentations, anything - the generic version is often called mobbing.

This whole-team approach was initiated by Woody Zuill’s team back at Hunter Industries. According to him, it’s „All the brilliant people working on the same thing, at the same time, in the same space, and on the same computer”. There are some guiding rules and principles, yet things are not carved in stone. To paraphrase Woody, it’s all about finding your own way how to work well together in your context and turning up the good.

Now let’s talk about benefits. Here are the ones that I have witnessed myself.


  • Pairing is very useful for getting things done, including everything needed. You always have the other one keeping you focused and disciplined.
  • Pairing is a great way to combine your skills and knowledge and have both persons benefit from that. Especially when you pair in different constellations, knowledge will spread across the team.
  • Pairing will teach both of you on whatever you are doing. This is a bidirectional way of learning. Implicit knowledge becomes obvious.
  • Pairing generates more ideas, faster. Pairs can nicely complement each other, build upon each other’s ideas, hardly get stuck.
  • Having a pair makes you think. By pairing up you can include different thoughts and viewpoints. Diversity challenges our own understanding, and this way you can create a shared one.

A word of warning: Pairing can be great for learning, but for that to happen it has to feel safe. Pairing should not be there to enforce any power dynamics but rather to decrease them. More senior ones can help more junior ones grow, and at the same time learn a lot from them as well.

If you share your vulnerabilities or fears in the beginning of a pairing session, this can make it safer to do the same for your pair.


  • All points for pairing apply here as well! They are multiplied in a mob. And there are more, especially when the whole team is working together (which is usually the case).
  • In a mob, you have all brains in. I absolutely agree with the statement that you don’t get the most out of everybody, but their best. Perfect if you have tricky problems to solve, and also to get the best quality outcome.
  • The whole team has only one topic in progress, so no one has to switch context.
  • You don‘t have to wait for answers on your questions as you have all people available. You are nearly never blocked this way!
  • Everybody is instantly informed about everything. Decisions are made together in time; there’s no need for further feedback loops, follow-up tasks, asynchronous reviews, etc. Therefore, it’s also a great format for any other activities. My team already used it for writing a job offer, reviewing incoming applications, or designing a presentation for business.
  • There‘s no need for daily sync meetings as the whole team is synchronized all the time.
  • Working in a mob might be perceived as slower sometimes – however, slow allows for thoughtful thinking, and we can go quicker in the right direction, and align on conventions right when they arise.
  • The benefits from strong-style pairing are multiplied especially when it comes to implicit knowledge sharing as you instantly share it with the whole team. Perfect in all situations, whether you’re introducing new techniques or technologies, or getting day to day routine work done.
  • When you mob regularly, vacation replacement is no worry anymore.
  • Also, it’s perfect for onboarding new people in the team. They will quickly learn how things are done as of now, get immediate answers to their questions, get support on the first steps.
  • Compared to pairing, the mob is an even safer environment where power dynamics are mitigated better as the whole team is there to regulate.
  • Also, it‘s less intense than pairing, you can take personal breaks without stopping the work. You can also easily opt out for tackling some private tasks. Just rejoin the mob and get quickly up to date again. This is more introvert-friendly than pairing! When pairing you’re always on the spot, it’s more intense and when you take a break, you instantly pause the pair.
  • The mob provides a perfect environment for seniors to do what is in my opinion their biggest task: to increase the seniority of everyone else. The seniors learn how to express their thoughts and intention as easily comprehensible as possible, and the more junior ones can practice hands-on how to do things, by actually doing them. Invaluable.
  • Last but not least: My team grew a lot closer together due to mobbing. We learned how to communicate within the team better, to have synchronized coffee breaks together, in general to get to know each other better.

In short: It’s all about “turning up the good”. (Thanks, Woody, for that catchy phrase!)

1 Like

Pairing and mobbing are wonderful for that! Both inside the company as well as in our global community.

At work I made good experience with cross-team pairs in our internal testing community. We have all our testers embedded in cross-functional teams, so if one tester who knows the product and domain pairs with a tester from another team who brings a fresh perspective and a different approach to testing, then it’s beneficial for both and the product as well. @katrinaclokie wrote about her own experiences with cross-team pair testing. Besides that, I also tested a series of cross-team, cross-role, cross-location mobs for learning purpose inside the company which were super insightful for everyone involved.

When it comes to our global testing community, pairing and mobbing can be applied for learning as well. I facilitated mobs at meetups and conferences, as well as a power learning group I am part of. For any of my personal challenges, I used pairing to great success. For example, on my Testing Tour last year I paired with a whole bunch of other testers from our community with all of us learning a lot from each other. The great thing is that more people are on a Testing Tour these days, like @gemma.hill1987 (Testing Tour) and @punkmik (Testing tour 2019) - reach out to them to give it a try yourself!


I’ve only heard about swarming or swarm programming from Danijel Arsenovski in one of his talks. He also wrote about his experiences, pointing out both the similarities as well as the differences from his perspective.

Also, this question leads me to the language discussion. “Mobbing” does not necessarily have a nice connotation, it’s sometimes referred to as bullying. “Mob” itself doesn’t have a great one, either. The people I’ve discussed this with did not like the term “swarming” either. I’m not a native English speaker, yet so far I have not heard of a better term for the approach, and according to my knowledge “mob programming” happened to be the stickiest.


In my experience: nearly anything. Programming, testing, code review, creating presentations for stakeholders, user support, reviewing job candidates, writing emails - anything. I strongly believe we can all learn from each other and the outcome of working well together will be a lot better than when working solo, asynchronously.

Better done alone? Confidential work, of course. Sometimes bureaucracy work. That being said, we’ve also done travel expense reports in a more effective way together. Or scheduling meetings. I know several people who deem obvious and complicated work to be done alone a better use of your time and who like to reserve only complex topics as candidates for pairing and mobbing. Can you imagine, however, how much you can share and learn about programs like Outlook, increasing our effectiveness achieving what we want to achieve with these tools as well?

Hi Lisi, in your view would you say Mobbing is suited across different methodologies or styles of software development like Scrum, Kanban or even DevOps…or is there a specific methodology that mobbing is most suited to?

1 Like

Do you have remote access to developers? Remote pairing and mobbing is working well, too. Could you share the idea and ask them if they’d like to give it a try? You could frame it as an experiment with a desired outcome in mind, for example to build quality into the product earlier in the process, to improve shared understanding, anything. Just make it measurable so you can evaluate it in the end. If the experiment succeeded, awesome! If it didn’t, you all learned what did not work in your context. And maybe by doing so you come across another idea to try out next on your journey of finding out how to work better together. In the case of my product team we wanted to extend our toolbox of development approaches. Mobbing was an experiment that not everyone was convinced of, yet we all decided to give it a try for a few times and see for ourselves if it helped us. What would be lost? Now, if the first person or group is not willing to give it a try - why not find another one and try it with them to gain experience and learn.

In any case, I relate to this question. For a long time, I was scared of showing what I don’t know, that people see my weaknesses - and I feared that pairing or mobbing would expose them. In the end, however, I was too intrigued by the idea and was eager to try it - and only then discovered the benefits for me personally. There might be other people with similar or different fears.

Interestingly, mobbing was less threatening for my own team compared to pairing. As soon as we all discovered the benefits, we started to pair a lot more as well. Often, I hear pairing to be the step before mobbing, yet for us it happened the other way around. The mob provided the safe space we needed to pair up as well.

What helped me personally, was if my pair or people on the mob showed their vulnerabilities. Shared what they don’t know. This made it a lot safer and easier for me to do the same. Nowadays I try this myself by opening up first, trying to provide a safe space for the other one(s). It makes such a difference.

When facilitating pairs or mobs, I call out a safe space in advance, as we have to feel safe to learn with each other. It’s important how we treat each other. Kindness, consideration and respect are the often-shared ground rules for a mob (shout-out to Maaret Pyhäjärvi and her wonderful “Mob Programming Guidebook”!). Listening to each other. Building on each other’s ideas. Trying things out instead of instantly rejecting them. Sometimes making things explicit and setting expectations is all that’s needed.

An important point is that I did not force anyone into a pair or mob. If they are not willing to give it a real try, leave them out and only do it with the people who want to. Make it fun so they might want to join in next time, as I learned from Maaret as well. We also cannot force anyone to stay - they can join again any time if they choose to. Can’t force them into a collaboration style they don’t approve, either; like strong-style pairing, which is my personally preferred way yet not everyone else’s.

1 Like

If everyone has their own setup, I’d expect some resistance in the beginning when it comes to working on another computer. We had the same situation, including things like different operating system languages and keyboard layout. Different scrolling directions! All the things. At first people stumbled and complained, seeing it as a hindrance, felt uncomfortable struggling with the setup in front of everyone else. We tried to make clear that this is a learning opportunity for everyone and that we can take our time, it will get better. Yet what I assume did the trick in the end, was their eagerness to get things done. After a few rotations, the focus went towards the actual task at hand, and the details of how to use a computer that’s not their own were not that hindering anymore - they even learned new tricks when using different setups. We all got a lot more flexible by doing so. Yet again - for us it helped to first mob before pairing up, so everyone stumbled besides the one whose computer was used - and the next time we used a different one. Still, in the end, people have to be willing to give it a real try. Then the pieces will fall into their place, whether it’s working out or not.

Regarding the remote situation: It might be tough if the one who wants to encourage the team is remote. Could you do the first rounds with the team on-site, introduce them to pairing or mobbing? While still being temporarily collocated, you could agree on an experiment where the team pairs or mobs maybe once a week for a while. You could already provide them the tools to include you remotely so you can all practice while in the same room. Then, when you’re remote again, I assume it would be easier to encourage further as there’s already a team commitment to give it a try. If it’s not the whole team from the start, maybe a few of them are still willing to give it a try. Also, for remote pairing or mobbing I found it most effective if the remote people were also able to work on the same computer, which means not only the screen is shared but also the control. This way you can take part as anyone else, not only navigate or observe.

Now lastly, you said you’re not actually on the team yourself. Could you still join the first few sessions, either as facilitator or even as a regular mob member? To help them kick-start their journey as part of the experiment? I’d assume you can fade out after a few sessions, yet in the beginning it would require more attendance and someone who drives it further until people realize the benefits on their own.

Of course, it all requires to find the first few people (if not the whole team) who agree to give it a try. I’d love to hear your experiences in this situation so far, what did you try, what worked and what not?

1 Like

What about “let’s continuously learn about our product as we develop it further”? Implementation and behavior change all the time. Even if they don’t, why not try out new approaches to learn more or to discover new issues? You could try out new tools together, use a new heuristic when exploring, experiment with a new approach regarding automation, dig deeper into underlying infrastructure or the product’s ecosystem, gain a deeper understanding by developing a feature yourself, anything. Every time I paired, I either learned something new or could share something with my pair that they were not aware of; no matter if we had paired only once before or many times already.

If the learning factor is not convincing enough, maybe better quality or optimized flow still is. As described in a previous answer, you could frame this as an experiment for the whole team, targeted on what you want to improve.

1 Like