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
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
Regarding remote mobbing, hereās the podcast I mentioned (unfortunately in German): https://www.innoq.com/de/podcast/061-remote-mob-programming/ The good news: theyāve just released an ebook about the topic - in English. 
I havenāt read it yet, but here it is: https://www.innoq.com/de/podcast/061-remote-mob-programming/
Also, Iāve done a Power Hour on the same topic earlier this year, check it out for more questions and answers: https://club.ministryoftesting.com/t/power-hour-pairing-mobbing
Itās a good idea ifā¦
These are just the first things that came into my mind, I bet there are a lot more reasons.
Should it be timeboxed? 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.
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: https://www.ministryoftesting.com/dojo/lessons/pairing-with-developers-a-guide-for-testers As always: start with activities or topics people are most comfortable with and make it a safe place to learn together.
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 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!
This is my everyday challenge! 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
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! 
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!
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? 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. 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!
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!