Wie geht man mit einer Situation um, wenn ein Teammitglied nicht an Retrospektiven teilnehmen möchte?

Das Team arbeitet einige Monate zusammen. Sie liegen irgendwo zwischen Norming- und Performing-Phase. Alle Teammitglieder sind begeistert von ihrer Arbeit und dem Produkt, an dem sie arbeiten. Einer der Teammitglieder sagt, dass er nicht von Retrospektiven profitiert. Er war bei vielen von ihnen (zwischen 30-50) in verschiedenen Teams und kam zu dem Schluss, dass er stattdessen lieber entwicklerbezogene Arbeit macht.

Gleichzeitig ist er kooperativ – hilft anderen, respektiert Teamnormen, nimmt aktiv an anderen Meetings teil usw. Er ist auch ein guter Ingenieur. Das Team möchte ihn nicht verlieren; mit anderen Worten, eine Lösung, ihn aus dem Team zu entlassen, ist nicht akzeptabel.

Wie denkt der Rest des Teams über den Nutzen von Retrospektiven? Wenn sie sie nützlich finden und seinen Beitrag schätzen und er anderen helfen möchte, dann geht es nicht um seinen Nutzen, sondern um ihren. :) Ein Ansatz, den ich mit Teammitgliedern verwendet habe, die keinen Wert in etwas sehen, das das Team schätzt, besteht darin, sie herauszufordern, ihr eigenes Format oder ihren eigenen Prozess zu erstellen, von dem sie glauben, dass er für alle Beteiligten funktionieren würde .
Warum sagt er, er profitiere nicht von Retrospektiven? Er scheint kein Problem mit dem Format der anderen Zeremonien zu haben, also was macht Retrospektiven problematisch? Außerdem stimme ich dem Kommentar von @JeffLindsey zu – was denkt das andere Team über Retrospektiven? Haben sie auch das Gefühl, dass sie nicht profitieren? Vielleicht gibt es etwas an Ihrem retrospektiven Prozess, das verbessert werden kann.
Liegt es daran, dass er der Meinung ist, dass die Aktionselemente aus einer Retrospektive nie umgesetzt werden (insbesondere diejenigen, bei denen die Änderung außerhalb des Einflussbereichs des Teams liegt). Ich habe das gesehen und ehrlich gesagt konnte ich es nicht vollständig lösen.
Bitte gehen Sie davon aus, dass das retrospektive Verfahren nicht fehlerhaft ist. 5 Teammitglieder profitieren davon, nur 1 nicht.
„Bitte gehen Sie davon aus, dass der retrospektive Prozess nicht fehlerhaft ist.“ Die allgemeine Idee von Agile ist, dass alles verbessert werden kann – das bedeutet nicht unbedingt, dass er fehlerhaft ist.
@SpoonerNZ Das stimmt. Eine Verbesserung dieser Situation könnte darin bestehen, dass dieses eine Teammitglied nicht am Retrospektive-Meeting teilnimmt.
Wenn Sie wirklich denken, dass es eine Lösung gibt, posten Sie sie als Antwort auf Ihre eigene Frage. Ich halte das nicht für eine gute Lösung, da dieses Teammitglied dann nichts über Änderungen des Teams an seiner Arbeitsweise weiß oder, was noch wichtiger ist, die Gründe dafür nicht versteht. Es schafft auch einen Präzedenzfall für "Unsere Meetings sind nicht wichtig, sagen Sie einfach, dass Sie nicht kommen möchten, und wir werden uns nicht darum kümmern". Ich vermute, dass dies als Lösung im Allgemeinen negativ gestimmt wird.
@SpoonerNZ Ich dachte nicht, dass es eine gute Lösung ist. Es ist nur eine Idee. Mein Punkt war eher: Eine Verbesserung muss nicht immer bedeuten, allgemeine Richtlinien zu befolgen, was in diesem Fall "das ganze Team sollte teilnehmen" bedeutet. Ich denke auch, dass es kurz- und langfristige Verbesserungen gibt. Kurzfristig kann dieses Setup nur einige Spannungen lösen und langfristig könnte ein Teammitglied seine Meinung ändern, weil er Retros eigentlich vermissen würde :-)

Antworten (5)

Die übliche Praxis ist, sie zu bitten, dem Meeting beizutreten, sie müssen nichts tun, außer gelegentlich den Diskussionen zuzuhören - sie können sogar in der Ecke sitzen. Wenn sie in eine Diskussion einsteigen möchten, ändert sich diese Vereinbarung und sie müssen bis zum Ende der Sitzung teilnehmen. Darauf muss man sich von Angesicht zu Angesicht einigen.

Ich habe mit dem Team und dem oben genannten Entwickler gesprochen und wir sind zu einer ähnlichen Lösung gekommen, wie Sie vorgeschlagen haben. Momentan ist er bei Retrospektiven dabei, sitzt aber in der Ecke und arbeitet an seinen Sachen. Immer wenn er etwas Interessantes hört, mischt er sich ein. Außerdem ist er mit allen Änderungen am Prozess einverstanden, die ihn betreffen würden, aber er hat sich nicht geäußert.

Es klingt, als wäre es ein guter Zeitpunkt für eine „Retrospektive der Retrospektiven“. Beginnen Sie mit einer Erinnerung an den Zweck einer Retrospektive und was das Team daraus zu ziehen versucht. Überprüfen Sie, wie das Team in der Vergangenheit Retrospektiven hatte, was gut lief, was verbessert werden kann usw. Möglicherweise ist das Format der Meetings das Problem, und andere könnten ähnliche Gefühle haben, wenn sie eine bessere Chance haben, sie auszudrücken.

Das einzige Mal, dass ich eine ähnliche Situation gesehen habe, war, dass die Retrospektiven immer die gleichen organisatorischen Probleme aufgeworfen haben und wir als Team die Situation nicht verbessern konnten. Wenn dies der Fall ist, kann ich leider nicht helfen - ich habe die Organisation verlassen!

Das ist nicht der Fall. Ein erwähntes Teammitglied sagt nicht, dass retrospektive Ergebnisse schlecht sind. Er versucht auch nicht, den Prozess zu untergraben. Er sagt nur, dass er seine Zeit gerne mit der Entwicklung verbringen möchte, nicht mit der Retrospektive, weil er seiner Meinung nach mehr Wert liefert. Außerdem ist er, wie ich in der Frage geschrieben habe, freundlich, gut ausgebildet (kein Star), hilfsbereit usw.
Aber ich würde zustimmen, dass dieser Ansatz ein guter Ausgangspunkt wäre, um eine Inspektions- und Anpassungsschleife zu reparieren.

Sie können keine Veränderungen vornehmen, ohne Veränderungen anzunehmen

Sie haben sich eingeklemmt. Allein die Tatsache, dass Sie diese Frage stellen, weist darauf hin, dass es Reibungen zwischen diesem Entwickler und dem vom Team gewählten Prozess gibt, obwohl Sie die Art des Problems, das dadurch entsteht, nicht wirklich definiert haben.

Sie möchten diese Reibung auch lösen, ohne dass sich der Entwickler an einen teamorientierten Prozess anpassen muss, und sind daher bereit, den Prozess zu unterbrechen, anstatt anzuerkennen, dass dieses Teammitglied möglicherweise nicht hineinpasst. Sie können einfach nicht den Status quo aufrechterhalten und gleichzeitig diese Spannungen lösen.

Sie haben das Scrum-Framework für diesen Entwickler im Wesentlichen optional gemacht, versuchen aber, Ihren Kuchen zu haben und ihn auch zu essen. Wenn Sie jedem Einzelnen im Team erlauben, die Teile des Frameworks auszuwählen, die ihm gefallen und denen er bereit ist, zu folgen, dann laden Sie nicht nur Scrum-Buts ein , sondern verzichten im Wesentlichen auf die Strenge (und höchstwahrscheinlich die Vorteile) von Ihre Scrum-Implementierung.

Es ist in Ordnung zu sagen, dass ein bestimmtes Framework für Ihr Team und Ihre Organisation nicht funktioniert; es gibt sicherlich noch andere Frameworks zur Auswahl. Sie müssen jedoch über ein Projektmanagement-Framework mit streng durchgesetzten Kontrollen verfügen, wenn Sie keine Anarchie einladen möchten.

Prima Donnas sind nicht agil

Sie haben jemanden, der nicht in Ihren teamorientierten Prozess passt. Das lässt Ihnen die folgenden Optionen:

  1. Bewerten Sie das Format und die Effektivität Ihrer Retrospektiven neu und optimieren Sie dann die Zeremonie, bis sie für alle von Nutzen ist.
  2. Bereitstellung von Schulungen, Anreizen und Konsequenzen, um sicherzustellen, dass alle Teammitglieder effektiv an dieser obligatorischen Scrum-Zeremonie teilnehmen.
  3. Verzichten Sie auf den Scrum-Prozess, wenn Sie nicht ohnehin vorhaben, ihm zu folgen.

Bei Scrum geht es um Teamarbeit. Einzelkämpfer, auch wenn sie technische Rockstars sind, sind Gift für agile Prozesse.

Retrospektiven werden vom Scrum Framework gefordert

Einer der Teammitglieder sagt, dass er nicht von Retrospektiven profitiert.

Diesem Teammitglied fehlt der Punkt. Ob er von der Retrospektive profitiert oder nicht, ist unerheblich; Die eigentliche Frage ist, ob das Team von den Retrospektiven profitiert oder nicht.

Darüber hinaus ist die Sprint-Retrospektive eine formal definierte Scrum-Zeremonie , die für den Inspektions- und Anpassungsprozess unerlässlich ist. Das bedeutet, dass Sie Retrospektiven durchführen müssen , wenn Sie sich an das formale Scrum-Framework halten. Das Versäumnis, effektive Sprint-Retrospektiven abzuhalten, verringert die Effektivität des Frameworks und widerspricht den agilen Kernprinzipien.

Schließlich müssen Sie sorgfältig überlegen, ob Sie bereit sind, Ihren Prozess von jemandem kapern zu lassen, der nicht bereit ist, ein voll funktionsfähiges Mitglied des Teams innerhalb eines teamorientierten agilen Rahmens wie Scrum zu sein. Wenn Sie zulassen, dass dieses Teammitglied dem Rest des Teams den Prozess diktiert oder die Elemente des Scrum-Frameworks, denen es folgen möchte, einseitig auswählen und auswählen, dann ist dies weder agil noch Scrum.

Wenn Sie als Scrum Master Ihre Verantwortung für die Leitung des Scrum-Prozesses aufgeben, um eine Person zu besänftigen, haben Sie Ihre Aufgabe nicht erfüllt. Stattdessen sollten Sie sicherstellen, dass die Retrospektiven einen Mehrwert für das Team darstellen und dass das Team jederzeit als Team funktioniert.

Nichts für ungut, aber das ist eine Menge absoluter Ratschläge und wir haben sehr wenig Kontext. Ich wünschte, er würde mit mehr Informationen antworten! :)
Eine gründliche Antwort :-) Ich verstehe, dass der Scrum Guide sagt, dass das ganze Team teilnehmen sollte. Ich habe meine Frage absichtlich nicht mit Scrum markiert oder Scrum selbst erwähnt.

Welches Format verwenden Sie für Ihre Retrospektiven? Meiner Erfahrung nach kann eine Änderung des Formats die Teilnahmequoten verbessern. Wenn Sie nur ein „Rad der Veränderung“ verwenden und erwarten, dass Teammitglieder offen vor ihren Kollegen sprechen, versuchen Sie, es ein wenig zu ändern. Erstellen Sie Histogramme für Schwerpunktbereiche und bitten Sie die Teammitglieder, Notizen darüber zu platzieren, wie gut sie (persönlich) die Leistung in diesem Schwerpunktbereich sehen. Alternativ können Sie auch den „Once Upon a Retrospective“-Ansatz ausprobieren, wie er auf StickyMinds.com beschrieben wird. Stellen Sie vor allem sicher, dass Sie alle vorgeschlagenen Änderungen dokumentieren und Aktionspunkte den Teammitgliedern zuweisen und dann vor oder zu Beginn der nächsten Retrospektive nachverfolgen.

Ich gehe normalerweise für Start Stop Continue, führe aber von Zeit zu Zeit andere Formate ein (z. B. jede 3. Retro). Das ist eine gute Lösung, danke :-)

[Geändert] Wie unten erwähnt, habe ich die Reaktionen falsch verstanden, weil ich annahm, dass das Nichterfüllen von Aktionen der Hauptgrund für die Nichtteilnahme war. Die folgende Antwort ist daher möglicherweise nicht zum Thema, aber ich habe sie hier gelassen, da ich der Meinung bin, dass sie für die Leser dieses Threads dennoch nützlich sein könnte.

Ich denke, das Teammitglied hat Recht, wenn es das Gefühl hat, dass die Aktionen, die aus einer Retrospektive hervorgehen, nicht umgesetzt werden; das ist ein ernstes Problem.

Wurde dies untersucht, sind die Ursachen bekannt? Das wäre das erste, was ich tun würde.

Wenn die Aktionen nicht ausreichend ausgeführt werden, müssen Sie die Linie stoppen und das angehen. Gründe, die ich sehe, warum keine Maßnahmen ergriffen werden, sind:

Aktionen sind zu vage, die Leute wissen nicht, was sie tun sollen. Aktionen sind nicht sichtbar, Menschen neigen dazu, sie bei täglichen Aktivitäten zu vergessen. Es ist unklar, warum die Aktion durchgeführt werden sollte, da das Problem, das sie lösen sollte, fehlt. Es gibt zu wenig Kultur für kontinuierliche Verbesserung.

All dies kann gelöst werden, aber Sie müssen wissen, warum es nicht genug Nachverfolgung gibt, um es anzugehen.

Der Autor der Frage gibt nicht an, dass dieses Teammitglied der Meinung ist, dass auf die aus Retrospektiven resultierenden Aktionen nicht reagiert wird.
Mein Fehler, ich habe dies in einer früheren Diskussion erwähnt und falsch verstanden, als ob es von Bartek Kobyłecki stammt, der die Frage gestellt hat. Danke für den Hinweis jordix!
Wie geht man mit einer Situation um, wenn ein Teammitglied nicht an Retrospektiven teilnehmen möchte?
AntwortenHierDatenschutz-Bestimmungen1y, 0v