Zeitdruck und Innehalten (und Lego)

Bild: Wikimedia Commons/Powerhauer - CC BY-SA 3.0

Zum Scrum Master-Job gehören unter Umständen Scrum-Workshops, in denen die Methode mit Hilfe von Legosteinen erklärt wird: Anstelle von Software werden damit Gebäude erstellt, das "Projekt" ist auf ein bis zwei Stunden begrenzt und die einzelnen Zyklen und Meetings sind entsprechend verkürzt, sonst wird versucht so nah wie möglich am Original-Vorgehen zu bleiben (eine genauere Erläuterung gibt es hier). Das Ziel ist eine eher spielerische Vermittlung, die auch für Menschen zugänglich ist die keine vertieften IT-Kenntnisse haben. Vor diesem Hintergrund kann dieses Vorgehen sehr sinnvoll sein, allerdings würde ich bei seinem Einsatz raten mit Vorsicht vorzugehen.

Beim Lego-Scrum (und auch bei anderen Simulationsmethoden wie z.B. dem Scrum-Kochen) sollte man meiner Meinung nach zwei Risiken bedenken: Zum Einen das Problem der fehlenden "Ernsthaftigkeit" (darüber hatte ich bereits etwas geschrieben), zum Anderen sollte man sich bewusst sein, dass Scrum auf diese Weise unter einem hohen Zeitdruck stattfindet. Bei einer 90-minütigen Simulation mit drei Sprints zu je einer halben Stunde bleiben für Refinement, Planning, Daily Standup, Review und Retrospektive jeweils nur wenige Minuten. Gerade bei unerfahrenen Teams kann das dazu führen, dass so viel wie möglich davon weggelassen wird um mehr Zeit für die "richtige Arbeit" zu haben. Wird das nicht diskutiert oder korrigiert gehen die Teilnehmer möglicherweise mit dem "Erkenntnisgewinn" nach Hause, dass diese Meetings etwas sind was man streichen oder stark verkürzen sollte wenn man schneller vorankommen will. Wenn sich das einmal in den Köpfen festgesetzt hat ist es mitunter nur schwer wieder dort herauszubekommen. Und das ist nicht der einzige "Kollateralschaden" der auftreten kann.

Zu den Kernelementen von Scrum gehört nach meinem Verständnis, dass in regelmässigen Abständen der Zeitdruck von den Teams weggenommen wird. Egal wie dringend und wichtig neue Features gerade sind (und sie sind fast immer dringend und wichtig) - in festen Zyklen muss innegehalten und Abstand genommen werden. Nur wenn man aus dem Hamsterrad heraussteigt und zurücktritt kann man sich die richtigen und zielführenden Fragen stellen:

• Ist das was wir vorhaben überhaupt technisch umsetzbar? (Refinement)
• Ist das was wir vorhaben in der gegebenen Zeit überhaupt zu bewältigen? (Planning)
• Sind wir noch im Zeitplan, und wenn nicht - wie gehen wir damit um? (Daily Standup)
• Ist das was wir produziert haben wirklich das was die Benutzer wollen? (Review)
• Ist das methodische Vorgehen das wir gewählt haben tatsächlich das richtige? (Retrospektive)

Was passiert aber wenn man sich die Zeit für dieses Innehalten nicht nimmt sondern schnellstmöglich durch die Meetings hetzt um schnell wieder an die Arbeit zu kommen? In den meisten Fällen wird man Murks als Ergebnis haben. Probleme werden nicht durchdrungen, Gedanken nicht zu Ende gedacht, Beschlüsse vorschnell gefasst und Diskussionen abgewürgt. Am Ende stehen Ergebnisse die nicht wirklich brauchbar sind.

Zurück zur Lego-Simulation. In ihrem Fall besteht ein hohes Risiko, dass die enge Zeitbegrenzung die Meetings so staucht, dass sie in der gerade erwähnten Form dysfunktional sind. Wenn dadurch aber der "Erkenntnisgewinn" geprägt ist, den die Teilnehmer mitnehmen, dann ist das sogar wesentlich schwerwiegender als im oben genannten ersten Fall. Dann entsteht nämlich der Eindruck, dass die Scrum-Regelmeetings im Zweifel nicht nur verzichtbar sondern sogar eher schädlich sind, weil ja "offensichtlich" nur halbgare und kaum brauchbare Ergebnisse in ihnen entstehen. Und wenn sich dieser Eindruck erstmal verfestigt hat, dann wird es wirklich schwer ihn zu korrigieren.

Das alles heisst nicht, dass man Lego-Scrum und ähnliche Methoden gar nicht einsetzen sollte. Es heisst aber, dass in ihnen explizit darauf geachtet werden sollte, dass die beschriebenen Fehlentwicklungen nicht eintreten. Möglich ist etwa eine Mindestdauer für Meetings, so dass es für die Teams nicht mehr möglich ist Arbeitszeit zu gewinnen indem man die Meetingzeit zusammenstreicht. Auch die Frage ob ein bis zwei Stunden wirklich für eine Simulation ausreichen kann man diskutieren (ich z.B. glaube das nicht). Und zuletzt sollten die Veranstalter in eigenen Retrospektiven regelmässig auch ihr eigenes Vorgehen überprüfen, ganz so wie sie es vermutlich selbst irgendwann mal in einer Scrum-Simulation gelernt haben.