On my latest stop on my testing tour I had the pleasure of pairing up with Simon Berner on the topic of pairing and mobbing.
We only had contact via Twitter before. It's always a great experience to put a real face to this sort of virtual connection and have a meaningful conversation with them.Wonderful pairing session with @alientester today! We went on a meta level and exchanged insights and experience on #PairTesting & #MobTesting, evolving a mind map together. My #TestingTour let me learn on so many levels already. Thank you Simon for joining me!— Elisabeth Hocke (@lisihocke) August 24, 2018
Going on a Meta Level
Simon put a lot of thought into our session already in advance and proposed our topic as follows.Hi Lisi
There are so many great things out there that I would like to discuss and explore with you, but so little time. I have something specific in mind where I know little about yet: to Mob. As you seem to have quite some experience around this topic, I would love to pair up with you on the topic of “to Mob” and elaborate a bit on it, if you are up for it. What are our experiences with MobTesting and MobProgramming in general? What are its benefits? When can it be applied best, when not? Are there different forms of it? Can a whole Sprint-Iteration completely be developed in a Mob? How can you introduce “to Mob” to a team who knows nothing about it? How do we learn best from its outcomes? … and many more interesting questions to discuss.
My intention in this session with you is, to create a MindMap where we both can share ideas/experiences and grow up on it (maybe me a bit more than you as you seem to be already a pro on it)
I’ll create a MindMap in advance with some of my ideas around the topic, so that we can get started on them.
Hope that sounds interesting to you
CheersIf that sounds interesting to me? Indeed it does a lot! Our session could only last that long, but I'd love to continue the conversations around it.
Simon
Now, originally my goal for the testing tour was to practice testing hands-on. I read and talked a lot, but felt I didn't practice or try out new approaches and tools enough. In this sense, this pairing session was a bit different, as we had a paired conversation around a certain topic. Still I was eager to give it a try, betting there's much to learn out of it as well.
Evolving a Pairing and Mobbing Mind Map
As promised, Simon already prepared a mind map. And it was huge! It contained most of the things already, so it was great to get our discussion started, elaborate on certain points and develop it further. As words cannot express what mind maps can, let's start at the end and show you our end result. I decided not to edit it after we stopped, so this is exactly as we left it. The original file which allows to follow the links can be found here: TestingTour_2018#17_Pairing&Mobbing.xmind.
I really enjoyed that Simon thought of including an "introduction" node for us to get going. After all, we didn't know each other and this made it easier to start and learn one or two interesting bits about each other. This way, I got to know that he just started in a new team with huge potential where he's the only one to drive things forward regarding testing and collaboration. Simon already pairs with his teammates and now got intrigued to try the mob approach as well.
We talked a lot about styles of pairing and what comes with them. We both enjoy and prefer strong-style pairing the most. When it comes to explaining this form, I normally shared this blog post by Llewellyn Falco: Llewellyn’s strong-style pairing. Great to see Simon had it already in his mind map. And he also had the following post by Maaret Pyhäjärvi right next to it: Being a navigator in Strong-style Pairing. I really enjoyed reading it afterwards, as well as her previous posts in this mini-series The pairing experience: foundations and Being a Driver in Strong-Style pairing. (Update: Maaret just compile an article from her notes on strong-style pairing: The Driver-Navigator in Strong-Style Pairing; my new favorite post to share.)
Simon shared that when it comes to understanding the roles of driver and navigator in strong-style pairing, the metaphor of the rally driver and navigator was enlightening to him. When driving a rally, the driver has no time to read the map or think about what else to consider, they are fully occupied with getting them there. It's up to the navigator to take care of directions and instructions and thinking ahead. This metaphor was flipping the switch for him.
Another interesting point Simon made was that "listening is an art". I so much agree! Especially when he shared his observation when meeting people. He's interested in people and the one asking questions about the others. People have a tendency, however, to tell you about their lives and then not ask in return to learn who you are. I made this observation myself so many times as well. However, I also fell into the trap of the other side so many times already, being guilty of not asking back myself. Best example was when I was speaking at a conference and someone approached me asking questions, I was really happy I could talk about things I love for once and not only listen to others, so that I often forgot to ask back. Another factor here is that exhaustion makes it worse as Simon added. When I'm tired, I fall back into my worse habits and less social behavior.
Another interesting discussion point was what to do when you see that people are falling back into a traditional style of pairing, having the navigator take over control of the keyboard again. We both experienced these kind of situations already which can be tricky to solve. I realized that I personally grew with experience, so when I am the driver, I won't allow my navigator to take over. It's really hard for me, however, to be on a mob and watch the driver freely handing over full control to the navigator. I normally intervene, referring to the learning aspect for both. Sometimes this is helping people find back on track, sometimes my voice is not heard. Now, the worst thing is if I'm myself the navigator (maybe also tired) and have to actively stop myself and refrain from taking over. At least it's fully in my hands to stop it then.
When focusing on mobbing, we quickly came to the question how to introduce it to a team and tackle the likely question regarding productivity. I referred to a great keynote by Woody Zuill at the Mob Programming Conference 2018: "Mob Programming and the Power of Flow". Unfortunately this talk cannot be found online, however you can find my notes about it in my blog post about the conference, and Woody's webinar Enhancing Team Effectiveness with Mob Programming seems to be sharing about the same content.
In a mob, it's important how we treat each other. Kindness, consideration and respect are the often-shared ground rules for a mob. Simon and I felt "kindness" is kind of straightforward, and "respect" understandable as well; "consideration", however, is not as easily graspable. I admitted I had to look this one up the most often before explaining it to a new mob. I explained it with being aware of the others and their context and considering that everyone's doing everything to the best of their knowledge. And instantly admitted I would love to look it up again right then to see if that's correct. Now that I have written this down in this blog post, I really went back to the Mob Programming Guidebook and looked it up. And found that once again I indeed mixed "consideration" up with "respect"!
"Consideration is really about listening. [...] The place it is going to show up the most is at the driver seat. Often the driver will start by not listening to the navigator. [...] Another way that this will manifest itself is that good ideas will be spoken by members of the mob and will be totally ignored. [...] As a facilitator, it is your job to call attention to those ideas and make sure that everyone gets heard. Over time the mob will learn the habits of listening to everyone and people will find their spots to contribute. [...] Another aspect of consideration is to remember to allow other people to shine. [...]
[Respect:] We always assume that the person who wrote the code before us did the best they could with the knowledge and circumstances they were in at the time they wrote it. [...] We want to create a space that is safe."
(Maaret Pyhäjärvi & Llewellyn Falco: "Mob Programming Guidebook" version 2018-03-24, chapter "Working in You First Mob", section "The Rules for Working with Each Other")
The next interesting topic was the size a mob should have and when it stops working due to the number of people involved. I learned that three persons already form a mob, however, if one leaves the mob for a break you are back in a pair. Therefore, a minimal size of four people is working out really nicely. When it comes to the maximal size, the general idea that I picked up was that the size of a mob is still right when everyone's either learning or contributing. If you have a normal-sized agile team it's perfect. I heard from two team mobs temporarily joining forces in a bigger mob, or from people trying a mob with a full meetup group. So far I still made good experience with a mob of ten people myself.
We were running out of time and still had many more topics on the mind map. So I asked Simon what would be the last most valuable topic he'd love to have input on before trying to mob with his team himself. Simon wanted to learn about the "don'ts" in a mob. Two points came to my mind instantly.
- Don't force anyone into the 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. In my team's case, the two most skeptical persons who did not want to be on our mob either changed team or the company soon after, so I cannot tell from experience how it might have evolved with them. Still, we cannot force people, only convince them.
- Don't force anyone to stay in the mob. Besides from the very first mob sessions, we made very good experience with allowing people to take any break they need and temporarily retreat from the mob. These can be as simple as toilet breaks or getting some water, with them being back on the mob very quickly. These can be meetings that just happen to take place at the same time, like a one to one with our manager or an interview. These also can be times people need to fall back to solo working mode and tackle other tasks they have. With this rule we made it easy for everyone to opt in and out, and the result was we were even longer together in the mob. Just the freedom was needed. And the coffee breaks? Since then we nearly always do them together, staying synchronized, and having that extra bit of socializing that helps so much when working together.
Retrospective Time
Simon shared it was a wonderful experience for him, joining me on my testing tour. He was nervous in the beginning as we didn't know each other (just like me always!), but it turned out to be a cool session. He also got a lot of information and value out of the session, which I loved to hear. He didn't think we should have improved anything in our session, as a lot depends on the energy flowing between two persons and ours was great.
I really enjoyed our discussion and the additional food for thought when it comes to pairing and mobbing. The preparation work Simon had put in already in advance was simply awesome! So much more to dive deeper into, lots of resources new to me. It was really interesting to try strong-style pairing on such a meta level topic, evolving the mind map with our results together. Because this is what we did! We used a timer and switched roles, however, for this kind of a topic it was quite hard to do and we often lost discipline. Still, both of us could contribute and learn. Simon made a good point here: it's the natural flow that matters, we don't have to force people into a box. It was as if we would have done it before.
All in all, it was once again a pleasure to pair up with great people of our wonderful community. There's so much to learn from them, to give back, and to discover new insights together.