Teamcoaching in der Softwareentwicklung

Seite 2: Beispiel

Inhaltsverzeichnis

Teamcoaching hilft, gemeinsam mit allen Teammitgliedern den Sinn für die oben angeführten Werte zu schärfen, die im Umgang miteinander zu kurz kommenden Werte zu identifizieren, an ihnen zu arbeiten und diese Probleme nachhaltig zu lösen. Ein Teamcoaching ist daher keine einmalige Veranstaltung, sondern vielmehr ein Prozess, den das Team über einen längeren Zeitraum durchläuft. Abbildung 2 zeigt den typischen Ablauf eines Teamcoachings.

Ablauf eines Teamcoachings (Abb. 2)

Im Folgenden werden nun die einzelnen Phasen erläutert und anhand eines fiktiven Beispiels vertieft.

Der Prozess eines Teamcoachings beginnt üblicherweise mit einem Gespräch der Coaches mit dem Sponsor des Teamcoachings, das kann beispielsweise der Linienvorgesetzte des Teams oder der Geschäftsführer der Organisation sein. Darin lernen die Coaches die Erwartungen des Sponsors kennen und legen mit ihm den Rahmen fest, innerhalb dessen das Teamcoaching stattfinden wird (Zeitraum, Umfang, Räumlichkeiten etc.).

Des Weiteren ist es wichtig, mit dem Sponsor ein klares Bild über das Dreiecksverhältnis zwischen Sponsor, Team und Coaches zu schaffen. Für den Erfolg des Teamcoachings ist es wichtig, dass es zwischen den Coaches und dem Team ein Vertrauensverhältnis gibt, das nicht durch eine Berichtspflicht der Coaches an den Sponsor verletzt werden darf. Oft wird als Regelung daher vereinbart, dass der Sponsor von den Coaches über die Inhalte des Teamcoachings nur Informationen bekommt, die diese zuvor mit dem Team abgestimmt haben.

Beispiel: Im Gespräch mit der Sponsorin, der Geschäftsführerin der Organisation, gibt diese den Coaches einen ersten Überblick über die Historie des Teams sowie die Einbettung des Teams in die Organisation. Die Organisation ist ein kleines Softwareentwicklungsunternehmen mit einem einzelnen Scrum-Team, das aus insgesamt acht, durchwegs männlichen Mitgliedern besteht. Scrum wird im Unternehmen seit vier Jahren angewendet, der Kern des Scrum-Teams besteht ebenso lange.

Die Sponsorin meint, dass seit Einführung von Scrum zwar durch die hohe Transparenz des Prozesses und durch das iterativ-inkrementelle Vorgehen wesentliche Verbesserungen erreicht werden konnten, sie sich aber trotzdem mehr erwartet hätte. Als Problem erwähnt sie, dass das Scrum-Team oft seine Sprint-Absichten nicht einhalten könne und dies nur Schulterzucken bei den Team-Mitgliedern auslöse.

Als Rahmen vereinbaren die Sponsorin und die Coaches für die nächsten drei Monate einen halbtägigen Vorbereitungsworkshop, eine anderthalbtägige Coaching-Klausur und zunächst einmal einen zweistündigen Nachbereitungs-Workshop.

Wenngleich der Sponsor den Rahmen für das Teamcoaching vorgibt: Die Themen, an denen im Teamcoaching gearbeitet werden soll, bestimmt das Team. Diese Selbstbestimmung ist ein wesentlicher Faktor für das Gelingen. Dazu findet ein Workshop des Teams mit den Coaches statt. Dabei gibt es von den Coaches Inputs zu den hilfreichen Werten in einem Team sowie zu ihrer Bedeutung und ihrem Zusammenspiel. Das Team selbst versucht daraufhin, die Problemfelder zu identifizieren, an denen es in der Folge arbeiten möchte. Dieser Workshop dauert in der Regel einen halben Tag.

Beispiel: Der vorbereitende Workshop mit dem Team findet in einem Besprechungsraum der Organisation statt. Es nimmt das gesamte Scrum-Team daran teil, inklusive Product Owner und Scrum Master.

Die Coaches stellen zunächst die in diesem Artikel vorgestellten Werte, ihre Bedeutung und ihren Bezug zueinander vor. Daraufhin werden die Teammitglieder in einer Einzelarbeit gebeten aufzuschreiben, für jeden der Werte auf einer Skala von 0 (wird im Team gar nicht gelebt) bis 10 (wird ideal gelebt) zu bewerten, wie dieser im Team täglich gelebt wird. Die Einzelbewertungen werden anschließend auf einem Flipchart zusammengeführt. Symbolisch sind diese in Abbildung 3 zusammengefasst.

So sieht das Team die acht Werte aktuell gelebt (Abb. 3)

Es zeigt sich also, dass alle Team-Mitglieder folgende Werte tendenziell schlecht bewertet haben: Fokus, Mut, Offenheit, Feedback und Commitment. Die Coaches versuchen anschließend, die einzelnen Teammitglieder zu Erklärungsversuchen für diese schlechten Bewertungen anzuregen. Diese kommen nur zögerlich. Die Coaches gewinnen den Eindruck, dass die Teammitglieder wenig Übung in solcher Kommunikation haben und sich nicht recht trauen, ihre Meinung zu äußern.

Im Laufe des Workshops stellt sich dann noch heraus, dass die Retrospektive, eines der vier von Scrum vorgegebenen regelmäßigen Meetings, nur selten stattfindet, da es dazu laut Scrum Master "kaum Bedarf" gebe. Die Coaches vereinbaren mit dem Team, sich in der Coaching-Klausur mit den schlecht bewerteten Werten auseinanderzusetzen.

Auf Basis dieser Vorarbeiten des Teams bereiten die Coaches einen individuell abgestimmten Ablauf für eine ein- oder auch mehrtägige Klausur vor. Um ausreichend Abstand zur täglichen Arbeit zu erreichen und einen geschützten Raum für die Arbeit an den Problemfeldern zu bieten, sollte die Klausur räumlich außerhalb der Organisation stattfinden. In der Klausur arbeitet das Team begleitet von den Coaches in einem Mix aus fachlichen Inputs, systemischen Anregungen, spielerischen Elementen und vielen Gelegenheiten zur Reflexion an seinen Problemfeldern.

Das Ergebnis der Klausur ist eine Liste von Zielen und Vereinbarungen des Teams für die zukünftige Zusammenarbeit. Diese Zielearbeit fällt den Teams üblicherweise nicht leicht. Ihr sollte daher in der Klausur ausreichend Zeit und Raum eingeräumt werden.

Beispiel: Die eineinhalbtägige Coaching-Klausur findet in einem abgelegenen Berggasthof statt, den die Teilnehmer in einer halben Autostunde erreichen können. Sie übernachten im Berggasthof und haben daher am Ende des ersten Klausurtag die Gelegenheit, die Erlebnisse informell am Abend weiter zu reflektieren.

Die Coaches entwickeln folgendes Design für die Klausur: Am ersten Seminartag werden die Teilnehmer in zwei Übungen (eine im Freien, eine im Gasthof) herausfinden, wie die Rollen im Team besetzt sind beziehungsweise wie sich die Dynamik im Team entwickelt (wer plant, wie werden die Rollen verteilt, wie schnell kommt das Team ins Tun, wer achtet auf die Beziehungen im Team etc.) oder wie die Teammitglieder miteinander in einer Stresssituation umgehen, insbesondere was den Umgang mit Fehlern betrifft. Zu den Übungen wird es ausführliche Reflexionsrunden geben, die die Coaches anleiten und in denen sie versuchen, wirklich alle Teilnehmer zu aktivieren. Unterstützt werden soll die Lernerfahrung aus diesen Übungen durch Inputs der Coaches zu den Themen Feedback (Geben und Nehmen) und typische Dysfunktionen im Team (mangelndes Vertrauen, Angst vor Konflikten etc.).

Am zweiten Seminartag soll das Scrum-Team dann im geschützten Raum der Klausur eine Retrospektive zum letzten Sprint des Teams abhalten und dabei versuchen, die Lernerfahrungen des ersten Seminartags einzubringen.

Im Laufe der Klausur beobachten die Coaches ein Sich-Öffnen der Teammitglieder. Mit zunehmender Zahl an Gelegenheiten für Reflexion und das Artikulieren der eigenen Meinung machen das auch immer mehr Teammitglieder. Die Atmosphäre in der Klausur ist von Aufmerksamkeit und Wertschätzung geprägt. Es hat für die Coaches den Anschein, dass hier ein Stein ins Rollen kommt.

Im abschließenden Teil der Klausur vereinbaren die Teilnehmer für sich folgende konkrete Ziele:

  • Das Team wird sich in den nächsten zwei Wochen Regeln geben, die es ermöglichen sollen, Phasen des ungestörten Arbeitens mit Phasen des Informationsaustausches abzuwechseln, insbesondere zwischen Product Owner und Teammitgliedern. Diese Regeln werden an zentraler Stelle im Teamraum visualisiert.
  • Das Team wird sich ab sofort gegenseitig darin bestärken, die in der Klausur kennen- und schätzen gelernten Praktiken zum Geben und Nehmen von Feedback, zur Abfrage von Meinungen eher stiller Teammitglieder sowie zur Konsensbildung in den Scrum Meetings anzuwenden. Zur Unterstützung wird das Team einige Schlagworte dazu neben dem Scrum Board visualisieren.
  • Das Team wird nach jedem Sprint wieder eine Retrospektive abhalten und den Scrum Master bei der Vorbereitung unterstützen, da als einer der Gründe für die stiefmütterliche Behandlung der Retrospektive eine zeitliche Überlastung des Scrum Master identifiziert wurde.