Ask Me Anything: Collaboration, Pairing and Mobbing

Tonight we had the wonderful @lisihocke join us for our final webinar of 2019, an Ask Me Anything session all about Collaboration, Pairing and Mobbing.

As always, I’ll share the resources below that I was able to catch on the night. If I missed a resource or you have another question you’d like to ask, please share it on this thread.

If you missed the live session, a recording will be available on the Ministry of Testing website


Resources Mentioned

Of course Lisi’s TestBash talks came up

And naturally, the teams first mobbing session

If you want to do your own pairing tour check out Lisi’s blog for ideas of what you could do

Lisi’s first pairing tour with Maaret came up during the AMA, you can read more about that here

Woody Zuills recent talk about mobbing and the power of flow was also referenced

@maaret spoke at TestBash Philadelphia about mobbing which also came up during the session, you can watch that here

Unanswered Questions

  1. When is it a good idea to swap from a pair session to a mob?
  2. How should mob programming be timeboxed?
  3. What are some ways to incorporate Quality Assurance team members into pairing and mobbing?
  4. Many of your talks focus on goal setting and making a commitment to achieve those goals. What advice do you have for testers whose goal for 2020 is to collaborate with others?
  5. If you write a lot of code but are also kind of a consultant to the rest of the team, how can you balance those tasks without lacking/losing focus?
  6. You have a unique mob programming technique to learning something no one knows in a mob. Can you tell how that works in practice for you as a facilitator?
  7. I saw your Testbash Lessons of a Testing Traveler - it was amazing so really excited about this one! How do you deal with a pair partner that is negative?
  8. How could we highlight values of mob/pair programming when sprint goals might seem to be at risk?
  9. Context : We are agile and using a continious development, continious testing - How do you find a balance from a day/sprint task prespective between sharing testing task in a team(includes developer, Product owner) and even approach to learn and become strong at coding using pairing /mobbing inside the team.
  10. How do you measure the productivity of pairing/mobbing compared to traditional techniques, how can you sell these to the project management? Whats the best way to implement this in an agile team?
  11. Thanks heaps MoT for organising events like this. Would be keen to know how to initiate a formal process for collaboration a project as Quality Analyst ( normally the Business Analysts or product owners ) drive the requirement gathering and communication with the business. Thanks !
  12. My team have discussed booking a room for pair working to reduce distractions and get the most value from the test session. Do you think it’s important to pair work away from your desk?
  13. Last week I joined a software craftsmanship meetup about schools of TDD: I really enjoyed the mobbing on katas with developers and learned a lot in a short time in the mob and was surprised how fast are all speeding up… Did you practice TDD with Katas and may share your experiences?

Regarding remote mobbing, here’s the podcast I mentioned (unfortunately in German): The good news: they’ve just released an ebook about the topic - in English. :wink: I haven’t read it yet, but here it is:

Also, I’ve done a Power Hour on the same topic earlier this year, check it out for more questions and answers:

1 Like

It’s a good idea if…

  • you are getting blocked, e.g. by an open question you cannot answer yourself, or by lack of knowledge or expertise in a certain area --> get the person(s) that can help unblock you on the mob (I’d hope they stay ;))
  • you are learning something right now that everyone should know, so better get them on board right away
  • you are uncertain which way to choose, e.g. when it comes to architectural decisions
  • you have the openness and trust in the team to give the mob a try, maybe even full-time :slight_smile:

These are just the first things that came into my mind, I bet there are a lot more reasons.

1 Like

Should it be timeboxed? :slight_smile: I didn’t have the chance yet but would love to be on a team that mobs full-time and learn the benefits. One of our product teams at my company is currently experimenting with it and I’m very eager to learn from their experience and lessons.

If you feel you need to timebox, for example when going your first steps, I recommend to do a 1.5-2 hour session, afterwards energy is likely to drop. Rather have it end happy and do a short retrospective in the end to reflect how to turn up the good the next time. Then rinse and repeat and find out what works best for you in your context. :slight_smile:

1 Like

Mobbing is generally about the whole team working on the same thing, so just using the definition might be the easiest way to get everyone on the team working together. If people think in separate roles here (“this is not for them”), I’d talk with them and see what are their reasons to think that way. In general I would explicitly invite everyone on the team to a mob. Phrase it as experiment for the team to solve a challenge they face; this could be slow feedback, lots of back and forth between developers and testers, lack of quality, lots of rework or technical debt, lots of issues on production, you name it. Basically anything related to quality can be an argument to give this experiment a try. The same with pairing across roles. Here’s a great guide from Lisa Crispin: As always: start with activities or topics people are most comfortable with and make it a safe place to learn together.

1 Like

My advice would be to phrase your challenge as an experiment. A clear hypothesis of what you want to do and what outcome you think this has, and how you want to test it. If your goal is to improve your collaboration skills (which would be an awesome goal!), then I’d say do just that :slight_smile: Get yourself into situations where you can practice your skills hands-on. Like asking around in your company and/or our community who would like to pair or mob with you, also remotely it’s really working well. Ask nicely, explain your context and what you would like to try - and I bet there are many people who would jump at that offer and learn together with you!

1 Like

This is my everyday challenge! :slight_smile: Not only regarding writing code, yet with anything. Besides working hands-on in my own product team, I am working on a global level as well which is expected from my seniority level. There’s a social aspect to it: It’s my second year in this position. The first year might have been seen as “temporary” situation, yet in my second year it clearly showed: I failed to communicate this challenge as well as the expectations and needs that come with it well in my team. So it became a social challenge as well. We found transparency was suddenly too low and we all made various assumptions without being explicit about them, not asking for or providing feedback in time. In hindsight it does not surprise me that during this time I had spent a lot less time on pairing or mobbing sessions in the team. Only quite late we finally sat together and brought everything to the table, enabling us to find a new working agreement and fresh start.

Losing focus is easy, especially in case you’re opening too many topics at the same time and trying to work on all of them at the same time. Then things quickly feel overwhelming and I feel like I cannot get anything done right. To force myself into focus again, I limited myself to 3 main areas where I will contribute; everything I do should pay into these buckets. I ask myself every week and every day: “How to provide the most value?”, note these points down, and then focus on them. This is not always working out but working a lot better than before.

When it comes to pairing and mobbing: well, both approaches really help increase my focus. They help me get the important things done while also sharing my knowledge with my pair or mob partners to enable them to get there themselves when I’m not around. I would prefer working this style all the time - so if I need to write a lot of code, let’s do it together, knowledge can be shared at the same time :slight_smile:

1 Like

That’s right, I do give a mob workshop called “Learning to Learn in a Mob”. The idea is to answer the following questions: What if you introduce a new technology no one in the mob had worked with before? What if you suddenly need knowledge in the team that nobody has? Does mobbing still prove to be an efficient way of learning in that case?

We had this very situation in my team two years ago. The one person that had set up our whole infrastructure left the company, and we had the huge task of moving everything to Kubernetes and AWS. No one knew how to do it, and we wanted to avoid such a bottleneck again, so we did it together as a mob.

The mob session that evolved from my personal experience is an experiment by nature, and with each group results might differ. The underlying hypothesis is the following:

“We believe that learning ____________ as a mob will result in valuable hands-on knowledge within a short time.
We’ll know we have succeeded when we have noted down ____ new insights within ____min of mobbing.”

To fill in the blanks, we first collect topics that people wanted to learn about yet never did. We filter out any topic where someone on the mob already has experience or knowledge, then the mob votes on their chosen topic. Then I ask them to guesstimate how many insights they will have within the time we have for mobbing.

While the mob is working on their chosen challenge, they gather any insight anyone has in the group on a board. After the agreed time is over we debrief their findings and do a short retro how things went.

As facilitator it’s amazing to observe the mob. Usually people need a bit of support to get things going, as people either never worked on a mob before or at least not in that constellation. Also usually, I can retreat to the back of the room quickly, ready to help them further in case needed. I use this time to take notes of my own observations, and the insights people have and even express yet might not realize themselves. It’s amazing to hear all the “oohs” and “aahs”, to see them frown, lean forward or back, to observe the evolving mob dynamic, and in well-working constellations see energy and laughter filling the room.

I have to say, it’s one of my most favorite mob sessions to facilitate! And I’m always learning so much myself.

First of all: thank you! :blush:

I would start with learning why they are negative, finding out the reasons for their negativity. It might not be related to me as a person, or pairing, or anything I might imagine. This would give me something to work with, to create a foundation. I would not, however, force anyone into pairing who’s really rejecting giving it a try. I’d rather focus on people who are open for it and then make it really effective and fun so the other person might get convinced to give it a try themselves. Learned that one from @maaret! :slight_smile:

One of the most important values of pairing or mobbing from my perspective is effectivity. Therefore, if sprint goals are at risk - I would even advocate more for these synchronous collaborative approaches. It’s a great way to get things really done, not only handed over to another person, waiting for their feedback, and moving things back and forth until we finally went in the right direction and have it really done. These approaches also support the principle of “stop starting, start finishing”. Opening too many parallel threads and potentially not delivering any value in the end sounds a lot more risky to me than limiting work in progress and finishing things one by one.

Finding a working balance is a challenge, and I assume it’s a common one for many teams. My best answer so far is that pairing and mobbing actively helps finding that balance, as we can combine everything then: while getting things done we are all learning from and with each other. If we mob on all activities that’s the easiest case as everything is covered for everyone. If we pair, I found it most valuable to pair in different constellations and on different activities to get the best mixture of knowledge and hands-on experience, spread across the team.

How do you measure the productivity of working solo? How can you sell not having all brains in on a problem and cope with the resulting lower quality, higher risk, and potential knowledge silos? :slight_smile: I learned asking these questions from Woody Zuill. I would recommend to watch his talk “Mob Programming and the Power of Flow”; Heather linked a version of it already above, here it is again.

The best way to implement this in a team depends on the team’s context - therefore the crux of the matter is, you can’t tell which way is best before you’ve tried it out. :wink: Therefore I would suggest to frame it as an experiment. People need to experience this approach hands-on themselves before they really realize its benefits. Then have them inspect and adapt things to their context. Woody shares that it’s all about working well together and “turning up the good”.

First, I would ask myself: why is formality needed? Where and how would it help? Where is that need coming from? Maybe there are more creative ways to fulfill the underlying need.

Why do you want a specific role to drive requirement gathering? Why can’t these be all kind of people, helping together? No matter our roles, I’d sit together with business people and learn about what drives business, what is important for them. Have open conversations, focusing on learning together and building up a relationship.

Regarding the activity of gathering requirements itself: I’d refrain from going too detailed too fast when we don’t have the information we need. I’d rather go in small steps, test my ideas early, learn from the results, and make my next decisions based on them. Practice hypothesis-driven development. Explore and learn more as you go and decide just enough to go further.

I think this heavily depends on your context. I suggest to run a few small experiments and find out what’s working best for your team. In my team we found out that booking meeting rooms was rather counter-productive; they are hard to get at my company and we were bound to these times then. It felt way too formal and it would have hindered us from mobbing or pairing at all. My team wanted a more natural way of having pairing and mobbing sessions whenever they evolved. Therefore we put a big screen in our room and left some space in front of it, so we could all come together and mob there. When it comes to pairing, we simply do it at one of our desks. Keeping things as easy and convenient as possible helped us a lot. Noise or distractions were never our concern. With a mob it’s no problem by nature, and in pairs it often proved helpful to be able to overhear another pair so we were able to learn about important information in real time and even jump into conversations. Other teams probably have different needs, so I’d say experiment to see what fulfills those needs best so you get the most out it! :slight_smile:

Great to hear you made such good experiences and learned a lot! So far I don’t have as much practice with TDD as I would like to have. I tried it at a meetup and a conference, I tried it together with a pair, I tried it myself. All on katas. Given this very limited experience, I love how TDD helps me to think of the next step to achieve, the next piece to implement and have instant feedback if it really does what I intended it to do. It’s amazing to go baby steps and evolve the design according to what is actually needed. I’d love to run a TDD experiment also at work, yet so far I’m lacking this kind of experience.

Phew! Happy that all questions I couldn’t answer live in the AMA session are answered now. In case you have further questions, feel free to reach out to me here or via Twitter, my DMs are open.

Final words regarding collaboration, pairing and mobbing: Give it a try, and then share what you learned! :slight_smile: