During my 6 months at the new job, I've managed to do Mob Testing a few times. Basically the idea is that whenever I sink into a new feature that needs exploring, I invite others to join me for the exploration for a limited time. I've been fascinated with the the perspectives and observations of the other testers I've had join me, but these always leave me wanting after the Mob Testing experiences I had at my earlier place of work. There not only testers joined (well, there were no testers other than myself) but we did the tasks together with the whole team, having programmers join in.
There's a big difference on if you're mob testing amongst testers (or quality engineers as we call them) or if you're including your teams developers and ever product owners. And the big difference comes from having people who need to receive the feedback testing is providing sharing the work.
With 6 months approaching, I'm starting to see that my no-so-subtle hints on a regular basis are not taking adapting mob testing / programming further. But it became funny at a point I taught developers from another organization who started off with the practice, and only through their positive reports someone relevant enough to push people to try it took initiative. There's an infamous old saying of no one ever being a prophet on their own land, and that kept creeping up to my thoughts - I became part of furniture, "always been here" surprisingly quickly. And I don't push people to do things they don't opt in to.
But finally last week's Wednesday, while my own personal team did not opt in, the team next door did and invited me to join their experience. With two application developers, two test developers and two all-around test specialists, we took the time to mob for about 5 hours during the day.
The task we were working on was a performance testing task, and the application developers were not in their strong area. We worked on extending an existing piece of code to a specific purpose, and the idea of the task was available to start our session. There were a few particularly interesting dynamics.
When in disagreement, do the less likely one first
About half an hour into our mobbing, we had a disagreement on how we would approach the extending of the code. We just did not disagree what would be the right thing to do as the next step. The two of us who were familiar with what the goal of what we were doing had one perspective. And another suggested doing things differently, in a way that in the moment felt it made little sense to us.
I realized that were were quickly going into discussion mode, convincing the other of what the right thing was - at a time we really knew the least. The other suggestion might not sound like the best idea, so we played a common rule to beginning mobs: "Do the less likely first, do both". Without continuing the discussion, we just adjusted the next step to be one that the other, in minority, felt strongly enough to voice.
And it turned out to be a good thing to do in a group. As it was done, the work unfolded in a way that did not leave us missing the other option.
Keep rotating
Between hours 2-3, two of the six mob participants needed to step out into another meeting. I was one of these two. For first two hours, we had rotated on a four minute timer and pushed the rule of having a designated navigator. As I came back from the meeting, the rotation had fallen off as the mob had found relevant bugs in performance and had two other people join in as lurkers on the side of the table, monitoring breaking services in more detail. The lurkers did not join the mob, but also the work got split so that the common thread started to hide.
Bringing back rotation brought back the group thread. Yet it was clear that the power dynamic had shifted. The more quiet ones were more quiet and we could use some work on dominating personalities.
But one things I loved to observe on the more quiet ones. They aced listening and it showed up as timely contributions when no one else knew where to head right now.
Oh Style
The group ended up on one computer with one IDE in the morning and another computer with another IDE in the afternoon. Keyboard shortcuts would fly around, and made different IDEs obvious.
On the order of doing things, there was more disagreement than we could experience and go through in one day. Strong opinions of "my way is the best way" would be best resolved doing similar tasks in different ways, and then having a retrospective discussion of the shared experiences.
And observing the group clean up code to be ready to check in was enchanting. It was enlightening to look at group who have "common rules" to not have common rules after all. Mobbing would really help out figuring the code styles over the discussions around pull requests.
There's a big difference on if you're mob testing amongst testers (or quality engineers as we call them) or if you're including your teams developers and ever product owners. And the big difference comes from having people who need to receive the feedback testing is providing sharing the work.
With 6 months approaching, I'm starting to see that my no-so-subtle hints on a regular basis are not taking adapting mob testing / programming further. But it became funny at a point I taught developers from another organization who started off with the practice, and only through their positive reports someone relevant enough to push people to try it took initiative. There's an infamous old saying of no one ever being a prophet on their own land, and that kept creeping up to my thoughts - I became part of furniture, "always been here" surprisingly quickly. And I don't push people to do things they don't opt in to.
But finally last week's Wednesday, while my own personal team did not opt in, the team next door did and invited me to join their experience. With two application developers, two test developers and two all-around test specialists, we took the time to mob for about 5 hours during the day.
The task we were working on was a performance testing task, and the application developers were not in their strong area. We worked on extending an existing piece of code to a specific purpose, and the idea of the task was available to start our session. There were a few particularly interesting dynamics.
When in disagreement, do the less likely one first
About half an hour into our mobbing, we had a disagreement on how we would approach the extending of the code. We just did not disagree what would be the right thing to do as the next step. The two of us who were familiar with what the goal of what we were doing had one perspective. And another suggested doing things differently, in a way that in the moment felt it made little sense to us.
I realized that were were quickly going into discussion mode, convincing the other of what the right thing was - at a time we really knew the least. The other suggestion might not sound like the best idea, so we played a common rule to beginning mobs: "Do the less likely first, do both". Without continuing the discussion, we just adjusted the next step to be one that the other, in minority, felt strongly enough to voice.
And it turned out to be a good thing to do in a group. As it was done, the work unfolded in a way that did not leave us missing the other option.
Keep rotating
Between hours 2-3, two of the six mob participants needed to step out into another meeting. I was one of these two. For first two hours, we had rotated on a four minute timer and pushed the rule of having a designated navigator. As I came back from the meeting, the rotation had fallen off as the mob had found relevant bugs in performance and had two other people join in as lurkers on the side of the table, monitoring breaking services in more detail. The lurkers did not join the mob, but also the work got split so that the common thread started to hide.
Bringing back rotation brought back the group thread. Yet it was clear that the power dynamic had shifted. The more quiet ones were more quiet and we could use some work on dominating personalities.
But one things I loved to observe on the more quiet ones. They aced listening and it showed up as timely contributions when no one else knew where to head right now.
Oh Style
The group ended up on one computer with one IDE in the morning and another computer with another IDE in the afternoon. Keyboard shortcuts would fly around, and made different IDEs obvious.
On the order of doing things, there was more disagreement than we could experience and go through in one day. Strong opinions of "my way is the best way" would be best resolved doing similar tasks in different ways, and then having a retrospective discussion of the shared experiences.
And observing the group clean up code to be ready to check in was enchanting. It was enlightening to look at group who have "common rules" to not have common rules after all. Mobbing would really help out figuring the code styles over the discussions around pull requests.
