Team-Coaching in der agilen Softwareentwicklung

Die klassische Softwareentwicklung folgt einem Plan, der zu Beginn des Projekts festgelegt wird. Im Lastenheft beschreibt der Auftraggeber möglichst präzise die Gesamtheit seiner Anforderungen. Diese werden vom Auftragnehmer in ein Pflichtenheft übersetzt, das die geplante Lösung für diese Anforderungen beschreibt.

Dieses Pflichtenheft segnet der Auftraggeber ab, anschließend entwickelt der Auftragnehmer die Lösung, wie in diesem Pflichtenheft zugesagt. In einem nicht sichtbaren Prozess entsteht die fertige Software. Änderungen im Verlauf der Projektentwicklung sind dabei nicht vorgesehen.

Hier finden wir die größten Unterschiede zu agilen Vorgehensweisen. Es ist essentiell für den Erfolg eines Projekts, dass Auftragnehmer und -geber im stetigen Austausch stehen. Es gibt einen groben Plan über das gesamte Projekt. Einzelne Inhalte hingegen werden im gemeinschaftlichen Austausch nach und nach konkretisiert.

Durch diese Vorgehensweise gibt es während des Projekts die Möglichkeit, Inhalte anzupassen und auf neue Anforderungen zu reagieren. Das wird beispielsweise durch Entwicklungen am Markt genauso wie durch den laufenden Erkenntnisgewinn aller in das Vorhaben eingebundener Personen notwendig. Dadurch entsteht ein schrittweise reifendes Produkt, das den individuellen Kundenanforderungen entspricht.

Eine weitere Forderung der agilen Vorgehensweise ist es, Software in kleinen Häppchen zu entwickeln, die arbeitsfähig sind. So kann der Kunde Teile der Software produktiv nutzen, bevor das ganze Projekt abgeschlossen ist. Dadurch entsteht ein Controlling-Mechanismus, der in knappen Schritten den Fortschritt eines Projekts misst. Durch regelmäßige Feedbackschleifen werden Probleme sowie neue Anforderungen früh sichtbar, sodass rechtzeitig darauf reagiert werden kann.

Das Wort Scrum kommt aus dem Rugby und bedeutet soviel wie „Gedränge“. Es ist ein spezieller Spielzug, bei dem zwei Mannschaften in einer engen Teamformierung um den Ball kämpfen. Scrum ist ein Framework, das die Zusammenarbeit selbstorganisierter Teams und die Prozessverbesserung durch zentrale Feedbackschleifen regelt.

In Scrum wird in Sprints gearbeitet. Sprints sind meist 14-tägige Arbeitsabschnitte. Ziel ist es, jeweils am Ende einer solchen Zeiteinheit ein neues Product Increment bereitstellen zu können, das ist eine neue Version der Software, die idealerweise vom Kunden bereits wertschöpfend genutzt werden kann.

Innerhalb eines Sprints gibt es Aktivitäten für die Planung (Sprint Planning), die laufende Abstimmung (Daily Scrum), das Feedback vom Kunden (Sprint Review) und die Prozessverbesserung (Sprint Retrospektive).

Scrum definiert drei Rollen, aus denen das Scrum-Team besteht, das gemeinsam für den Erfolg eines Projekts zuständig ist:

Der Product Owner ist das Bindeglied zwischen Developer Team und den Kunden. Er ist für den geschäftlichen Erfolg des Produkts verantwortlich. Der Product Owner arbeitet eng mit Kunden, Anwendern und anderen Stakeholdern der Software zusammen und konsolidiert ihre Wünsche und Aufträge. Der Product Owner ist dafür verantwortlich, WAS die Software leisten können soll.

Das Developer Team verantwortet, WIE die Software erstellt wird. Es besteht in der Regel aus fünf bis neun Personen. Seine Kernkompetenz ist die Umsetzung der vom Product Owner koordinierten Anforderungen in qualitativ hochwertige und wertschöpfende Software (Product Increments). Ein wichtiges Prinzip von Scrum ist die Selbstorganisation des Teams. Es gibt keinen Teamleiter, der dem Developer Team sagt, wie genau es die Arbeit organisieren soll.

Der Scrum Master agiert als Team-Coach. Er kümmert sich darum, dass das Developer Team effizient und effektiv in Selbstorganisation arbeiten kann. Der Scrum Master fördert die Reflexion und Entwicklung innerhalb des Teams und tritt dabei als Coach, Mediator, Trainer, Moderator und Mentor auf.

Eine weitere Aufgabe ist, das Developer Team vor Störungen von außen zu beschützen, d.h., er stellt sicher, dass das Team einen geschützten Raum und die Zeit hat, in dem es seine Arbeit erledigen kann. Der Scrum Master führt das Team ohne disziplinarische Macht und inhaltliche Verantwortung.

In der agilen Softwareentwicklung haben sich eine Reihe von Werten herauskristallisiert, die als Grundlage für eine gedeihliche Arbeit stehen. Es handelt sich dabei um Fokus, Offenheit, Wertschätzung , Mut, Kommunikation, Feedback, Einfachheit und Commitment. Diese Werte ergeben sich aus den Anforderungen der agilen Vorgehensweise. Sie sind ein Grundpfeiler für die selbstorganisierte Arbeit des Scrum-Teams. Bei diesen Werten können viele Missverständnisse und Schwierigkeiten auftreten. Die Arbeit an den agilen Werten ist eine der Hauptaufgaben im Team-Coaching.

Im Team-Coaching steht der Coach vor der Herausforderung, herauszuarbeiten, welche Muster in der gemeinsamen Arbeit des Teams bis jetzt erfolgsversprechend waren bzw. welche Schwierigkeiten und Probleme es gibt und wie diese beseitigt werden können.

Durch die vom klassischen Vorgehen stark abweichende Projektorganisation im Scrum ergeben sich einige Herausforderungen für ein Scrum-Team und seine Umgebung, beispielsweise das Delegieren bzw. Übernehmen von Verantwortung oder das Herbeiführen von Teamentscheidungen. Das folgende Beispiel zeigt ein mögliches Vorgehen, solche Herausforderungen in einem Team-Coaching zu adressieren.

Im Gespräch mit der Auftraggeberin, der Geschäftsführerin der Organisation, gibt diese dem Coach einen ersten Überblick über die Historie des Teams sowie die Einbettung des Teams in die Organisation. Die Organisation ist ein kleines Softwareentwicklungsunternehmen mit einem Scrum-Team, das aus acht Mitgliedern besteht.

Die Geschäftsführerin meint, dass seit Einführung von Scrum zwar durch die hohe Transparenz des Prozesses sowie durch das schrittweise Vorgehen mit regelmäßigem Kunden-Feedback wesentliche Verbesserungen erreicht werden konnten, dass sie aber trotz allem mehr erwartet hätte.

Als Problem erwähnt sie, dass das Scrum-Team sehr oft seine abgegebenen Sprint Commitments (Selbstverpflichtung des Scrum-Teams, die für den Sprint zugesagten Arbeiten auch tatsächlich umzusetzen) nicht einhalten kann, und dies nur Schulterzucken bei den Team-Mitgliedern auslöst.

Als Rahmen vereinbaren die Geschäftsführerin und der Coach für die nächsten drei Monate einen halbtägigen Vorbereitungsworkshop, eine eineinhalbtägige Coaching-Klausur an einem Ort abseits der Organisation sowie einen zweistündigen Nachbereitungsworkshop.

Am vorbereitenden Workshop nimmt das gesamte Scrum-Team teil, d.h. Developer Team, Product Owner und Scrum Master. Der Coach stellt zunächst die zuvor eingeführten Werte vor. Daraufhin werden die Teammitglieder in einer Einzelarbeit gebeten, jeden der Werte auf einer Skala von null (wird im Team gar nicht gelebt) bis zehn (wird ideal gelebt) zu bewerten. Die Einzelbewertungen werden anschließend auf einem Flipchart zusammengeführt.

Es zeigt sich, dass die Werte Fokus, Mut, Offenheit, Feedback und Commitment von allen Teammitgliedern tendenziell schlecht bewertet wurden. Der Coach versucht anschließend, die einzelnen Teammitglieder zu Erklärungsversuchen für diese schlechten Bewertungen anzuregen, die allerdings nur sehr zögerlich kommen.

So wird der Eindruck gewonnen, dass die Teammitglieder nur wenig Übung in gemeinsamer Kommunikation zu selbstbezüglichen Themen haben und sich nicht recht trauen, ihre Meinung zu äußern.

Im Laufe des Workshops stellt sich zudem noch heraus, dass die Retrospektive, eines der vier von Scrum vorgegebenen regelmäßigen Meetings, nur sehr selten stattfindet, da es dazu laut Scrum Master „kaum Bedarf “ gebe.

Die Retrospektive dient der regelmäßigen Reflexion des Teams darüber, wie miteinander gearbeitet wird und resultiert in gemeinsam erarbeiteten Maßnahmen zur kontinuierlichen Verbesserung des Arbeitsprozesses. Sie ist somit ein wesentlicher Mechanismus zur Förderung der Selbstorganisation des Teams und sollte nur in Ausnahmefällen unterbleiben.

Der Coach vereinbart mit dem Team, sich in der Coaching-Klausur mit den schlechtbewerteten Werten auseinanderzusetzen.

Die eineinhalbtägige Coaching-Klausur findet in einem abgelegenen Berggasthof statt. Die Teilnehmer übernachten hier, sie haben daher am Ende des ersten Klausurtags die Gelegenheit, die Erlebnisse informell am Abend weiter zu betrachten.

Der Coach entwickelt folgendes Design für die Klausur: Am ersten Seminartag werden die Teilnehmer in zwei Übungen herausfinden, wie die Rollen im Team besetzt sind, 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.) bzw. 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 vom Coach angeleitet werden und in denen der Coach versuchen wird, wirklich alle Teilnehmer zu aktivieren. Unterstützt werden soll die Lernerfahrung dieser Übungen durch Inputs des Coachs zu den Themen „Feedback geben und nehmen“ sowie „typischen 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 am ersten Seminartag gemachten Lernerfahrungen einzubringen.

Im Laufe der Klausur beobachtet der Coach ein Sich-Öffnen der Teammitglieder. Durch das aktive Üben, Kritik wertschätzend zu äußern sowie Feedback zu geben und zu nehmen, gelingt es den Teilnehmern zusehends, offen über unangenehme Dinge miteinander zu diskutieren. Die Atmosphäre in der Klausur ist sehr von Aufmerksamkeit und Wertschätzung geprägt. Es hat 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 sichtbar gemacht werden.
• Das Team wird sich ab sofort gegenseitig darin bestärken, die in der Klausur kennen- und schätzengelernten 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 (einer Tafel, die den Projektfortschritt des Scrum-Teams anzeigt, und vor der sich das Team zur täglichen Abstimmung trifft) visualisieren. 
• Das Team wird nach jedem Sprint wieder eine Retrospektive abhalten. Es wird 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 Masters identifiziert wurde.

Sechs Wochen nach der Coaching-Klausur trifft sich das Team zum vereinbarten Nachbereitungsworkshop. Das Team bewertet dabei die Erreichung der in der Klausur vereinbarten Ziele:

• Die Regeln für ein fokussiertes Arbeiten wurden vom Team erarbeitet und für alle sichtbar gemacht. Mit der Einhaltung dieser Regeln ist das Team einigermaßen zufrieden, es wird jedoch vereinbart, einige Regeln noch einmal zu überarbeiten, da sie vom Product Owner als zu strikt empfunden werden – wie beispielsweise das „Nicht-Stören-Dürfen“: Das Team hatte vereinbart, dass es für seine oder die Anfragen anderer teamexterner Personen nur zu fix festgelegten Zeiträumen pro Tag zur Verfügung steht.
• Das Geben und Nehmen von Feedback funktioniert besser als bisher. Besonders gut gelingt es dem Team, auch die Meinung von bisher eher zurückhaltenden Kollegen abzufragen. Allerdings sind nicht alle im Team mit der Konsensbildung zufrieden. Das Team wird sich nach und nach bewusst, dass es zwei sehr dominante Charaktere im Team gibt und diese oft Entscheidungen vorwegnehmen.
• In der Zeit seit der Coaching-Klausur hätten drei Retrospektiven stattfinden sollen. Zwei haben tatsächlich stattgefunden, mit ihrem Verlauf ist das Team zufrieden. Die letzte Retrospektive allerdings ist „auf Grund der allgemeinen Hektik“ vor Auslieferung der nächsten Version der Software ausgefallen. Ein Nachhaken des Coachs bringt ans Licht, dass die nach wie vor bestehende zeitliche Überforderung des Scrum Masters einen hohen Anteil am neuerlichen Ausfall der Retrospektive hatte.

Am Ende der Nachbereitung erscheint es dem Coach notwendig, die genannte zeitliche Überforderung des Scrum Masters weiter zu thematisieren. Das Team befindet sich gerade in einer sensiblen Phase, in der es einen Scrum Master bräuchte, der intensiv mit dem Team arbeiten und ihm die notwendigen Anregungen geben kann.

Der Scrum Master wird um ein Einzelgespräch gebeten, um die Gründe für die zeitliche Überforderung zu erforschen. Dabei stellt sich heraus, dass es sowohl Ursachen gibt, die vom Scrum Master alleine beseitigt werden können (z.B. mangelnde Priorisierung von Aufgaben) als auch solche, die nur gemeinsam mit der Organisation verändert werden können (z.B. arbeitsintensive Aufgaben für den Scrum Master in der Vertriebsunterstützung, die immer wieder ungeplant über ihn hereinbrechen).

Der Coach und der Scrum Master vereinbaren ein gemeinsames Gespräch mit der Geschäftsführerin, um festzulegen, wie diese Probleme angepackt werden können.

In diesem Gespräch stellt sich heraus, dass der Scrum Master seine Aufgaben in der Vertriebsunterstützung sehr gerne macht und sich vielleicht auch deshalb recht leicht von seinen Aufgaben als Scrum Master ablenken lässt. Auf die Frage des Coachs, wofür er sich entscheiden würde, wenn er nur mehr einen der beiden Tätigkeitsbereiche wahrnehmen dürfte, fällt ihm eine Antwort sichtlich schwer; er scheint ein Zerrissener zwischen diesen beiden Bereichen zu sein.

Dem Scrum Master gefällt die Idee des Coachs, das gesamte Team an der Lösungsfindung zu beteiligen – er wirkt sogar fast erleichtert. Auch der Geschäftsführerin sagt die Idee zu, da sie dem Grundgedanken agiler Vorgehensweisen gut entspricht, der Selbstorganisation des Teams möglichst breiten Raum zu geben. Die Gesprächsteilnehmer vereinbaren ein Teamgespräch in der darauffolgenden Woche, das vom Coach moderiert werden wird.

In der Vorbereitung auf das Teamgespräch geht der Coach von der Hypothese aus, dass es sehr wichtig sein wird, eine Atmosphäre zu schaffen, die den Teammitgliedern eine offene Auseinandersetzung mit dem Problem ermöglicht. Er beschließt daher, zu Beginn des Teamgesprächs die Teilnehmer mit ihrer Einschätzung zu den agilen Werten zu konfrontieren: Gerade die damals schlecht eingeschätzten Werte Mut und Offenheit werden notwendig sein, um eine gute Lösung zu finden.

Zunächst scheint es einigen Teilnehmern im Teamgespräch tatsächlich schwerzufallen, offene Worte für ihr Unbehagen zu finden, und auch den Mut aufzubringen, radikale Lösungen für das Problem anzudenken. Bestärkt durch Aufmunterungen des Coachs und vor allem des Scrum Masters selbst wird die Diskussion mit zunehmender Dauer facettenreicher und es werden auch größere Veränderungen ins Spiel gebracht.

Letztendlich kommt das Team zu folgendem Vorschlag, welcher der Geschäftsführerin zur Entscheidung vorgelegt werden soll: Der Scrum Master zieht sich aus seiner Rolle zurück, bleibt aber dem Team als einfaches Mitglied erhalten. Dies soll ihm die Möglichkeit geben, sowohl weiter im Team zu arbeiten als auch den von ihm sehr geschätzten Vertriebstätigkeiten nachgehen zu können. Seine Rolle als Scrum Master übernimmt ein noch relativ junges Teammitglied, dem diese Rolle jedoch vom gesamten Team zugetraut wird.

Teamwork ist in der Wissensarbeit die bevorzugte Arbeitsform, denn nur so können die Mitarbeiter kreative Problemstellungen erfolgreich meistern. Die Zusammenarbeit geschieht jedoch nicht einfach so, sondern bedarf intensiver Auseinandersetzung mit dem täglichen Umgang miteinander.

Das Leben der in diesem Artikel vorgestellten Werte, die gemeinsames Fundament unterschiedlicher agiler Vorgehensweisen sind, spielt dabei eine vitale Rolle. Ausgehend von dem so geschaffenen Vertrauen im Team wird dieses seine Ziele gemeinsam verfolgen und ist in der Lage, Höchstleistungen zu erbringen. Team-Coaching hilft den Mitgliedern eines Teams, ein Klima zu etablieren, in dem diese Werte gelebt werden.