Wenn Sie diese Überschrift lesen, dann werden Sie sich wahrscheinlich sagen, dass Ihnen darüber niemand erzählen müsse. Das sei schließlich vollkommen klar. Nur meine ich mit einer offenen Kommunikation eben nicht nur, dass Probleme und Schwierigkeiten angesprochen und sachlich diskutiert werden, sondern auch, dass jeder, der sich kritisiert oder sonstwie angegangen fühlt, dies ebenfalls anspricht. Genau dort finden wir ein großes Risiko und gleichzeitig eine große Herausforderung.
In der Agilen Softwareentwicklung (hier meine ich nicht nur Scrum, hier meine ich alles) nimmt die Stärkung des Teams und die Kommunikation der Teammitglieder sowohl untereinander als auch mit den anderen Rollen eine zentrale Position ein. In Scrum sprechen wir im Rahmen der Retrospektive darüber, was wir nicht besonders gut gemacht haben, und wie wir diese Dinge verbessern können, und auch wenn wir uns dabei an die Regel halten, dass wir niemanden öffentlich persönlich kritisieren wollen, können wir dennoch nicht vermeiden, dass sich einzelne Personen direkt angesprochen fühlen.
Wenn Scrum Master oder Product Owner Probleme ansprechen, kann es auch passieren, dass sich einzelne Teammitglieder ungerecht behandelt oder missverstanden fühlen. Das ist eine ganz normale Reaktion, die uns immer wieder begegnen kann. Niemand hört gern Kritik, und im allgemein sind Menschen dann bemüht, sich aus dieser Kritik herauszunehmen oder sie als unberechtigt anzusehen. Das wissen wir bereits, doch was geschieht dann?
Derjenige, der sich unberechtigt kritisiert fühlt (ganz gleich, ob das wirklich so ist), beginnt damit, eine Mauer aufzubauen und sensibler auf einzelne Aussagen zu reagieren. Bei der nächsten Besprechung kommt wieder ein Problem auf den Tisch, und man fühlt sich erneut persönlich angesprochen. Ich habe sehr oft beobachtet, dass einzelne Teammitglieder dann im Laufe der Zeit übersensibel reagieren und sich ständig kritisiert und missverstanden fühlen. Von einem vertrauensvollen Verhältnis zwischen Product Owner oder Scrum Master und Entwickler kann dann nicht mehr gesprochen werden.
Wenn sich diese Sache fortsetzt (und der blinde Scrum Master das nicht bemerkt und rechtzeitig gegensteuert), wird der Entwickler irgendwann in Gleichgültigkeit fallen (auch schon oft gesehen) und schließlich entweder das Team oder gleich das Unternehmen verlassen. Solche Dinge geschehen rech häufig, und letzten Endes liegt es nur an ein paar dummen Missverständnissen.
Wir bekommen wir diese Gefahr also in den Griff? Als Scrum Master und Product Owner sollten Sie Ihr Team auch nach ihrer Meinung zu angesprochenen Problemem fragen und die nicht einfach nur kommentarlos (am besten mit fertiger Lösung) in den Raum stellen. Schildern Sie Ihre Sicht der Dinge, und fragen Sie dann das Team, ob sie das ebenso sehen. Sagen Sie nicht »Wir machen gerade dies und jenes falsch« (also in unausweichlicher Endgültigkeit), sondern formulieren Sie lieber »Ich sehe dies und jenes so, und denke, dass wir uns darüber Gedanken machen sollten. Wie seht Ihr das?«
Beziehen Sie Ihr Team mit ein und lassen Sie sie aktiv an der Lösung der Probleme teilhaben. Natürlich ist das in Scrum (und auch in allen anderen Agilen Vorgehensmodellen) so vorgesehen, aber trotzdem sieht man immer wieder Scrum Master und Product Owner, die ungefähr so formulieren: »Dies und jenes käuft nicht, wir machen das in Zukunft so und so, oder habt ihr eine andere Meinung?« Das ist eine Alibi-Frage und keine echte Miteinbeziehung des Teams. Natürlich sollen Scrum Master und Product Owner Vorschläge machen, wie man bestimmte Dinge verbessern kann, aber diese Vorschläge sind keinesfalls gesetzt. Vielleicht hat einer ihrer Kollegen eine bessere Idee.
Doch zurück zur eigentlichen Problematik: Fragen Sie Ihr Team nicht nur nach dessen Meinung, sondern ermutigen Sie Ihre Kollegen auch dazu, offen darüber zu sprechen, wenn sie Kritik für unangemessen halten oder sich persönlich kritisiert fühlen. Es läuft immer wieder auf den alten Grundsatz hinaus: Man kann über alles reden, man muss es nur tun.
Bis Ihre Kollegen soweit sind, dass sie wirklich offen mit Ihnen darüber sprechen, wenn sie Kritik für nicht angebracht halten, kann ein weiter Weg sein. Man kann es ganz kurz formulieren: Nehmen Sie Ihre Kollegen ernst, und lassen Sie es sie durch ihre Taten wissen, dass es so ist. Dann sind Sei auf einem guten Weg.
Das alles bedeutet jedoch keinesfalls, dass Product Owner oder Scrum Master in einem persönlichen Gespräch keine Kritik an einem Entwickler äußern sollten. Wenn einer der Kollegen schlampig arbeitet, dann wird das angesprochen. Das geschieht unter vier Augen und ohne Schreierei, aber es hat keinen Sinn, um den heißen Brei herum zu reden. Vergessen Sie nicht, dass Sie sich auch auf ein solches Gespräch gut vorbereiten sollten, was in diesem Beispiel bedeutet, dass Ihre Kritik auch belegbar sein muss. Äußern Sie also keine globale Kritik, sondern schildern Sie anhand von Beispielen das Problem. So wirken Sei auch der Gefahr entgegen, dass das Gespräch die Ebene der Sachlichkeit verlässt.
