Scrum Master und Agile Teams
Eine der häufigen Fragen, die mir als Agile Coach immer wieder begegnet, ist die nach dem Nutzen eines Scrum Masters oder Agile Masters, wie die Rolle in manchen Unternehmen auch genannt wird. Das Problem, das hinter der Frage steckt, ist meistens ein Kapazitätsproblem im Unternehmen. Oft sehen auch Führungskräfte nicht ein, warum eine ganze Person darauf abgestellt wird, „nur“ die Einhaltung der Regeln von Scrum zu „überwachen“ oder das Daily, das Review bzw. die Retro zu organisieren.
Viele Aufgaben als Scrum Master
Ein guter Scrum Master leistet jedoch viel mehr als das. Er ist nach meinem Verständnis vor allem ein Coach für das Development Team und den Product Owner. Natürlich ist eine seiner Aufgaben, die anderen Mitglieder des Scrum Teams (also Development Team und Product Owner) in ihrem Verständnis von Scrum zu entwickeln, sie also zu trainieren und zu coachen. So organisiert der Scrum Master vielleicht anfangs noch das Daily, moderiert vielleicht sogar die ersten paar Runden. Dann aber ist er zunehmend in der Rolle eines Coachs dabei, um das Team zur Selbstorganisation zu führen. Und schließlich stellt er nur noch sicher, dass das Team ein Daily durchführt. Zu einem späteren Zeitpunkt wäre es sogar ein Fehler, immer persönlich anwesend zu sein. Es sei denn, das Team wünscht dies oder es sind bestimmte Ereignisse vorgefallen.
Vor kurzem habe ich eine Einladung bekommen, einen Workshop mit einem recht erfolgreichen Team durchzuführen. Das Team war gut unterwegs, die Velocity stieg konstant. Das Team hatte jedoch mit ein paar typischen Impediments zu kämpfen. Es gab keine vollständige Testautomatisierung, viele Abhängigkeiten zu anderen Teams, keinen klaren Kundenfokus – weil das Produkt ein Schritt in einem Prozess war – und mangelnde Kapazitäten. So wurde dem Team zum Beispiel kein Scrum Master zur Verfügung gestellt, weil es ja erfolgreich unterwegs war. Ebenso stand der Product Owner nur mit einem Teil seiner Kapazität zur Verfügung. Doch das erfuhr ich erst im Laufe des Workshops.
Fragen der Selbstorganisation
Dieser begann mit ein paar Fragen, die sich aus der Selbstorganisation ergaben. Als externer Coach ist das eine eher problematische Situation, wenn ich nach Ratschlägen oder best practice gefragt werde. Ich verstehe natürlich den Wunsch nach Erfahrungen anderer Teams. Allerdings erzeugen Ratschläge von außen oft auch Widerstand – im einen Fall zeitnah („Der hat nicht verstanden, wie es bei uns wirklich aussieht“), im anderen Fall später („Das konnte bei uns eben nicht funktionieren“).
Daher lasse ich mich eher ungern auf eine konkrete Antwort ein, sondern stelle Fragen . Das kommt für mich im Übrigen auch dem Ansatz näher, das Team in seiner Selbstorganisation zu coachen. Ich empfehle also zum Beispiel kein musterhaftes Vorgehen für ein spannendes Daily, zu dem alle Teammitglieder gerne kommen. Sondern ich frage die Teammitglieder direkt: Was könnt Ihr denn an eurem Daily verändern, damit ihr alle gern kommt und euch richtig drauf freut? Manchmal ernte ich dann noch eine Runde Widerstand („Ja, aber das doch genau das Problem, dass es so … ist“).
Fragen vom Ziel her gesehen
Okay, dann lege ich noch eins drauf: „Es ist euer Daily und es liegt an euch, das Daily so zu gestalten, dass es euch wirklich Nutzen bringt. Also, angenommen ihr habt ein Daily, auf das ihr Euch jeden Morgen wirklich freut, aus dem ihr voller Energie wieder an die Arbeit geht, das euch begeistert und motiviert, was habt ihr dann verändert?“ Tatsächlich ist das eine typische Art zu Fragen aus dem Business Coaching, die ich hier einsetze. Ich schiebe den Klienten (hier: das Team) gedanklich in den positiven Zielzustand und lasse ihn zurückblicken, was sich verändert hat. Diese Frage ist meistens einfacher zu beantworten als der Blick nach vorne auf die notwendigen Veränderungen. Aber das sei hier nur am Rande ein kleiner Ausblick auf den Coach-Anteil in der Rolle des Scrum Masters oder Agile Coachs.
Zurück zum Team. Da wir das Meeting online führten, leider auch noch ohne Video und als reine „Telefonkonferenz“ über MS Teams, war es schwierig, alle Teilnehmer zu aktivieren. Also sprach ich reihum alle Teammitglieder an, wo sie noch Fragen hätten oder Impediments in ihrer Arbeit sehen. Schließlich merkte eine Entwicklerin an, dass sie viel Aufwand hätte, um aus der Beschreibung der User Stories die nötigen Informationen für ihre Arbeit zu ziehen. Das liege in der sehr umfassenden Beschreibung der User Stories.
Detailvielfalt sorgt für Verwirrung
Sie teilte ihren Bildschirm mit uns und wir sahen uns gemeinsam eine User Story in Jira an. Dazu gab es noch eine Confluence-Seite mit näheren Erläuterungen. Jira ist ein Tool, das oft zur Verwaltung von User Stories eingesetzt wird, Confluence ist das ergänzende Werkzeug zur Dokumentation und Kommunikation im Team. Wir erinnern uns kurz, dass eine User Story aus Sicht eines Benutzers unseres Produkts erläutern soll, was er tun möchte bzw. welche Funktion er umgesetzt sehen will.
Doch diese User Story war eher eine vollständige technische Spezifikation, fast schon ein kleines IT-Konzept. Nun gibt es natürlich auch technische User Stories, kein Thema. Aber hier war es wirklich eine umfassende, rein technisch formulierte Spezifikation. Aufgrund der vielen Abhängigkeiten zu anderen Prozessschritten, Systemen und Teams war die Darstellung in Jira nicht mehr ausreichend.
Der Konflikt tritt ans Licht
Die genauere Schilderung erfolgte in einer ellenlangen Confluence-Seite. Darin fanden sich etliche Abkürzungen, technische Details wie Feld- und Tabellennamen oder Verweise auf andere Systeme und Schnittstellen. Mit anderen Worten: Es war eine umfassende technische Spezifikation, die auch wesentlich mehr beinhaltete als nur das aktuelle Produkt. Mit aus diesem Grund war sie komplett unverständlich – nicht nur für mich, sondern auch für die Entwicklerin. Mir war sofort klar, dass sie mit dieser User Story nun sicher nicht die nötigen Informationen hatte, um ihren Code zu schreiben.
Schon während ihrer Problemschilderung fiel ein anderes Teammitglied ein, dass dieses Vorgehen eben so nötig sei, um die zahlreichen Abhängigkeiten zu anderen Teams zu pflegen. Die Confluence-Seite werde eben von vielen Kolleg*innen bearbeitet. Woraus eine interessante Diskussion im Team entstand. Mache Teammitglieder stimmten der Entwicklerin zu, andere folgten eher dem Ansatz, das müsse eben so sein, um die zahlreichen Abhängigkeiten im Blick zu haben. Mir war schon klar, was sich hier langsam zeigte: ein handfester, bisher verborgener Konflikt.
Scrum Master fokussiert auf Werte
Ich nahm Anlauf und verlagerte die Diskussion auf die Scrum-Werte. Ich fragte die Entwicklerin, welcher Wert aus ihrer Sicht nicht ganz erfüllt sei, damit sie gute Arbeit leisten konnte. Wir kamen darauf, dass sie keinen Fokus halten konnte. Zudem leide ihr Commitment (also ihre Motivation) stellenweise, weil so viel zusätzliche Abstimmung nötig sei. Schließlich konfrontierte ich so noch mit der Frage, ob sie sich eigentlich respektiert fühle. Tatsächlich entbrannte nun eine heftige Diskussion. In deren Verlauf verwies schließlich auch der Product Owner klar darauf, dass er nicht noch mehr Arbeit in die detaillierte Aufschlüsselung der User Stories stecken könne. Er hätte noch ein anderes Produkt und parallel zu seiner Rolle als PO noch weitere fachliche Aufgaben.
So langsam hatte ich damit alles beisammen, um das Team durch eine weitere Frage zu packen. Ich bedankte mich zunächst für die offene und ehrliche Diskussion und sprach in dem Zusammenhang die Werte Offenheit und Mut an. Immerhin hatten einige Leute sich den Mut genommen, sehr offen und durchaus emotional anzusprechen, was sie beschäftigt. Das ist sehr hilfreich, um die tatsächlichen Probleme des Teams überhaupt zu erkennen und angehen zu können. Und wir hatten endlich unser eigentliches Problem, einen handfesten Konflikt, im Fokus.
Stärkung des Teamgedankens
Somit konnte ich den nächsten Schritt zur Lösung angehen. Natürlich wieder in eine Frage gekleidet: „Wie könnt ihr es als Team schaffen, die User Stories für die Entwickler zu verbessern, ohne eurem Product Owner damit mehr Arbeit mitzugeben? Und in Ergänzung: Wie könnt ihr dabei insgesamt auch die Abhängigkeiten zu anderen Teams beachten?“ Okay, die Frage war lang und nicht leicht zu verstehen, trotz meiner Pausen. Aber die Botschaft kam an. Einer fragte nach: „Du meinst also, wie wir das alles so hindrehen, dass wir besser als Team funktionieren?“ – „Ja natürlich, das wäre die Kurzfassung meiner Frage. So dass ihr wieder stärker miteinander, nicht gegeneinander arbeitet. Dass ihr auf Euch achtgebt und euch gegenseitig unterstützt.“
Faszinierend: Nach diesem Fokuswechsel zum Miteinander sprudelten schnell erste Lösungsvorschläge. Beginnend beim Daily, hin zu Sprint Planning und Refinement bis zu zusätzlichen Abstimmungen mit den anderen Teams reichten die Ideen. Letzteres sollte in Form von übergreifenden Daylies und gemeinsamen Refinements passieren. Für mich war das ein wunderschönes und zielgerichtetes Ergebnis des Workshops. Das Team empfand das ebenso.
Wozu braucht es einen Scrum Master?
Zum Schluss lenkten wir noch einmal die Aufmerksamkeit auf die Frage, ob das Team nun einen Scrum Master braucht oder dessen Kapazität besser als Entwickler nutzen könne. Also fragte ich nochmal, was ich mit dem Team wohl heute gemacht hätte. Schnell waren wir bei der Idee des Teamcoachs, der das Team noch besser macht. Und der auch ein paar inhaltliche Dinge in die Diskussion einbringt, die (zu) oft vergessen werden: die Scrum-Werte zum Beispiel. Von da aus war es natürlich nur noch ein kurzer Weg für mich.
Ich erklärte dem Team, dass alles, was ich heute mit ihnen gemacht hatte, ein Teil der Aufgaben eines guten Scrum Masters sei. Den nötigen Input zu geben und als Coach das Team noch besser in der Zusammenarbeit zu machen. Und schon kam die letzte Falle für mich, in Form der Frage, ob das Team denn meiner Meinung nach nun doch einen Scrum Master braucht. Zum Glück kam die Antwort gleich nach der Frage mit: dass ich wohl vermutlich jetzt antworten würde, das müsse das Team selbst entscheiden, wenn es Selbstorganisation wirklich leben wolle. Richtig! Und so beschlossen wir den Workshop mit einem runden Ende.
Ich hoffe, dass dieses Beispiel sowohl meine Rolle als Agile Coach wie auch die Rolle des Scrum Masters etwas verdeutlichen konnte. Falls Sie Fragen zu erfolgreichen Teams, zu Scrum, Agilität oder den Rollen von Scrum haben, sprechen Sie mich gerne an oder vereinbaren Sie gleich ein Gespräch mit mir: Hier finden Sie Kontakt.