Holding a QA-Focused Retrospective to Build Better Software

Is quality assurance important to your product? How about to your brand? If the answer is yes—and I hope it is—then perhaps it’s time to think about offering your QAs the spotlight at the retrospective table.

What’s the definition of a retrospective? A retrospective is a look back at past events. Only here, we’re not reviewing Bowie’s discography or the evolution of engineering. Retrospectives play a very important role in agile software development. At the end of every iteration a retrospective is held to review what worked, what didn’t, and brainstorm solutions to improve.

We know that the best work—in any industry—is done when all stakeholders feel valued, and when teams recognize the unique contributions that cross-functional perspectives bring to the table. That’s one reason including a QA spotlight in your retros, or holding a QA focused retro, offers maximum ROI for time spent.

The Benefits of a QA-Focused Retro

Include a QA spotlight in your retrospectives to:

• Solidify relationships with designers and engineers and reinforce the idea that everyone is working toward the same goal.
• Empower QA team members to understand how their specific contributions impact product launches.
• Reduce or eliminate the typical us-vs-them paradigm set up by ‘bug-count’ metrics or ‘throwing the issue over the wall’.

Hold a QA focused retrospective to:

• Surface feedback previously unavailable to development.
• Help product managers and developers to ‘un-silo’ and look at software from the Quality perspective.
• Understand product development in a practical way. QA engineers are the team members with the most practical experience in how software actually performs. They know the ins-and-outs of user experience, where ‘gotchas’ typically lie, and where and how to look for defects. In short, they’ve been there and done that in more than theory.
• Promote mindfulness and accountability—of all team members.

Tips for Running a QA-Focused Retrospective

So, you’re ready to include a QA spotlight in your retrospectives, or to hold a QA-focused retro? Fantastic! Let’s discuss a few pointers for facilitating a productive retrospective.

We know typical meetings can be boring or seen as time better spent elsewhere. A retrospective is different. Here, the intent is less pontification and more a meeting of the minds. A retro isn’t a finger pointing exercise, or an audience held captive by only the most vocal team members. Rather, this is a collaborative process of thought-sharing, knowledge-broadening, and problem-solving.

General considerations:

• Everyone has a voice – don’t let the squeakiest wheel monopolize the floor
• Break up project silos when possible – the point of a retrospective is to encourage cross-functional insight and collaboration
• Always provide a safe space for all members to reflect and discuss – frame area specific roadblocks or issues as “how can we help?” rather than “whose fault is it?”
• Use activities to encourage participation – we’re human and we like to have fun

Methods and Activities to Focus A Retrospective

First, set the rules of engagement:

• Don’t make it personal; don’t take it personally.
• All opinions are valid.
• Set a retrospective boundary: is it the last sprint, quarter, or project?
• Recognize not everything can be fixed at once.
• Focus on immediate actionables and an improvement mindset.

Second, map out your retrospective game plan. Here are some ideas:

Method: Happy/Puzzled/Sad

Use this when you want to know how your teams felt, rather than what happened. This is a great way to see where silo related tensions lie, and to find out what’s really ‘bugging’ your team.

• Give teams sticky notes to jot down the things that made them happy, confused, or sad/angry. On the sticky they should briefly describe the issue then draw the corresponding smiley face. Afterwards, use a whiteboard or the wall to group stickies with the same category smiley faces and dot-vote to prioritize issues. (Hint: limit each person to three votes, and don’t allow double-dotting).

Method: Hypothesis

Use this when you want teams to collaborate on solutions. Again, ask everyone to compose one sticky note on their priority issue, then group and dot-vote. (Hint: do one 10-minute round of individual issue brainstorming, then after voting combine members into cross-functional teams to build a hypothesis. Hypothesis can then be dot-voted to provide an action step for the current retrospective).

• We hypothesize by <implementing this>
• We will <improve on this problem>
• Which will <benefits>
• As measured by <measurements>

Method: The 4Ls

Best for a longer retrospective where sufficient time can be devoted to each question. Have participants answer the following (one per sticky note) then group per category. Discuss each answer as a whole.

• What did you like?
• What was lacking?
• What did you learn?
• What do you long for going forward?

Agile Retrospective Recap

Retrospectives are a fantastic way to encourage cross-functional collaboration, understanding, and problem-solving. However, these benefits arise only when all members feel valued, and diversity of experience is appreciated. To make the most of your most valuable assets—your employees—try a QA-focused retrospective to gain valuable insight into your software development processes. Make sure that once an actionable is decided, clearly identify who is responsible for next steps. Create a Jira ticket, assign it in a Trello board, or do whatever it takes to communicate the outcome and next steps. Incremental steps lead to big strides forward!

Interested in How We Can Help Your Software QA Teams?

Want to learn more about how our QA and software testing services can help your company release better software? Contact us to find out how we can improve your QA ROI.