„Wie kann ich wissen, ob es gut läuft und was kann man im Zweifel tun?” – hat mich kürzlich eine Managerin gefragt, nach einem großen Retrospektive-Workshop, die Augenbrauen erwartungsvoll hochgezogen. Ob die Velocity gut sei, wie man sie steigern könne, wie man insgesamt besser werden könne, woran man das merke.
„Ganz einfach”, habe ich gesagt: Die Teams müssten das selbst regeln. Sie müssten einfach von alleine besser werden.
Bevor jetzt aber Enttäuschung über diese vermeintlich inhaltsleere Beraterfloskel aufsteigt, schiebe ich nach, jetzt, wie auch im Gespräch mit der Managerin: Unterstützt mit einem minimalem Team-Coaching – ich nenne diese Unterstützung Spotlight-Beratung. Ausdrücklich punktuell, begrenzt. Die erste Intervention ist, Teams mit der Erwartungshaltung zu konfrontieren, dass sie es selbst versuchen müssen, egal was, alles, immer!
Beobachtung ist mein erster Beitrag
Insofern würde ich ein Team zunächst einfach fragen, inwiefern man helfen könne, beim Besserwerden. Was genau die Teammitglieder denken, über die Zusammenarbeit. Was sie zum Beispiel mit ihrer Velocity anstellen wollen. Wie sie die Bewegungsdaten, die sie erzeugen und sammeln, also etwa Durchlaufzeiten von Anforderungen, Anzahl der Stories, Summe der Storypoints, Anzahl der Bugs oder Liegezeiten interpretieren und wie sie diese Erkenntnisse anwenden. Oder wie sie mit ihren Stakeholdern umgehen.
Wenn ich als Agile Coach für eine solche Spotlight-Beratung geholt werde, was würde ich also anbieten?
Zunächst würde ich einfach mal zuschauen, beobachten, so viel ich kann. Mitgehen ins Daily, Meetings miterleben, natürlich Review und Planning besuchen. Das Backlog inspizieren. Aber noch nichts weiter tun, nur beobachten. Ich würde anfangen, Fragen zu stellen, weil ich sehen wollte, wie das Team darauf reagiert. Antwortet immer der Product Owner? Oder gibt es einen Scrum Master, der die Szene dominiert? Wer ist die graue Eminenz, wenn es eine gibt?
Ich würde auch einfach fragen, wenn ich nicht verstünde, was gerade abläuft, oder warum. Interessant, zu erfahren, welche Antworten es darauf gibt – und besonders, wer darauf antwortet, wie die Reaktion auf diese Fragen ist. Aber es wird jemand antworten: Es gibt immer jemanden, der reden will. Genauso, wie immer jemand eine Idee hat.
Ohne Auftrag kein Coaching
Ich würde als nächstes anbieten, mit dem Team eine Retrospektive zu machen: Das wäre der erste Auftrag, den ich mit meinem Klienten formuliere. Darin zu sehen versuchen, inwiefern die Teammitglieder miteinander über ihre Zusammenarbeit sprechen. Inwiefern sie voneinander überhaupt wissen, wie sie sich selbst einschätzen würden, hinsichtlich der Zusammenarbeit. Oder inwiefern sie alleine die Meinung des engsten Kollegen einschätzen können. Ich würde versuchen einzubringen, gemeinsam auf die Zusammenarbeit aus der Stakeholder-Perspektive zu schauen: Was glauben sie, wie die Stakeholder womöglich auf die Arbeit ihres Teams blicken? Inwiefern man sagen könne, das Team sei an der Grenze zur Bestleistung?
Wahrscheinlich ist, dass damit schon etwas ausgelöst wird. Natürlich kein Umsturz, bewusst nicht. Sondern eine Gruppenübung. Ein Teammitglied soll sich fragen: Sehe ich, was die Stakeholder sehen? Verstehen die andern, was ich will? Inwiefern bringe ich rüber, was ich weiß – oder was ich möchte? Inwiefern verstehe ich, was mein Kollege denkt – über mich, über das Produkt, die Zusammenarbeit?
In allen Teams herrscht eine gewisse Vorstellung davon, was man so allgemein in einem Projekt über dessen Zustand annimmt und wer im alltäglichen Miteinander wofür da ist: Läuft es insgesamt gut oder schlecht? Wer ist der Vordenker, wer der Witzbold, wer der Mahner? Aber sind diese Annahmen oder Rollenzuweisungen jemals explizit vorgenommen worden? Ist der Witzbold mit seiner Rolle einverstanden oder warum hat er sie überhaupt? Oder hat jemand häufig einen von der Mehrheitsmeinung abweichenden Einspruch parat: Wird er damit noch gehört, oder heißt es nur: Er schon wieder, mit seinen Kommentaren? Gibt es Unterstützung, wenn Hilfe benötigt wird? Wie wird darüber gesprochen, dass man – natürlich! – weiter lernen muss, lernen möchte?
Schon nach dem ersten Workshop wird etwas anders werden. Es wird einen neuen Blick auf Kommunikationsmuster in der Gruppe geben. Ein neuer Blick auf Verhaltensmuster wird möglich werden, die eigenen und die der anderen.
Kontinuierliche Verbesserung ist Verhaltenstraining
Ziel ist, die kontinuierliche Verbesserung im Team neu anzuregen, ernstzunehmen; ein Klima zu erzeugen, das die Auseinandersetzung darüber erfreulich macht und das Voneinanderlernen in den Mittelpunkt stellt. Ideale Voraussetzungen sind meistens gegeben: Ein kleines, recht stabiles Team, regelmäßige Meetings, geschützte Räume der Meta-Kommunikation – der Retrospektive-Workshop. Ein Team, das regelmäßig, alle 14 Tage eine solche Retrospektive vornimmt, wird besser werden. Einmal, weil Feedback sowieso nicht optional ist, weil man das also ausnutzen könnte. Und, weil mit diesem regelmäßig eingeübten Verhalten jeder jedem helfen kann und Hilfe nicht nur potentiell, sondern direkt angewendet wird.
Als Agile Coach komme ich ausdrücklich mit dem Anspruch, dieses Spotlight anzumachen. Behutsame Expertenberatung habe ich gewiss auch dabei. Ich komme aber nicht, um ein Team dauerhaft coachen zu wollen.
In einem gruppendynamisch lernenden Team wird über kurz oder lang die Velocity besser werden. Es wird einen Sinn haben, dass das Team empirische Daten ermittelt, weil sie analysiert und interpretiert werden, weil daraus Hypothesen und Maßnahmen abgeleitet werden. Das Team wird besser werden, weil die Mitglieder daran glauben, die Team-Zusammenarbeit selbst steuern zu können, ganz einfach, indem sie sich fragen: Wie lernen wir am besten miteinander – und voneinander? Insofern können Sie wissen, dass es gut läuft, wenn Sie eine Antwort wie diese bekommen.
Danach könnten Sie das Spotlight neu ansetzen – und auf den Product Owner leuchten. Lesen Sie im nächsten Beitrag, wie ein Spotlight-Product Owner-Coaching gelingt.
