Retrospective: Using the Team Radar

Retrospective: Using the Team Radar

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 transparent where a team agrees and where it doesn’t, automatically prioritising what needs attention.

In today's Product Owner training I got the opportunity to put this Retrospective format in 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.

Preparation

Before the start of the workshop I'd prepared 2 team radars. A small one on 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 by "Team Radar" in this blog post. 

Doing the Team Radar

  • We started the Retrospective by creating 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 in 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!

Findings

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. Afterwards 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 concerned 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.

Closing

In this blog post I've shared my experiences using the Team Radar as described by Christiaan Verwijs. Because the participants didn't belonged to a team but consisted of several Product Owners and Business Analysts I renamed the format the "Retrospective Radar". During the Retrospective I 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.

If you've tried it as well: let me know. I'm always eager to learn from your experiences!


Anubhav Sinha

Building Beyond Playbooks | Product Operating Model | Help Teams in Building Product, Business Aligned Approach and Transformation | Pricing, B2B SaaS

8 å¹´

Yes - this is wow to analyse where gap persist

赞
回复
Caio Roth

Engenharia | Produto | Agilidade

8 å¹´

Great idea, I'll test in my next retrospective...

赞
回复
Werner Spreeuwenberg PMP

Senior Agile Project Manager at b-next group

8 å¹´

Rotating retrospective models by using models like the pancake and futurespective models, helps in keeping the retrospective participants engaged. Getting a retrospective facilitator from outside the team helps in getting new insights into the team. He/she might even get the team to open up on topics which the team normally sidetracks. Great article and well done Barry.

赞
回复
Esther Fortman

International Business | Letters of Credit | Value Chain | Trade Finance Services | Outside Europe | Guarantees | Risks

8 å¹´

Jack Boone

赞
回复
Steven Deneir

???Scrum Opinion Leader | Professional Scrum Trainer | Simplification Officer | Guiding organisations towards business agility ??

8 å¹´

I once applied this tool in a slightly different format calling it the Team Bike: instead of 1 wheel we had 2 - a bike... Idea was here, if we are a team we want to race towards our target. So what helps us to get better wheels. The first wheel had the Scrum Values as spokes. The second wheel had the Scrum Events as spokes. Thanks for the reminder of this great tool! I'll probably use it again in our next retrospective.

要查看或添加评论,请登录

Barry Overeem的更多文章

  • The Making Of The Brand-New Professional Scrum Master II class

    The Making Of The Brand-New Professional Scrum Master II class

    Finally! With the “embargo” lifted by Scrum.org, we can now share with you the incredible journey that Christiaan…

    13 条评论
  • About the Professional Scrum Master II Class

    About the Professional Scrum Master II Class

    This week Scrum.org launched the brand new Professional Scrum Master II class! For the past eight months, together with…

    14 条评论
  • Myth 14: Refinement is a required meeting for the entire Scrum Team

    Myth 14: Refinement is a required meeting for the entire Scrum Team

    Scrum is intended as a simple, yet sufficient framework for complex product delivery. Scrum is not a one-size-fits-all…

    19 条评论
  • Unleash local know-how with a User Experience Fishbowl

    Unleash local know-how with a User Experience Fishbowl

    Unleash local know-how with a User Experience Fishbowl rather than relying on external “experts” Organizations often…

  • An Essential Practice for Entrepreneurs

    An Essential Practice for Entrepreneurs

    Last week Bauke, Max, Jelrik, Christiaan and I got together for our monthly meetup as part of “The Liberators Friends”.…

    4 条评论
  • Peer coaching with Liberating Structures

    Peer coaching with Liberating Structures

    Liberating Structures are 33 easy-to-use structures for interaction in groups of any size. They enhance relational…

    7 条评论
  • Myth 13: The Scrum Master can’t remove people from the Scrum Team

    Myth 13: The Scrum Master can’t remove people from the Scrum Team

    Scrum is intended as a simple, yet sufficient framework for complex product delivery. Scrum is not a one-size-fits-all…

    99 条评论
  • My Hope for the Future of Scrum

    My Hope for the Future of Scrum

    This week I got interviewed by Marcos Lopez at Agile-Lean Ireland in Dublin. Marcos offered me some interesting…

    6 条评论
  • The Liberators: Unleashing Organisational Superpowers

    The Liberators: Unleashing Organisational Superpowers

    Today marks the official founding of The Liberators. We, Barry Overeem and Christiaan Verwijs, wanted to start a…

    24 条评论
  • Your Scrum Master Journey @KPN iTV

    Your Scrum Master Journey @KPN iTV

    This week Christiaan Verwijs and I facilitated a workshop at KPN iTV in which Scrum Masters could provide a pitch for…

社区洞察

其他会员也浏览了