Jeder Produktmanager kennt den Moment in dem man bemerkt, dass im Team irgendwie der Wurm drin ist. Oft hat man selbst auch direkt eine Meinung was alles verbessert werden müsste, nur irgendwie sieht das Team das nicht. Sind die denn doof? Das ist doch offensichtlich!!
Nein, sind sie nicht. Es gibt eine schöne Metapher aus dem Coaching dazu: „Das Auto in dem man sitzt kann man nicht anschieben“. Und genauso verhält es sich. Wenn der Produktmanager solche Muster also früher erkennt, dann eben weil man nicht wirklich Teil des Teams ist. Und das ist ein echter Vorteil den man nutzen sollte!
Aber wie spricht man unangenehme Themen mit dem Team so an, dass die Mitglieder das Feedback auch annehmen können und nicht in eine Verteidigungshaltung abrutschen?
Nun, das hängt ganz vom Team ab. Ist man gut eingespielt und das Vertrauen sehr hoch, kann man oft ganz direkt damit rausrücken. Dabei ist es aber gut, bei seinen Beobachtungen zu bleiben und nicht direkt mit Lösungsansätzen um die Ecke zu kommen. Denn meist findet das Team selbst bessere oder praktikablere Lösungen.
Für Teams bei denen die „in your face“-Taktik aber nicht so gut klappen würde, gibt es eine tolle Retro-Methode um Unangenehmes anzusprechen: das Teamradar.
So funktioniert das Teamradar
Das Teamradar besteht aus einer 8-armigen Spinnengrafik mit Achsenbeschriftung und einer Skala je Achse.
Bei der Achsenbeschriftung gilt es die Themen auszuwählen, über die das Team in der Retro dann sprechen soll. Nehmen wir als Beispiel „Feedback-Kultur im Team„. Zu dem jeweiligen Thema soll das Team sich selbst eine Note auf der Skala geben.
Bei der Skala ist es wichtig, eine Zahl ohne echten Mittelwert zu finden. Eine 10er Skala ist also doof… da tendieren die Teams immer zur 5. Ich nutze immer eine 7er Skala und oft wird viel diskutiert über die Frage „3 oder 4“.
Die Frage für unser Beispiel wäre also: Wie zufrieden, auf einer Skala von 1-7 (wobei 7 sehr zufrieden wäre) ist das Team mit seiner Feedback-Kultur? Natürlich geht das nur nach kurzer Diskussion im Team.
Im Anschluss verbindet man die Punkte und bespricht, wie in jeder Retro, Action Items für die 1-3 schlechtesten Bereiche.
Auswahl der Achsenbeschriftungen
Für die 8 Themen entlang der Achsen haben sich folgende Auswahlkriterien bewährt:
- Als erstes formuliert man das eine Thema, das der Produktmanager im Kopf hatte zum Thema „im Team ist der Wurm drin“. Stört es den Produktmanager zum Beispiel, dass einige Personen im Team zu Meetings zu spät kommen, könnte die
Achsenbeschriftung „Pünktlichkeit“ oder, etwas weniger deutlich und offener formuliert „Meeting-Kultur“ heißen. Das Thema kommt so sicher zur Sprache und man kann einen Eindruck gewinnen, ob das Thema auch wichtig für das Team ist… denn vielleicht stört es schon länger alle im Team, aber keiner wollte es ansprechen. Oder es stört nur den Produktmanager und das Team nicht. Dann wird das Team sich eine gute Note geben und das Thema ist erst mal wieder erledigt. - Zur Beschriftung der anderen Achsen nutze ich die agilen Werte, Prinzipien und Praktiken. Eine gute Liste gibt es hier bei agilecoach.de
Wichtig ist es außerdem, nicht nur Problemfelder als Achsenbeschriftung zu nehmen. Überlegt ruhig 3-4 Themen, bei denen das Team sich gute Werte geben oder selbst erkennen kann, dass es super Fortschritte gemach hat.
So bereitet ihr die Teamradar-Retro vor
- Teamradar malen – hier eignet sich ein Flipchart ganz gut weil man es nach der Retro mitnehmen und im Teamspace aufhängen kann.
- Post-its in vier Farben + Stift mitnehmen. Denn es hat sich bewährt, während das Team über die einzelnen Punkte spricht, positive (grün) und negative (pink) Aspekte sowie allgemeine Anmerkungen (blau) festzuhalten. Die vierte Farbe (gelb) nutze ich um die Achsbeschriftungen nochmals zu übertragen.
- Einleitung überlegen. Jede Retro sollte ja immer mit einer „Set the stage“-Phase beginnen. Ich mache gerne das „wie fühlt ihr euch heute“-Ding zum Einstieg. Ein passendes Plakat dazu hier: Feelings. Und wer mehr Inspiration braucht, der nutze den Retromat.
- Genug Zeit einplanen! Diese Retro ist nichts für Menschen mit wenig Zeit. 8 Achsen = 120 Minuten. 4 Achsen = 60 Minuten.
- Raum mit Wandfläche buchen. Denn die Post-Its müssen ja irgendwo Platz finden!
Ablauf der Retro
- Wie gesagt, einsteigen mit einer „Set the stage“-Aufgabe.
- Dann wird das Radar erklärt:
- Warum hast du die jeweiligen Themen gewählt? Gebt hier kurz Kontext zu eurer Überlegung.
- Bittet das Team, sich jeweils pro Thema auf ein Rating zu einigen. Pro Achse sollte nicht mehr als 8-10 Minuten Zeit verwendet werden. Je nachdem wie viel Erfahrung ihr habt, macht der Einsatz eines TimeTimers hier Sinn.
- Bestimmt wer die Post-its beschriftet. Reihum oder eine Person? Ich mache das oft selbst, weil dann das Team in Ruhe diskutieren kann.
- Los geht´s. Fangt mit der ersten Achse an und arbeitet euch Thema für Thema vor.
- Sind alle Themen besprochen, könnt ihr die Punkte verbinden. So wird deutlich, welche Themen ein besonders schlechtes Rating bekommen haben.
- Erfragt die Tendenz. Das geht ganz schnell per Thumbvoting. Bittet das Team per Daumen anzuzeigen ob z.B. das Thema „Pünktlichkeit“ gerade ohnehin ständig besser wird oder ob sie noch eine Verschlechterung erwarten.
- Nun geht es darum Action Items abzuleiten. Beginnt hier mit dem Thema, das am schlechtesten abgeschnitten hat. Haben mehrere Themen z.B. eine 3er Bewertung, dann besprecht zuerst die mit der negativen Tendenz. Mehr als drei Themengebiete zu besprechen macht meist keinen Sinn. Namen an den Action Items nicht vergessen!!
- Schliesst die Retrospektive ab.
Das ist bei der Moderation zu beachten
- Natürlich solltet ihr auf jeden Fall die Zeit im Auge behalten und lieber eine Achse auslassen als keine Action Items abzuleiten.
- Was ich aber viel wichtiger finde ist es, sich selbst so gut wie möglich rauszuhalten. Ihr seit der Moderator. Natürlich habt ihr diese Art der Retro ausgewählt um das Team mal über bestimmte Themen diskutieren zu lassen. Aber eure Meinung dazu kennt ihr ja schon – spannend ist es doch jetzt zu erfahren, wie das Team darüber denkt. Denn vielleicht sehen die Teammitglieder kein Problem wo ihr eines vermutet. Und das bekommt ihr nur raus, wenn ihr einfach mal die Klappe haltet.
- Zu krasse Tendenzen abfangen. Manche Teams sind super positiv oder, das ist häufiger der Fall, sehr selbstkritisch. Sollte euch das auffallen, dürft ihr das Team sachte darauf hinweisen.
- Schreit das nach Wiederholung? Oft bietet es sich an das Radar nach 3-4 Monaten nochmals in genau der selben Form zu wiederholen. So sieht das Team seinen Fortschritt ganz gut.
Und nun?
Ausprobieren würde ich sagen! Und gerne an dieser Stelle, in den Kommentaren, eure Erfahrungen mit den anderen Lesern teilen. Das wäre mir ein Fest!
Hallo Petra,
vielen Dank für diesen Artikel. Das Zitat „Das Auto in dem man sitzt kann man nicht anschieben“ für sich ist schon Klasse und drückt ein wichtiges Problem treffend aus.
Die beschriebene Methode werde ich sicher ausprobieren, denn sie ist m.E. sehr wertschätzend und mobilisiert die Teamkräfte. Klasse
Interessantes Tool auf jeden Fall!
Zwei Dinge habe ich mich beim Lesen allerdings gefragt:
1. Es gibt ja unterschiedliche Ansichten und Bedürfnisse, was die Rolle eines Product Owners angeht. Persönlich war es mir immer am Liebsten, möglichst stark als Teil des Teams zu handeln und auch wahrgenommen zu werden (in einer anderen Rolle). Dann ist man wenig Außenstehender und damit nicht der ideale Moderator. Das bringt mich zu..
2. Sollte so etwas nicht von einem Scrum Master gemacht werden?
Hi Jörg, freut mich sehr, wenn der Artikel gefällt und drücke die Daumen für deinen Testflug!
Hi Sebastian, beides gute Fragen/Anmerkungen. Wenn dir gelingt Teil des Teams zu sein ist das toll! Und Definitionen für PO/PM gibt es soviele wie Firmen auf dieser Welt. Zu 2.: wenn man den Luxus hat einen Scrum Master zu haben, dann kann der das natürlich auch machen. Wird aber leider wieder eher selten, dass die Firmen ausreichend Agile Coaches / Scrum Master beschäftigen.
Hallo Frau Wille,
zwei Anmerkungen:
Eine 10er-Skala hat keinen Mittelpunkt: 5 ist nicht die Mitte, sondern der obere Rand der unteren Skalenhälfte. Ungerade Zahlen (wie z.B. 7) haben eine Mitte, nämlich 4 (oberhalb und unterhalb gibt es jeweils 3 Werte)!
Eine „kurze Diskussion“ habe ich bei solchen Themen noch nie erlebt – oder das Wichtige wurde nicht ausgesprochen. Methodisch sinnvoll ist ein anderes Vorgehen: Jeder markiert für sich allein die Werte im „Teamradar“, anschließend werden die Bilder nebeneinander gestellt; dann macht eine Diskussion Sinn und liefert die Unterschiede in den Sichtweisen jedes Einzelnen. Daraus eine gemeinsame Basis zu entwickeln ist die eigentliche Herausforderung im Rahmen einer Teamentwicklung!
Über die Mitte der Zehnerskala bin ich auch zuerst gestolpert. Mit etwas Grübeln bin ich aber zu dem Schluss gekommen, dass das in diesem Fall schon in Ordnung ist:
Wenn ich einen Fragebogen habe und zehn (oder acht, sechs, vier…) Böppel zum Ankreuzen wähle, dann habe ich tatsächlich keine Mitte und zwinge den Probanden, einen Tendenz zu wählen. Wenn ich aber abstrakter unterwegs bin und keine komplette Skala aufmale (wie auf dem obigen Bild des Radars zu sehen), dann ist für den Teilnehmer (und für den Mathematiker) durchaus 5 die Hälfte von 10 und damit eine Möglichkeit zur tendenzlose Aussage gegeben. Es kommt also auf das Format an, ob die 10 eine Mitte hat, oder nicht :)
Vielen Dank für diesen Beitrag zum Thema Teamradar. Interessante Idee, ein Teamradar in den Alltag der Arbeitenden zu integrieren. Ich möchte gerne, dass sich mein Arbeitsteam besser unter einander versteht und möchte deshalb auch ein Teambuilding-Workshop mit ihnen absolvieren.