Interesting situation! I think it would be good to find out what causes friction in the first place so the root cause can be tackled. Still, sometimes we have to work with what we have. In that situation I’d look for allies, those people who are open to give pairing or mobbing a try in a smaller scope. The whole team could still be invited, yet as stated in a previous answer, they cannot be forced. So why not start small and gain experience? I’d go with Maaret’s advice here again: do it openly in front of everyone and make it fun and insightful so others might want to join in next time. If it turns out valuable for people, they will promote the approach themselves.
Normally I’ve seen this kind of behavior getting regulated by the mob rather sooner than later with people calling it out and gently reminding each other until they get it. However, there are some people who seem either not to notice, or not to care. What can help here is to do a regular short retrospective after each mob session where people can share what went well and address what could be improved. If that doesn’t improve the situation, I’d share the observed behavior and resulting impact with the person separately from the mob in a one on one situation. It’s key that they understand why these guidelines exist, what purpose they serve. Then it’s up to them to decide if they want to change their own behavior. If they really don’t want to - well, might be that we would continue the mob without that person then. Might also be that the mob is perfectly fine with it and still finds it valuable. Yet again: people need to feel safe, so in the latter case it’s important to find out if really everyone is really fine. It’s all about finding out how to work well together and then turning up the good.
In my opinion the mob approach is not limited to certain methodologies or styles of development. I could also imagine it to be valuable in a waterfall-ish environment as people would still learn from each other a lot. I would, however, expect the benefits to be reduced in this case as you might not have all knowledge and skills you need available at the same time to answer your questions or to have great questions asked just in time.
I think mobbing is a great fit if done within a learning organization, or a team that’s eager to get better, or any environment that encourages and fosters continuous learning and improvement.
We’ve reached the end of the Power Hour! So I’ll take this chance and cross-post a question of an old friend of mine here. She asked on Twitter: “What was your greatest learning? Can you share 1 Success & 1failure story?”
Let me answer this the other way around.
My failure story: I really like using the mob format as a teaching tool these days. Not too long ago, I gave a workshop for a few people including an exercise done in a mob, and this time everything went wrong. Bad behaviors surfaced. It was not a safe space at all. The topic I wanted to convey was not understood. People ignored me as facilitator. That was a super tough situation for everyone involved and it did not help my mission. I don’t know yet what I will try when I encounter such a situation again, yet I know I will definitely try something differently.
My success story for mobbing: My team had agreed to try out mobbing a few times. They were not convinced yet thought “why not”. Then we did it again. And another time. Then more often. And suddenly we mobbed nearly on the whole big epic of moving our complete infrastructure to AWS and Kubernetes. A topic none of us have had much experience with before! This worked amazingly well and the knowledge was instantly spread across the team.
A bonus success story for pairing: Well, I’d say that’s my Testing Tour of last year!
My greatest learning so far was twofold! First, you need to try things out in your context to know whether they do work in your context or not. And second, I thought that I’d be on the learning side when pairing or mobbing, and then found to my positive surprise I could be on the contributing side at the same time. We can all learn so much from each other, no matter our roles, titles, backgrounds, expertise levels, anything - if we consider these situations as learning opportunities.
Speaking of resources: there’s a lot out there about pairing and mobbing. I also wrote about my experiences on my blog and shared them in the Test Automation University course “The Whole Team Approach to Continuous Testing”. In case you want to learn what others have experienced and how they see these collaborative approaches, here are some resources that I personally found really valuable.
- Styles of Pair Testing
- Llewellyn’s strong-style pairing
- The Driver-Navigator in Strong-Style Pairing
- Pairing With Developers: A Guide For Testers
- Pair Programming Pointers
- EP 61: It Takes Two
- Styles of Pair Testing
- Leveling up as a Pair
- Mob Programming Guidebook
- 4 years of constant mob programming
- Mob Testing: An Introduction & Experience Report
- 100% of the team in a mob for 12 months — taking mob programming a couple of steps further.
- The Surprisingly Inclusive Benefits of Mob Programming
- Mob Programming for the Introverted
- Practices for Effective Mob Programming
- When knowledge is the limiting factor
- A Few Tips for Mob Programming
- Programming, Fast and Slow
- Effective Mob Programming Patterns
- Mob Programming - Whole Team Collaboration - PhillyXP
- Increasing Quality Skills and Collaboration Through Mob Programming-The Clearlink Experience
- Kanban and Mob Programming in Action | Business Agility Series
… and with that I’m officially closing the Power Hour! Thanks so much everyone for your questions, hope I could trigger some thoughts. For today, I’m going to leave you with the following: when in doubt, give it a try yourself and make your own experiences; and if not in doubt, do it anyway! Thanks everyone and have a great rest of the day!
Interesting, as when trying to sell the idea to technical and non-technical, mob programming was off-putting to the non-technical people as they would say they can’t do programming.
But once I just called it mobbing, and dropped the programming, it was appealing to more people.
Hmm, so this is something that is kinda working for us. Though this sounds fundamental and trivial, it’s shame that a lot of QAs (including me) have failed to adhere to this practice in the past for various reasons. It is interesting to see how such process/ mindset shift can influence quality of the software delivered (positively) to a great extent. https://qakumar.wordpress.com/2019/09/11/benefits-of-qa-pairing-with-developers-devops-engineers/