Saturday, May 13, 2017

Thoughts about Testing in a Mob

This was not the first mobbing experience for our team, but the first one to complete a whole story using this approach. One key factor that the team agreed with mobbing at all, was that our mob size changed dynamically. Whoever wanted to join the mob was welcome any time, and whoever preferred to work on other tasks could do so as well. This way, our mob consisted of three to seven persons. The downside of this approach was that we did not always have all the knowledge at hand but had to ask asynchronously for feedback. Still, we had enough knowledge available to stay productive and make progress.

Personally I decided to always stay in the mob. As a team player, there was no other option for me. As the person who triggered that we give this approach a try, I was curious how it will work out and did not want to miss this learning experience. And as the only person identifying as tester on the team, I felt staying in the mob was just perfect to trigger tests, provide feedback, raise questions, and seek answers as soon as possible. This way, I felt another downside of the dynamic mob size: As some teammates decided to work on their "own" stories, I missed to provide feedback on those as early as I could (though of course others could have stepped in). Luckily the mob selected a story we needed to complete to achieve our sprint goal, which justified that I spent all my efforts there first.

After we finished our story, I was feeling proud. This was really a joint team effort and we all had our hands on the story, ensuring quality from different perspectives. But one thing made me think: Shortly before we decided that our changes are ready to be merged, one colleague challenged this by raising the question who does testing of the story. At first this puzzled me, as we had included testing all the way from start to finish. So I answered that the mob tested the story thoroughly. But this teammate was not convinced that you could possibly come up with all necessary tests in the mob.

As he could not tell what else to test, and the current mob agreed that we covered everything from quality perspective, we merged the story nonetheless. But his comment left me wondering. Did we forget something? Should we have something done differently? Should we have not allowed for dynamic mob sizes as particularly this colleague did not join all sessions? Which reasons did he have to think that testing cannot be done in a mob? Is there a trust issue?

Naturally, I don't have all the answers but I will keep an eye on this issue. To gain more insights, I decided to join Maaret Pyhäjärvi's tutorial at Agile Testing Days 2017 about Mob Testing. Still, my biggest hope is that my team continues working on actual stories as a mob to gather more experience ourselves and learn by doing.

2 comments:

  1. Sounds like a good experiment, you learned a lot! It'd be interesting if you had the chance to try again but with a set group of people, rather than have them come and go.

    Did you do exploratory testing on the story during the session also?

    ReplyDelete
    Replies
    1. We definitely did share and learn a lot. We've done six sessions so far, adapting along the way. We started with a strict set of rules (see http://www.lisihocke.com/2017/04/our-teams-first-mobbing-session.html). Afterwards, we experimented with more leightweight approaches (see http://www.lisihocke.com/2017/05/mobbing-take-two-and-take-three.html). As a result for now, we found that the team liked the most informal way the best. In fact, the group for each session was quite stable, it rather changed between the different sessions for the same story. But the team felt that being allowed to leave the mob to get a coffee or in case they have a personal meeting gave them the desired freedom. Maybe this was a key factor that the team agreed to continue mobbing for certain stories as this approach proved valuable for problem solving and knowledge sharing.

      We also did some exploratory testing during the sessions, but rather shortly after each increment. This way, we discovered several issues we could then fix right away, raised further questions nobody thought of yet, and noted follow-up tasks. However, today we found that a critical issue actually slipped through. It was only caught after merging; yet before release, so we could fix it today and no harm was done. The team agreed that we hardly would have caught it upfront, also with our normal workflow. Still, this triggered the testing discussion and we agreed to take more dedicated time to further explore at the end of each story we work on together. Not to rush, but to even more focus on quality.

      In the end, we all know that these mob experiences are just our first baby steps. We have to keep improving our way to learn what actually works best for us.

      Delete