Teamübergreifende Dailies
 |
| Bild: Unsplash / Parabol - Lizenz |
Wenn mehrere agil arbeitende Teams merken, dass sie häufigen Austauschbedarf haben, ist in den meisten Fällen die Einrichtung eines gemeinsamen Daily Meeting die Folge, in dem ein tagesaktueller Austausch zu Neuigkeiten, Abhängigkeiten und gemeinsamem Vorgehen möglich ist. Derartige teamübergreifende Dailies sind die früheste und einfachste Form der agilen Skalierung, aber bereits eine die in verschiedenen Varianten durchgeführt werden kann. Da diese jeweils verschiedene Vor- und Nachteile haben lohnt es sich kurz zurückzutreten und sie nebeneinander zu betrachten.
I. Sequentielle Team-Dailies mit "Scouting"
Die einfachste Variante. Alle Team-Dailies finden nacheinander statt (idealerweise in einem Raum oder in einem gemeinsamen Call), so dass jedes Team einen Vertreter (oft "Scout" genannt) bestimmen kann, der bei den jeweils anderen teilnimmt. Der Vorteil dieses Vorgehens ist, dass so keine neuen Meetings entstehen, der Nachteil, dass sich das Scouting bei mehreren Teams sehr in die Länge ziehen kann. Scouting wird u.a. im Skalierungs-Framework LeSS empfohlen.
II. Ein übergreifendes Daily vor den Team-Dailies
Ein eher seltener Ansatz. Die Grundidee hier ist es, Informationen zusammenzutragen die für die danach folgenden Team-Dailies wichtig sind, wie z.B. die Ergebnisse nachts durchlaufender Regressionstests. Das kann Sinn machen, die Schwierigkeit dabei ist aber, dass neue Inputs aus den Team-Dailies erst mit einem Tag Verspätung in die grosse Runde kommen. Ein typisches Umfeld für diese früh stattfindenden übergreifenden Dailies ist das Skalierungs-Framework Nexus.
III. Ein übergreifendes Daily nach den Team-Dailies
Der Klassiker. Der Austausch über das was in den Teams kurz vorher als übergreifend wichtig erkannt wurde ist unter dem Namen "Scrum of Scrums" in vielen Firmen anzutreffen und gehörte zu den ersten Skalierungselementen von Scrum die erfunden wurden, noch vor den Skalierungs-Frameworks. Der Vorteil ist, dass Erkenntnisse aus den Team-Dailies schnell verbreitet werden, es besteht aber das Risiko, dass auch vieles aus den Teams berichtet wird, was keine übergreifende Relevanz hat.
IV. Mehrere Spezialisten-Dailies
Ein Vorgehen das z.B. im Skalierungsframework Scrum@Scale zu finden ist. Nach den Daily Scrums der Teams folgen hier die der Product Owner und der Scrum Master, möglich sind auch die der Frontend-Entwickler, der Tester, etc., etc. Der Überblick der in solchen Runden entsteht ist sehr spezifisch, zur Verbreitung eigentlich irrelevanter Informationen kommt es seltener. Dafür besteht das Risiko, dass es an keiner Stelle zu einem Gesamtbild kommt sondern überall nur Ausschnitte sichtbar sind.1
Welche dieser Varianten die am besten passende ist dürfte von Fall zu Fall unterschiedlich sein und sich möglicherweise sogar über die Zeit ändern. Um die passende zu finden bieten sich zwei Vorgehensweisen an: initial kann man sich fragen welchen Zweck das teamübergreifende Daily überhaupt haben soll, oft ergibt sich daraus schon ein Hinweis auf den passenden Modus. Sobald die Termine stattfinden kann man in den Inspect & Adapt-Modus übergehen, überprüfen ob sie den erhofften Mehrwert bringen und ggf. neues ausprobieren.
Nur von einem ist abzuraten: dem "Reporting-Daily" für das Management. Die gehen soweit an der Idee selbstorganisierter Teams vorbei und laden so stark zum Micro-Management ein, dass man sie gar nicht erst einführen sollte.
