Agile Test Quadrants (Adaptations by Gojko AdžiÄ‡)
I’ve been successfully using the Agile test quadrants in retrospectives to stimulate in-depth team discussions on software quality and its improvement.
The quadrant model was originally developed by Brian Marick, and then popularized by Lisa Crispin and Janet Gregory in their book, “Agile Testing: A Practical Guide for Agile Testers and Teams.” For me, the quadrants capture all the complexities of software quality and can help reduce communication gaps between product owners, business analysts, developers, and testers.
As there’s always room to improve, the model works for both mature teams doing continuous delivery as well as newer teams. Most teams I’ve worked with found they had a “blind spot” for one or more quadrants. For my retrospectives, I use an adaptation of the quadrants by Gojko AdžiÄ‡, but you can use any version you like.
How it works
I usually begin by introducing the format of the workshop and giving a bit of history on the quadrants, which takes about five minutes. There’s often an “aha” moment for participants when they see the quadrants for the first time and recognize the blind spots in their way of working.
Provide a score per quadrant
After introducing the quadrants, I ask each participant to evaluate their expended effort per quadrant, as follows:
Effort spent: too little”Š—”Šjust right”Š—”Štoo much
Quality achieved: low”Š—”Šjust right”Š—”Šoverdoing it
This usually takes about 7 to 10 minutes. Let the participants do this on their own and make sure they don’t start discussing right away. At this point, it’s all is about perception and all input is valid. Next, ask everyone to write their scores on a sticky note with their initials and place it on the horizontal lines next to each quadrant. Now a discussion can be started based on the different values given by the participants.
Try to come to a consensus on effort spent and quality for each quadrant. Write the main observations and problems on sticky notes with a distinct color from the scores and put these aside. Timebox the discussion per quadrant to 15 minutes max.
If arguments become repetitive and no consensus can be reached, write the different opinions on a sticky. Perhaps a way forward will become clear later in the session (or not). Usually, I did not experience severe disagreements within the teams, however, it’s usually obvious as to where the gaps are. The items you do reach consensus on will still provide value. Here are some real-world examples:
“We are doing CD but we completely forgot about the end-user.”
“Our feedback is slow because we are lacking in the bottom left quadrant. We need to start doing more unit testing!”
Define several actions
Now it is time to define concrete actions based on the consensus reached. These can be both specific, technical actions as well as process measures. It’s important to order the issues by priority. Process and development improvements can often be implemented right away, and could be put in the “definition of done.”
If specific development work is needed, then you will need to negotiate with the PO. It’s recommended to always have the PO present to represent the business.
Ending the session
Gather the issues, measures, and their priority. Make sure relevant items get added to the DoD.
Once you’ve done the exercise once with your team, it’s a good idea to repeat it every two or three sprints, as long as it helps you improve. You could also do variations, such as focussing on a single quadrant. Keep it fresh and improvise!
I am a specialist at Qxperts. We empower companies to deliver reliable & high-quality software. Any questions? We are here to help! www.qxperts.io