Retrospective for one testing team
This testing team haven’t done retrospective before, and there’s no actions before too. They were in “Scrum” as said by organization Agile transformation even though they only do testing, and they were actually not a team, members were responsible for test cases in different component areas.
Since the team leader or say Scrum master hasn’t any experience in facilitating retrospective, team members were also interested in knowing how to facilitate an retrospective.
Quite a long time without any retrospective before, it’s a bit hard to using timeline in the “Gather Data” phase. I decided to help them move a small step first, summarize their feeling about last sprint in one word, then to explore in the future. Everybody graps one post-it note, write down, share with others on the flipchart. Then I gave everybody one dot, they could add this dot to support any feelings other than themselves’.
Continued to gather data by exlporing the feelings. I asked everybody to write down any events which made them have that feeling. Then share with all others to see if they feel the same, circle a “+1” on the card if you feel the same.
Then align those index cards according to the numbers of support, from highest at left to lowest at right. Gave everybody a chance to go through all those, refresh the overview.
Then, prioritize the cards, but not according to the support, but how painful it is to you. In another word, the top problem. Simple rule, everybody three dots, the most dots the highest priority to solve.
There are several ways to generate insights from that data, and decide what to do. To help them more be a team, I decided not to use diverge-converge way, instead promoting collective discussion. Show them the fishbone technique, ask them to choose catagories prefered, and self-organized to discuss. They volunteered to be two groups, each discuss one catagory in parallel. Unfortunately they seems are really inexperienced in group discussion and decision making, or politely say too diverse opinions.
Some classical issues arosed, a facilitator must be awared.
- The team leader who should be the facilitator in the future was very insistent once in the discussion, she really believe the team were not so active, while team believed the main cause if no pre-agreement of external experts’ time. She was close to frastrated, but still insisting, I jumped in to break the deadlock. “Let’s do a simple thumb-voting. If you think agreement is the root cause, thumb up; if you support the active opinion, thumb down; both are fine for you, pronate.” 3 seconds, all thumbs up beside hers. Looking at her, I said “I think it’s obvious now.”
- A proposal was made to combine some testcases to reduce execution time, since every case requires a time-consuming restart. Based on myself’s testing experience, it’s unclear that whether they want to execute several cases at the same time, or they even want to combine the testcase at the design level. The 2nd possibility is dangerous since it blurs the boundaries of testing points. Two boys were so slient and intrinsic, one tend to express his opinion, but continuously been disturbed by one active / noisy girl. I stopped her using my facilitator power, because I thought they should listen to others ideas ad a team. Do not judge too early, right?