Over a million developers have joined DZone.

Retrospective: Using the Team Radar

DZone's Guide to

Retrospective: Using the Team Radar

In this post, MVB Barry Overeem discusses his experience with a new method for conducting Sprint Retrospectives - the Retrospective Radar.

· Agile Zone ·
Free Resource

Download this white paper to learn about the ways to make a Scrum Team great, brought to you in partnership with Scrum.org

Recently Christiaan Verwijs wrote the blog post “Retrospective: Do The Team Radar." As Christiaan describes, this format strikes a nice balance between reflection as a team and as an individual. It’s also one of the best methods to make the project transparent where a team agrees it should be and where it shouldn't be, automatically prioritizing what needs attention.

In today’s Product Owner training I got the opportunity to put this Retrospective format into practice. One of the goals was to assess the current state of the Product Owner role and product management way of working. The ideal moment to try the Team Radar and to check the awesomeness of this format.


Before the start of the workshop, I’d prepared 2 team radars. A small one on an A4 format for every individual participant, and a large one on a flip-chart for the group as a whole. Because it was a Product Owner workshop I wrote down the topics I thought would be most relevant. One topic was left open and got chosen during the day.

The exact topics can change per Retrospective, for this session I selected: Scrum, Definition of Done, Stakeholder Management, Mandate, Return on Investment, Quality of the Product Backlog, and Collaboration. I also changed the title to “Retrospective Radar” because the participants didn’t belong to the same team. The title retrospective radar seemed more appropriate. To avoid any confusion I’ll stick with “Team Radar” in this blog post. 

Doing the Team Radar

  • We started the Retrospective by creating a shared understanding of every topic. Because the participants had different roles (e.g. Business Analyst, Product Owner) and weren’t part of the same team it was important to offer everyone a clear perspective and starting point.
  • Using the printouts of the Team Radar, I asked everyone to individually rate the topics on the spokes. We’ve used the scale from 1 (not going well at all) to 10 (going extremely well) and everyone marked the score on the axis.

  • When everyone was done rating the axes on their individual printout, I asked them to connect the dots/markings from the various axes. This way everyone created their own radar.
  • Because the group was quite large (13 persons) I created 3 teams in which they shared the results with each other. After 10 minutes every team merged the individual results into a “team result.” The three team results were subsequently plotted on the large team radar.

  • After the results of the three teams were incorporated in the large team radar, we took about 15 minutes to discuss the findings as a group. The suggested questions by Christiaan Verwijs proved to be useful:
    • What patterns are visible right away?
    • What surprises or shocks you?
    • On what topics do we (mostly) agree or disagree? What does this tell us?
    • What topics receive a low rate from everyone?
    • What individual scores are surprising? What does this tell us?
  • After discussing the results sufficiently, we dot-voted for the three axes that needed improvements most urgently.

Creating an Improvement Canvas

  • A good Retrospective will result in actionable and committed improvements. To ensure such a result, I got the idea to use a tailor-made version of an Improvement Canvas. A detailed description of this canvas is described by Crisp.
  • Again the group was divided into three teams. Everyone was free to choose the topic they wanted to work on.
  • After a few short iterations with frequent reviews, inspection, and adaptation, the first version of the improvement canvas was created. Every canvas (three in total) contained actionable items for the upcoming weeks. It needs a bit more refinement, but it’s definitely good enough to get started!


The Team Radar is definitely a format I’m going to use more often. As Christiaan already stated it generated lots of valuable in-depth discussions. The three levels in which we used the radar was also a good choice: individual, team, group. First, give everyone the opportunity to assess the different topics themselves. Afterward let them discuss the results in their team, and finally, share the results with the entire group. Using an improvement canvas might not be necessary for every team Retrospective. But because this session was concerned with some larger issues it was a good choice to spend some extra time on creating actionable improvements. It also offers a good opportunity for another “Team Radar” in 6 weeks time.


In this blog post, I’ve shared my experiences using the Team Radar as described by Christiaan Verwijs. Because the participants didn’t belong to a team but consisted of several Product Owners and Business Analysts I renamed the format the “Retrospective Radar.” During the Retrospective, got the idea to combine this format with the creation of an Improvement Canvas. This proved to be a good decision because it resulted in tangible, actionable improvements. Hopefully, the article by Christiaan and this story “from the trenches” is useful to you.

Learn more about the myths about Scrum and DevOps. Download the whitepaper now brought to you in partnership with Scrum.org.

agile ,retrospectives ,scrum

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}