Experiences on Mob Testing

Mob testing is a specific form of group testing where testing is done so that the group shares the input computers. I wrote an article on this for the Testing Planet and thought people might have questions, comment and own things to share after reading it. So this would be a good place to have that discussion.

The article: https://dojo.ministryoftesting.com/lessons/mob-testing-an-introduction-experience-report

Q1 received by email: How do Introverts survive in mobs? This sounds terrifying. “I’m an introvert and need quiet and focus to get in the zone and having to do something like this regularly would be incredibly draining.”

Q2 received by email: what about contracting environment? The customers would never pay for the whole team to work on a single thing. “In a consulting environment, where people are not necessarily invested in the team as a whole and are compensated per hour worked on the project rather than on growth value, do you even see a chance of a practice such as mobbing to take hold? Unless you get a team exceptionally motivated to learn new methods AND comfortable with working this way, or maybe an environment particularly suited to this sort of cooperation (a lot to learn for everyone or almost everyone on the team), I don’t believe either the developers or the management would pounce on this method.”

Q1 reply:
There’s a very nice article on mobbing for introverts that might answer some of your question by an introvert, Aaron Griffin who has now years of experience showing up into a mob on a daily basis. My discussions with him has lead me to realize that while it can be really draining at first, there’s a significant upside. Introverts often feel their ideas don’t get heard, and a considerate established mob can turn that experience around. Also, stepping out of rotation and reflecting, and even stepping out completely when you feel you need to recharge is encouraged. The work does not stop for one person leaving the mob. But Aaron has a lot more to say: https://www.agilealliance.org/resources/experience-reports/mob-programming-for-the-introverted/

Q2 reply
I work with teams in a product company, and in my current place of work getting people to mob (even pair) is extremely difficult. There’s strong ideas of how they learn best and that involving others in any way isn’t their thing. Forcing people isn’t my thing. But some groups volunteer to try things out, usually the ones that are no so established, over team limits. We have tens of teams here, and I work directly with many.

I’ve seen mobbing in use in contracting environments too, but for learning often it requires the idea of “we don’t invoice for these hours”. Some teams do their contracting work in a mob, with enlightened customers willing to pay as they see the deliveries being faster and more to the point. The main obstacle is always people. Not just customers and managers, but also the developers and testers. They “know” this won’t work without ever trying it and surely it does not work when you don’t do it.

I’m getting better at convincing managers. Developers still give me hard time. So I use other developers who have stuff to teach as my minions in taking this forward. For example, Llewellyn Falco is a developer who commands a lot of respect from other developers. Bringing him in to mob with us makes people show up to learn from him.

I have also a side job of consulting, although I do that very little. I do most of my teaching nowadays in mob format. So I show up at companies doing a two hour session with them. When we test together and they find problems on their own applications they were completely blind to, it changes things. I spent a day mobbing with a team I was considering joining (I did not - decided that they had much to learn from me and I had less to gain with that choice at that time) and we broke their “working” system in ways they never thought, and I could do this with them on day 1 without ever having seen or used their application (energy invoicing) before.

So, just get some group together and test together. Talk about what you learned and what you contributed. Celebrate both to enforce trying again.

1 Like

What would you suggest for trying to encourage mobbing in the workplace, when they are reluctant to even pair up, and wouldn’t mobbing as a means to get the best out of a group of people, but taking up everyone’s time when normally only one or two people would have done it?

I love the idea and have read your leanpub book, but work in an environment which is reluctant to try new things, and prefers to do what they have tried before. Success with anything new is seen as an anomaly, and failures merely prove that they were right.

I have tried many things, having an environment with reluctance.

  1. I find smaller group, have fun, learn a lot and encourage us all to share. “We’re having a party you did not join but are welcome to”
  2. I build group with half externals. When we think we don’t have anything to learn from each other, we still believe people in other companies can teach us stuff. Meetups are magic.
  3. I convince a manager and have them join, people join when manager will see they did not join and show interest in learning.
  4. I introduce things to mob on that are interesting. Like right now, I finally got a good group together to learn Python3 language essential by mobbing on Koans (little unit test puzzles).
  5. I share messages I get as DMs on people outside the company being more successful than we are
  6. I extend a personal request for them to invest in my learning by participating. They like me, they like making me happy (worked well in previous place of work, not so much here)
  7. I drag in an external facilitator that is a programmer of respect and people want to hang with.
  8. On my experiences mobbing with colleagues, I share stories of insights. Like how 3 developers who couldn’t get a programming thing done thought they would individually have done it faster. Or like how we within a day introduced performance testing we did not have, and got loads of blockers fixed by extending the mob with people from other teams having the problems blocking us.
1 Like

I really like the idea of mob testing and I would definitely give it a go.

How does the business see this from a resource perspective if 3 or 4 team members are working on a single body of work for 2-3 hours. Depending on team members but that could be $2500 + in billable hours. Did you find the Mob Testing findings resulted in the business saving more than the initial investment of the teams billable hours?

I have not learned to log on to this platform, and now that I did, I realize I left you waiting for quite a while.

I hear the cost aspect a lot. But it costs a lot to keep people working individually and not learning and collaborating too. I find that sometimes with mobs the thing we think takes a lot of time becomes minimal with the right brains working together.

At my previous place of work, two of our best developers made estimates of a new feature we were asked to deliver. They said it would take them three months to implement. So, a day of mobbing with the whole team of 9 people was nothing compared to it. We spent 2 hours with the whole team, 2 more hours with half of the team. This was on a Thursday, and we did mobbing only for learning purposes. The feature was ready on Monday afternoon. The business folks thought we had lied about how big of an effort it was. But we had not. We were careful with estimates, obviously. But we also did not realize how much technical assets (ready code we could use) we would find when we had the whole team working on it. Nor did we realize how the quality could be in place from getting started when the tester would also be in the mob.

I think personally that in this industry, we cannot afford not to pay for learning. I often speak of the idea that if we would get 1% better every day by investing 1 hour into learning, the cumulative nature of learning would make us outperform our past self in 28 days. Comparing ourselves today and in a year with the same 1% better every day, we could use as much as 6/8 working hours on learning to be on par with ourselves in a year.

Long story short: it is about the work going smaller with smart minds collaborating, and us getting better through learning that makes it worthwhile.

That sounds amazing… was there scope change during that process from what your 2 original devs estimated to what the entire team of 9 delivered?

Not really sure what you mean by mobbing for learning purposes possibly its similar to grooming as a team where there is knowledge transfer for everyone. This is so everyone knows what is happening and dependant on skill set (the devs may need to pair) anyone can pick up the work. With testing all AC are written up with any additional information ie environment set up, accounts etc. Is that what happened during the sessions?

Agree with the learning anyone who actually wants to stay in this game needs to personally invest in up or cross skill their own professional development and not hang around hoping their company might pay for it.

The rule (that is currently being challenged within certain fields but I feel still applies to tech today) is 10,000 hours of deliberate practice is needed to master a skill.

Maaret you may possibly hear my groaning now into my first few double digit hours of learning Ruby :wink:

There was no scope change. I love this quote: “Features don’t creep, understanding grows”. And in this case, growing understanding of what we could reuse because we found it having everyone in the mob was really really valuable.

With mobbing for learning purposes, I mean doing activities that are not really trying to take day to day work forward but place solely the idea of mobbing on “let’s learn together”. It could be exercises that illustrate techniques, or it could be working on some of your own work stuff together but emphasizing just learning over being productive.

With grooming (story refinement as I insist on calling it), we talk about stuff. With mobbing, we do that stuff. And work unfolds differently in doing than talking. Then again, where I’m at we don’t do ACs. So that did not happen during the sessions.

I hope your learning Ruby has moved fro groaning to joy and groaning. :slight_smile:

good points and really interesting what your team is doing.

yes its turned to joy and groaning… actually more fascination with curiosity being filled + groaning. I never thought I would be doing this :thinking:

you really caught my interest when you wrote… “where I’m at we don’t do ACs.” now that Maaret is a conversation definitely worth having