Informations
Jobs
The team
The Team Radar is a well-suited format for comparing the individual assessments of team members with regard to certain categories. In this way, different expectations of the team also become easily visible. If you use this format several times in a team, you can visually recognize possible team developments on the basis of the different radars.
Preparation
Print out as large a team radar as possible for the wall and one A4 version per team member. Pre-write category suggestions on Post-Its. Categories can be characteristics of a team or values they want to represent, but also for example the question: "How well are we positioned process-wise?". Basically, anything that describes a team and that they can rate on a . 1-5 scale.
Here are a few examples:
- Knowledge distribution
- Focus
- Time to market
- Helpfulness
- Motivation
- Innovation
- Product identification
- Solution-oriented
- Common goals
- Feedback behavior
- Technical debt
- Appreciation
- Meeting culture
- Processes
- Software quality
- Trust
- Openness
- Conflict Capability
You will also need some colored pens, more blank Post Its and a flipchart.
Implementation
Check In
You can actually choose any format for the Check In. Since Team Radar is about comparing individual assessments of the team, the following task might be a good fit:
"Write in one sentence on a Post-It what your neighbor to the left would say about the last sprint."
The Post-Its are then collected on a flipchart and everyone briefly tells something about their sentence. The neighbor meant in each case can add whether the assessment matched.
Determining the categories
Before the radar can start, the team has to agree on six categories. For this purpose, I distributed the prepared Post-Its around the still empty large Team Radar. My current team consists of about ten people and so I asked the colleagues to go to the board collectively and distribute the Post-Its on the radar themselves.
If the team is missing a category, they can write it themselves on one of the empty Post-Its and hang it to it.
We briefly discuss the selected categories to make sure that everyone in the team associates roughly the same thing with the map.
Individual radar
Once the categories have been determined, each team member receives an A4 version of the radar with the request to transfer the categories there and to record their own assessment of them on the scale. They are not supposed to exchange themselves yet, in order to remain really with their own perceptions. The plotted points can then be connected to form a radar.
teamradar01
The single radar should really be filled in alone, without comparing the result with the neighbor. As a moderator, you could pay special attention to this.
Merging on the team radar
If the single picture of all colleagues stands, each team member transfers its radar on the large team radar and gives still some short explanations. Finally, everyone can see the finished team radar and let it have a little effect on them. Sometimes this leads to a discussion, usually when there are large deviations in individual categories.
teamradar02
Otherwise, you can also ask the team a few questions about the radar:
- Does the image meet your expectations?
- Were there any particular surprises?
- Can you explain why your assessments are so different?
- Very cool, you guys are in agreement. What could have led to this?
Comparison with older team radars
If you have already used the Team Radar several times in the same team, it is also worthwhile to compare it with the predecessors at this point. Are there any improvements? Has the picture changed a lot?
Voting
Afterwards every member gets 2-3 possible votes, which he can assign to the categories. You can also put all three votes on only one category. The categories with the most votes will be discussed in the further course of the retro. Depending on the time and motivation still available in the team, the number may vary. In the last implementation, we talked about three categories in more detail.
Discussion and action for voted topics
For each voted category, we now talk more intensively about differences, jointly determine how high the average scale point should be in the next team radar and what can be done concretely to achieve this. For the action items, as always, the more concrete the better and there should also be a person responsible for the topic (if possible, not your Scrum Master).
Personally, I prefer to mix the phases Generate Insight and Actions, since you are already in the topic during the discussion and don't have to jump back and forth.
Even though this section seems to be very short in my description right now, you should spend most of your time on it.
Conclusion
Finally, I summarize the collected measures once again. They can then also be seen visualized on the Team Radar. Then there is a small round of feedback on the format itself and if this is positive, I hold out the prospect that we will repeat the radar again in about 6 months.
Materials
PDF Team Radar A0 PDF Teamradar A4
Feedback
Do you already have experiences with this format or do you have further questions? Are you generally interested in the presentation of retro formats? Then please write a comment. We are always happy to receive feedback.
2Comments
- 29.06.2018 16:01 Clock
Das klingt nach einer einfachen Retro Technik. Ich werde sie ausprobieren,
- sschoenebein29.06.2018 16:30 Clock
Hallo Mirko,
das freut mich. Schreibe uns gerne, wie es so gelaufen ist :-)
Schöne Grüße,
Steffi
Write a comment
Answer to: Reply directly to the topic
Written by
Stefanie Schönebein
Similar Articles
AlexanderSeptember 15, 2022Fully-automated enterprise-scaled provisioning of AWS Accounts via Self-Service using Jira Service Desk
00In this article, we’ll demonstrate how to automate the provisioning of AWS Accounts via self-service using Jira Service Desk, potentially reducing the provisioning time of out AWS Accounts from 4 hours to 25 minutes.Project managementWorking methods
RenéFebruary 28, 2022A brief guide to replacing legacy software
03Some see the task of ‘replacing outdated software’ as punishment. Well, I see it differently! In this article I’ll explain how we successfully introduced an extensive new system and resolved over 100 dependencies. Software, just like natural organisms, has a finite lifecycle. However, the end of its useful lifetime does not necessarily mean ‘The End’ – it can also be the beginning of something new. In this sense, there is something evolutionary about software replacement.ArchitectureProject management
