Scrum in einem Team richtig zu machen, ist schon schwierig genug. Hier helfen aber zumindest die in Scrum beschriebenen Rituale, wie das Daily, die Retrospektive, das Refinement und natürlich Planning und Review.
Bei der Skalierung von Scrum auf viele Teams standen wir vor der Herausforderung, dass Scrum nichts dazu sagt, wie die Kommunikation zwischen den Team, die Abstimmung, also das Alignment, passieren soll, und auch nicht wie eine Organisation mit den Wünschen der Teams nach Autonomie umgehen soll.
Kommunikation als Herausforderng
Viele Dinge, die früher nur im eigenen Team, oder mit einem anderen Ansprechpartner abgestimmt werden mussten, bedurften nach diversen Skalierungsschritten plötzlich komplexer Abstimmungsprozesse, oder es kam schlicht die Frage auf: „Mit wem muss ich das abstimmen?“ „Mit dem Datenschützer!“ ist immer eine gute und schnelle Antwort – jedoch ist sie nicht immer hilfreich.
Neue Meetings entstehen und auch der Community of Practice-Gedanke hält Einzug.
Bei Bedarf haben wir auch übergreifende Dailies, wo es notwendig ist, die oft auch als Scrum of Scrums genannt werden, wie bei den Scum Mastern oder für die Testautomatisierung, denn wer kümmert sich nun um die roten Testfälle auf der ganzen Plattform. Die Regression gehört schließlich allen.
Die Beteiligten stöhnen unter der Meetinglast. Das Scrum of Scrums-Weekly scheint endlos zu dauern und Frust entsteht.
Immer häufiger wird die Frage diskutiert „Was muss ich überhaupt abstimmen?“ oder „Warum kann ich das nicht mit meinem Team alleine entscheiden?“.
Das Delegationsmodel als Management 3.0 Methode, die wir von Jurgen Appelo gezeigt bekommen hatten, half uns beim Sortieren, welche Dinge überhaupt und – wenn ja – mit welchem Delegationslevel abzustimmen sind.
Auch die Detailtiefe von Statusmeldungen wurde hinterfragt. Informationen wurden auf das Wesentliche gekürzt. Über die Zeit entstand eine Art Informations- und Abstimmungsorganismus, mit und in dem wir gut leben können, und in dem wir nicht zu sehr von einzelnen Wissensträgern abhängig sind.
Release Retrospektive
Ein wichtiger Baustein ist dabei das regelmäßige Feedback, das ja in den Teams durch Retrospektiven gelernt ist, und das wir auch für alle Teams auf Release-Ebene hoben.
Im Schnitt nach jedem zweiten Zweimonatsrelease machen wir eine Release Retrospektive, als große und von außen moderierte Tagesveranstaltung. Hier nehmen alle Scrum Master, Product Owner, aus jedem Team ein Entwickler und ein Tester, sowie wichtige Stakeholder aus dem Betrieb, der Architektur und optional der Fachbereiche teil. Ganz wichtig sind auch die Abteilungsleiter in ihren Rollen als agile Manager.
Ziel ist es dabei, die „großen“ Fragen aller Teams, die sie nicht selber lösen können, zu adressieren und übergreifende Ansätze in der Organisation zu finden. Darum kümmern sich dann die Abteilungsleiter, die ja die Umgebung managen, in denen die Teams arbeiten.
Review Messe
Bei einigen wenigen Teams funktionierte das Scrum Format des Reviews sehr gut. Bei der Skalierung stellten wir jedoch fest, dass immer weniger fachseitige Anforderer zu den Team Reviews kamen, und auch den anderen Teams nicht klar war, was denn ihre Kollegen genau gebaut und entwickelt hatten.
Um dem entgegen zu wirken, probierten wir das Format der Review Messe, bei dem alle Teams gleichzeitig an Ständen, die wir auf einer Etage aufbauten, ihre Ergebnisse vorstellten. Das umfasste natürlich die Live-Demonstrationen der Software, aber auch Plakate mit Screenshots und einer Beschreibung der Themen.
Jeder interessierte kann sich so an den einzelnen Ständen informieren, dem aktuellen Durchlauf der Präsentation beiwohnen, oder mit einem Teammitglied an den Schautafeln Fragen diskutieren und Verständnis vertiefen.
Die Dauer dieser Veranstaltung legten wir mit zwei Stunden fest. Die Teams stellten oft auch Süßigkeiten bereit und boten mobile Endgeräte für die Web- und App-Anwendungen zum Ausprobieren an.
Die Organisation reagierte ausgesprochen positiv auf dieses Format, die Messe war rege besucht, Fachseiten diskutierten mit Entwicklern und Testern, was das gegenseitige Verständnis und Vertrauen förderte, und auch einzelne Teammitglieder machte die Runde und tauschten sich mit Kollegen aus.
Da der zeitliche Aufwand zur Vorbereitung dieser Messe höher ist, als die Vorbereitung eines normales Reviews, machen wir diese Art der Ergebnispräsentation nur nach dem letzten Sprint eines Releases.
Communities of Practice
Um teamübergreifende Abstimmungen zu erleichtern und ein Alignment in verschiedensten Dimensionen zu erreichen, etablierten sich Communities of Practice (CoP) zu einer Reihe von Themen, als Antwort auf die Frage „Wie machen das denn die anderen, und kann ich vielleicht was lernen?“
Die Initiative zu einer Community kam entweder situativ aus einer Problemsituation, in der ein Team feststellte, dass andere Lösungen und Ansätze haben, die ihnen fehlen, wurden aber durchaus auch vom Management initiiert, um aktiv Diskussionen zu fördern. Dabei ist die Teilnahme an einer CoP freiwillig, und manche Communities existieren auch nur temporär.
Als für das übergreifende Alignment wichtig haben sich bei uns folgende Communities etabliert:
- Scrum Master
- Product Owner
- Qualitätssicherung
- Entwicklung
- Testautomatisierung
- DevOps
- Architektur
Die übergreifende Abstimmung erfolgt in Weeklies, die die Communities autark organisieren.
Die Ergebnisse, die in den Communities erarbeitet werden, diskutieren die Teams dann intern und übernehmen oder adaptieren sie. So haben sich die Teams zum Beispiel auf eine übergreifende Definition of Done geeinigt, die von den Teams individuell erweitert wird.
Alignment und Autonomie
Wir haben erkannt, dass Alignment und Autonomie keine gegensätzlichen Ziele sind, sondern vielmehr zwei sich ergänzende Dimensionen, die es aktiv zu managen und pflegen gilt.
Teams in völliger Autonomie optimieren sich nur lokal und sind nicht effizienter oder besser für das Gesamtergebnis als Teams die hundert Prozent Alignment aber keine Autonomie haben.
Die Kunst, und damit auch die Herausforderung, ist es, beide Dimensionen zu fördern, und den Teams zu helfen autonom zu arbeiten und dabei mit den anderen Teams und den Unternehmenszielen möglichst gut aligned zu sein – eine Aufgabe für das agile Management.