Um es ganz kurz zu machen: nein. Dennoch möchte ich an dieser Stelle einige Gedanken zu diesem Thema mit Ihnen teilen, darunter auch ein ganz einfacher Check, mit dem Sie einen guten Eindruck davon gewinnen können, ob in ihrem Team alles in Ordnung ist.
Nach der Veröffentlichung der Google-Studie zum Zusammenhang zwischen hochperformanten Teams und Psychological Safety (oder früher auch Teamgesundheit) sprach und spricht plötzlich jeder von dieser scheinbar neuen und bahnbrechenden Erkenntnis, dabei arbeiten Scrum Master schon seit Jahren mit mehr als nur einem Auge auf diesem Aspekt (oder sollten es zumindest tun). Woher kommt also diese ganze Aufregung? Liegt es daran, dass so viele Manager, Scrum Master und Product Owner so ratlos sind?
Es scheint fast so zu sein, wenn man sich betrachtet, wie hungrig sich Teile der Community auf eine uralte Erkenntnis gestürzt haben, um sofort in ihren Teams den Fragebogen durchzuarbeiten, den man unter folgender Adresse finden kann: https://rework.withgoogle.com/guides/understanding-team-effectiveness/steps/foster-psychological-safety/.
Bitte verstehen Sie mich nicht falsch. Die Studie an sich ist sinnvoll und richtig, und an der habe ich nicht viel auszusetzen, ich habe nur Schwierigkeiten damit, dass eine Sache, die schon seit langer Zeit klar sein sollte, jetzt wieder in den Fokus rückt und neu erscheint.
Aber der Reihe nach:
Zuerst einmal scheint es ein größeres Problem damit zu geben, dass viele Teams entweder nicht gut funktionieren, oder dass sie von außen so wahrgenommen werden. Da drängt sich mir doch sofort die Frage auf, nach welchen Maßstäben man das bewertet? Ist das in irgendeiner Form anhand objektiver Messgrößen möglich? Ich meine, dass wir hier schon auf das erste Problem stoßen, dass sich in zwei unterschiedliche Aspekte aufteilen lässt: zum einen, ob das Team die richtigen Dinge tut, und zum anderen, ob das Team genug schafft. Diese beiden Dinge zu bewerten, überlasse ich Ihnen. Hinzu kommt noch die Frage, wie das Team sich selbst sieht, aber das ist eine ganz andere Baustelle. Ich denke, dass ich zu diesem ganzen Fragenkomplex noch einen eigenen Beitrag schreiben werde. Es wird zu umfangreich, an dieser Stelle alle Aspekte beleuchten zu wollen.
Gehen wir aber einmal davon aus, dass alle Beteiligten zu dem Schluss kommen, dass Irgendetwas in dem Team nicht richtig funktioniert, und dass es viel mehr und bessere Dinge schaffen könnte, weil wir wirklich gute Leute am Start haben. In dem Fall ist Psychological Safety noch lange nicht zwingend der Schlüssel zum Erfolg. Es ist nur eine von vielen Möglichkeiten, die in einer Entwicklermannschaft (oder in jedem anderen beliebigen Team) nicht funktionieren können. In unserem Kontext kann auch eine schlechte Kommunikation zwischen Product Owner und Team zu Problemen führen, unklare Anforderungen oder Erwartungen der Stakeholder, ungünstige Rahmenbedingungen, dumme Zufälle und viele Dinge mehr.
Wie kann ich aber ganz leicht testen, ob ich an dieser Stelle ein Problem habe? Die Antwort ist ganz einfach, wenn Sie täglich mit Ihren Kollegen zu tun haben. Ein Scrum Master sollte also durch bloße Beobachtung eine sehr gute Einschätzung abgeben können, wenn er über ein Mindestmaß an Empathie verfügt. Wenn Sie von außen beurteilen wollen, ob an dieser Stelle ein Problem vorliegt, haben Sie es sehr viel schwerer. Dann bleibt Ihnen zum einen die Möglichkeit, auf einen solchen Fragebogen zurückzugreifen, auch wenn ich der Meinung bin, dass die Ergebnisse hier sehr verzerrt sind und nur erste sehr grobe Hinweise liefern können. Oder Sie greifen auf einen Beobachter zurück, der näher am Team ist, was ich in jedem Fall empfehlen würde. Diese Erkenntnisse sind nuancierter und direkter. Für welchen Weg Sie sich auch immer entscheiden, wollen Sie die Sache angehen, müssen Sie nah ans Team. Es hilft nicht, hier irgendwelche Regeln aufstellen zu wollen. Solche Dinge wie Speech Token o.ä. bringen Sie nicht weiter, weil sie das Problem nicht an der Ursache fassen.
Zur Ursache aber später, zunächst wollen wir ja herausfinden, ob wir überhaupt ein Problem haben, bevor wir uns mit den Ursachen beschäftigen können. Wenn Sie dicht am Team sind (und als Scrum Master sollten Sie das sein), reicht eine simple Beobachtung in einem überschaubaren Zeitrahmen unter Beachtung folgender Fragen:
Fühlt sich jedes introvertierte Teammitglied sicher genug, einem extrovertierten Teammitglied zu widersprechen?
Fühlt sich jeder sicher genug, einen nicht vollständig ausformulierten Gedanken zu äußern?
Wird jede Idee, ganz gleich von wem sie stammt, ernst genommen?
Wenn Sie all diese Fragen mit Ja beantworten, können Sie sehr sicher sein, dass sie an dieser Front kein Problem in ihrem Team haben. Ich möchte das ganz kurz erklären.
Die erste Frage beschäftigt sich mit einfachen menschlichen Verhaltensweisen. Manche Kollegen sprechen mehr und sind »lauter« als andere. Wenn sie die »Stillen« bewusst oder unbewusst unterdrücken, haben wir ein Problem. Kommen alle zu Wort, und trauen sich auch, abweichende Meinungen zu äußern, ist alles ok. Wir werden niemals erreichen, dass ein sehr introvertierter und schweigsamer Kollege genau so viel sagt wie die Plaudertasche neben ihm, aber wir wollen erreichen, dass jeder etwas sagt, wenn er etwas zu sagen hat.
Die zweite Frage hat etwas mit dem Vertrauen in seine Kollegen zu tun. Schicke ich jeden Gedanken, den ich habe, erst einmal durch eine Reihe von internen Filtern, bis ich der Ansicht bin, dass er gut genug ist, ihn inmitten meiner Kollegen zu äußern, dann ist damit eine Furcht oder zumindest Unsicherheit verbunden. Wenn ich jedoch eine Idee äußern kann, sobald ich sie habe, dann habe ich genug Vertrauen zu meinen Kollegen, dass sie nicht wegen einer vielleicht »dummen« Idee über mich urteilen.
Die dritte Frage zielt auf das Gefälle im Team ab. In jeder Gruppe gibt es Hierarchien, auch wenn es keine Hierarchien gibt (sie verstehen hoffentlich, was ich meine). Erfahrene Kollegen haben ein anderes Standing als juniorige Entwickler, ihre Meinung wiegt oft schwerer. Dagegen kann man nichts tun, und an sich ist daran nichts Schlimmes. Das ist ein ganz natürlicher Prozess. Wichtig ist für uns nur, dass diese »Teamleader« nicht zu dominant werden. Jeder Gedanke, der auf den Tisch kommt, ist zunächst einmal gleichwertig zu betrachten, ganz gleich, von wem er kommt. Wenn das Team das beherzigt, ist auch an dieser Stelle alles in Ordnung.
Müssen Sie auf eine oder mehrere dieser Fragen mit Nein antworten, dann haben Sie auch gleich schon einen ersten groben Hinweis auf die Ursache des Problems. Das können auf der einen Seite zu dominante Mitglieder sein, Fehler im System, das unsichtbare Hierarchien fördert, statt sie aufzulösen, oder auch eine Teamzusammensetzung, die fachlich nicht zusammenpasst.
Mit dem Tets ist allerdings nur der erste Schritt auf einem sehr langen Weg getan. Veränderungen sind hier sehr mühsam und langwierig. Die Kollegen von Google haben unter der Adresse https://docs.google.com/document/d/1PsnDMS2emcPLgMLFAQCXZjO7C4j2hJ7znOq_g2Zkjgk/edit ein Google-Docs-Dokument abgelegt, das einige Hinweise enthält, wie Sie als Manager, Product Owner oder Scrum Master mit einer solchen Situation umgehen können. Erwarten Sie hier jedoch nicht zuviel. Ein solches Dokument kann immer nur ein paar allgemeine Anweisungen und Richtlinien enthalten, ihre Maßnahmen werden jedoch Zeit, Geduld und immer auch eine individuelle Herangehensweise beinhalten müssen. Veränderungen in einem so sensiblen Feld sind langwierig und lassen sich in keinem Fall erzwingen. Wir müssen häufig sowohl dominante Personen (sanft) bremsen, als auch introvertierte (zum Teil ängstliche) Personen stärken und bestärken.
Hier findet Ihr eine Übersicht von Videos zu diesem und anderen Themen
Als Scrum Master sind sie gefordert, eben diese Dinge zu tun, dafür zu sorgen, dass auch die leisen Töne gehört werden, und dass alle Meinungen und Ideen gleich wichtig sind. Wir werden dies nicht durch das Aufstellen von Regeln erreichen. Dies erfordert eine Veränderung auf einer anderen Ebene, die sowohl Akzeptanz als auch damit einhergehend Verhalten einschließt.
Ich muss Sie enttäuschen, wenn Sie erwarten, dass ich Ihnen hier eine allgemeingültige Lösung präsentiere, dazu sind die Ausgangssituationen zu unterschiedlich, und jeder Mensch reagiert anders.
An allererster Stelle steht allerdings immer das Verstehen, wo die eigentlichen Probleme liegen. Das wird nur sehr schwer durch Fragen gelingen, weil die beteiligten Personen meist selbst nicht wissen, was sie eigentlich tun, und wie sie auf andere wirken. Es bleibt also auch hier nur der Weg über Beobachtung und (vorsichtige) Gespräche. Fallen Sie nicht mit der Tür ins Haus. Es kann gut gehen, aber die Gefahr, dass einige Personen dann abblocken ist zu groß. Das würde Ihnen alles nur noch viel schwerer machen.
Wenn Sie ein oder mehrere Probleme innerhalb des Teams identifiziert haben, können Sie langsam zum nächsten Schritt übergehen und sich fragen, wie das Idealbild genau aussehen soll. Die Aussage, dass alle alles sagen können sollen, ist dabei viel zu vage. Sie haben eine überaus dominante Person in ihrem Team identifiziert und vielleicht zwei weitere, die sich zu leicht unterbuttern lassen. Ein weiterer trägt vielleicht eine gleichgültige Mine zur Schau. Wie sieht in diesem Setting eine Verbesserung konkret aus?
Erst wenn Sie das wissen, können Sie damit beginnen, Veränderungen herbeizuführen. Auf der einen Seite ist das die Leitung der Meetings, in der Sie ausgleichen und dafür sorgen, dass alle zu Wort kommen, aber das genügt natürlich nicht. Sie allein können kaum eine Änderung herbeiführen, weil in diesem Fall alles erzwungen wäre. Eine Änderung muss von den Teammitgliedern selbst kommen und gelebt werden. Sie können dies begünstigen und fördern.
Ein Weg (auch wenn viele jetzt aufschreien werden) ist es, mit den Kollegen über die anderen Kollegen zu sprechen. Wichtig ist, dass Sie dabei nüchtern und ausgleichend bleiben. Es ist immer schwierig an einem Tisch miteinander über ein Problem zu sprechen. Einfacher ist es oft, mit einer Person – sachlich – über eine andere zu sprechen. In diesem Setting können Sie Verständnis für die Sichtweise und die Situation des anderen schaffen.
Ja ich weiß, wir sprechen miteinander, nicht übereinander. Ich meine, man kann durchaus übereinander sprechen, die Frage ist nur, wie wir das tun. Unser Ziel ist vor allem Verständnis. Wenn ein Kollege versteht, wie ein anderer sich fühlt, dann wird er von sich aus einige Dinge überdenken und von sich aus einige Dinge ändern. Diese Entwicklung ist immer gesünder und meist auch zielführender als eine von außen bzw. einer anderen Person initiierte Veränderung.
Zum Schluss: Bitte denken Sie immer daran, dass Sie viele Optionen haben, wenn Sie mit Ihrem Team vor einem Problem stehen. Testen Sie den Aspekt Psychological Safety. Wenn Sie zum Schluss kommen, dass hier alles in Ordnung ist, Haken dran und die nächste Möglichkeit prüfen. Es gibt so viele Dinge, die in einem Team schief laufen können, dass es fatal wäre, sich hier nur auf eine mögliche Ursache zu konzentrieren.
Folgt mir auf twitter, um keine neuen Beiträge zu verpassen.
