With a group of people working together on Mob Programming, there must be moments where more than one person has ideas of what would be the Right Thing to do.
With Mob Testing, I see these as ideas of where the bugs might be hidden. In training setting, I often stop people from following the ideas to keep the group together, and just park ideas actively in the mind map for future - that in training often never comes.
The rule of thumb on mobbing would be to approach competing ideas of solutions with the "do both" approach. At Mob Programming Conference this week, I had just the right opportunity to live by this rule.
In the open spaces, we were trying out mob writing an article. We were trying to describe mobbing for the inexperienced through describing the mobbing we were doing right now, and the line of thought from people who do not mob lead me to an idea of needing a metaphor.
My choice of metaphor and how it came about
After my talk at Agile Testing Days Scandinavia, a question that left me thinking (and discussing with Llewellyn Falco) was about the difference between Mob Programming and Coding Dojo. In both, we have a group. In both, we have a rotation. In both, we work together on a problem. Mobbing grew out of Randori (coding dojo), so is there a difference?
At the conference, my response was that the difference I've seen was the style of navigation. With the rule of "an idea from my head to the computer must go through someone else's hands", the dynamics of the group changes from watching a pair (coding dojo) to group of navigators channeling stuff to the computer (mob programming).
Llewellyn was not completely happy with my answer, as mob programming as he sees it, isn't really defined by an individual mechanic such as style of pairing. He introduced metaphors to think about the difference: Is a swimming pool just a bigger bath tub? Clearly not. Is there a difference between a first date and a long-term relationship? Clearly yes. The groups that grow together through mob programming are essentially different than groups that just start the mechanics of mob programming together. The level of trust makes it a whole different ball game.
Navigating the idea to action
Instead of explaining all this to my fellow mob writers in the session, I navigated words onto the text file we were creating. As soon as I was getting the first part of the idea out that us as first time group were more like a first date over an established mob as we were a group of strangers coming together, the others reacted strongly against this. I was not allowed to finish my sentence (so much for kindness, consideration and respect...)
Since we were writing a metaphor, another navigator offered a competing metaphor. What we were experiencing was more like already being experienced in driving a car, but needing to move into a massive truck changing from programming to writing. Being a proficient writer, I naturally disagreed with this metaphor.
Both of us raised our voices ever so slightly. Both of us started talking more about the metaphors, willing to clarify them in many more words. No text was bring written. So I remembered the rule of thumb: Do both.
I had been in half-sentence with my thought, and it was not going anywhere even if I did not finish. I stepped back and proposed to work on the eccentric to me idea, just to see how it would work as text.
The one with the idea navigated the words on paper. As he was finished with his chapter, I no longer cared about my idea - it wasn't any better in terms of clarifying. His words were there and we moved on to describing the experience of choosing what to write on by just writing and delaying the commitment.
Review for consistency & correctness
With the article done, we took upon ourselves to mob with reviewing for consistency and correctness. And in this reading, we ended up deleting also the other metaphor. It left bits around it, that we refactored into something that made more sense thinking of our audience. Those bits around were valuable sentences of ideas, ideas that would have not ended up on paper if we had fought about ideas over the implementations.
What did I learn?
I learned that
With Mob Testing, I see these as ideas of where the bugs might be hidden. In training setting, I often stop people from following the ideas to keep the group together, and just park ideas actively in the mind map for future - that in training often never comes.
The rule of thumb on mobbing would be to approach competing ideas of solutions with the "do both" approach. At Mob Programming Conference this week, I had just the right opportunity to live by this rule.
In the open spaces, we were trying out mob writing an article. We were trying to describe mobbing for the inexperienced through describing the mobbing we were doing right now, and the line of thought from people who do not mob lead me to an idea of needing a metaphor.
My choice of metaphor and how it came about
After my talk at Agile Testing Days Scandinavia, a question that left me thinking (and discussing with Llewellyn Falco) was about the difference between Mob Programming and Coding Dojo. In both, we have a group. In both, we have a rotation. In both, we work together on a problem. Mobbing grew out of Randori (coding dojo), so is there a difference?
At the conference, my response was that the difference I've seen was the style of navigation. With the rule of "an idea from my head to the computer must go through someone else's hands", the dynamics of the group changes from watching a pair (coding dojo) to group of navigators channeling stuff to the computer (mob programming).
Llewellyn was not completely happy with my answer, as mob programming as he sees it, isn't really defined by an individual mechanic such as style of pairing. He introduced metaphors to think about the difference: Is a swimming pool just a bigger bath tub? Clearly not. Is there a difference between a first date and a long-term relationship? Clearly yes. The groups that grow together through mob programming are essentially different than groups that just start the mechanics of mob programming together. The level of trust makes it a whole different ball game.
Navigating the idea to action
Instead of explaining all this to my fellow mob writers in the session, I navigated words onto the text file we were creating. As soon as I was getting the first part of the idea out that us as first time group were more like a first date over an established mob as we were a group of strangers coming together, the others reacted strongly against this. I was not allowed to finish my sentence (so much for kindness, consideration and respect...)
Since we were writing a metaphor, another navigator offered a competing metaphor. What we were experiencing was more like already being experienced in driving a car, but needing to move into a massive truck changing from programming to writing. Being a proficient writer, I naturally disagreed with this metaphor.
Both of us raised our voices ever so slightly. Both of us started talking more about the metaphors, willing to clarify them in many more words. No text was bring written. So I remembered the rule of thumb: Do both.
I had been in half-sentence with my thought, and it was not going anywhere even if I did not finish. I stepped back and proposed to work on the eccentric to me idea, just to see how it would work as text.
The one with the idea navigated the words on paper. As he was finished with his chapter, I no longer cared about my idea - it wasn't any better in terms of clarifying. His words were there and we moved on to describing the experience of choosing what to write on by just writing and delaying the commitment.
Review for consistency & correctness
With the article done, we took upon ourselves to mob with reviewing for consistency and correctness. And in this reading, we ended up deleting also the other metaphor. It left bits around it, that we refactored into something that made more sense thinking of our audience. Those bits around were valuable sentences of ideas, ideas that would have not ended up on paper if we had fought about ideas over the implementations.
What did I learn?
I learned that
- Mob programming gives me a useful heuristic to step down on a creative disagreement: do both
- Doing 'bad ideas' generates new ideas that wouldn't emerge if we just argued
- Neither our level of trust as a team or the difference of programming vs. writing mattered for the point we wanted to be making
- I dislike long release cycles: we did not publish the article right away, it will come out in InfoQ weeks later. So I end up writing a different view into the same experience a lot before our shared experience gets out.
