Wenn Sie sich bereits mit Scrum beschäftigt haben, werden Sie wissen, dass wir für alle Meetings einen festen Zeitrahmen definieren, damit wir nicht einfach endlos plappern, sondern zügig durch die Agenda gehen. Doch was soll man machen, wenn man sich verschätzt hat, und der Review dauert einfach länger als angenommen? Bricht man dann den Review ab? Und was dann?
Zunächst ein paar allgemeine Gedanken zu Meetings in Scrum, bevor wir uns später den größeren Problemen widmen: Ich habe in einigen Unternehmen bereits gesehen, dass einzelne Meetings abgebrochen wurden, wenn die Zeit abgelaufen war. Der Scrum Master hatte gut sichtbar eine Uhr (genau genommen sein Tablet) in den Konferenzraum gestellt, den Alarm auf 90 Minuten eingestellt und das Planning-Meeting abgebrochen, als diese 90 Minuten erreicht waren. Der Sprint endete daraufhin recht chaotisch, da das Team die besprochenen Anforderungen bereits nach einer Woche fertiggestellt hatte. Der Product Owner legte dann unkritische kleine Anforderungen nach.
Wir einigen uns auf eine Höchstdauer für ein Meeting um uns davor zu bewahren, uns in endlosen Laberdiskussionen zu verlieren. Selbstverständlich ist es dann überhaupt kein Problem, wenn man fünf oder zehn Minuten länger braucht. Sie sollten daher nicht von Ihren alten Praxis abweichen, einen kleinen Zeitpuffer einzuplanen, wenn in einem größeren Unternehmen ein Konferenzraum gebucht werden muss.
Es ist für mich auch vollkommen in Ordnung, wenn man eine Uhr gut sichtbar im Konferenzraum aufstellt, um sich daran zu erinnern, dass man zusammengekommen ist, um zu arbeiten und voran zu kommen (in den meisten Konfis hängt sowieso eine an der Wand).
Auch beim morgendlichen Daily Scrum sollte man meiner Meinung nach nicht mit der Stoppuhr arbeiten, ganz gleich ob man sich vielleicht auf 15 Minuten insgesamt oder zwei Minuten pro Teammitglied geeinigt hat. Der Scrum Master hat lediglich darauf zu achten, dass die Dinge nicht ausufern und man nicht endlos redet. Wenn einer drei Minuten braucht, und ein anderer nur eine, dann ist das auch vollkommen in Ordnung.
Ich muss als Scrum Master im Daily nicht jede Diskussion sofort abbrechen und sagen, dass sich die Kollegen später einmal zusammensetzen sollten. Wenn das Problem in einer Minute gelöst ist, ist auch das vollkommen in Ordnung.
Schwierig wird es lediglich, wenn wir feststellen, dass wir überhaupt nicht zum Ende kommen. Gerade während der Einführung von Scrum kann es passieren, dass wir uns z.B. auf 90 Minuten für das Planungsmeeting verständigen, nach zwei Stunden jedoch gerade einmal die Hälfte des Spints eingetütet haben. In diesem Fall sollte der Scrum Master unterbrechen und gemeinsam mit Team und Product Owner untersuchen, warum man nur so langsam vorankommt. In aller Regel liegt es dann daran, dass die Anforderungen noch so unklar sind, dass das Team viele Fragen hat. Oder das Team ist sich nicht einig, wie es die Anforderungen umsetzen möchte und kann daher nicht zu einer Schätzung kommen.
In beiden Fällen würde ich dazu raten, lediglich einen einwöchigen Sprint anzusetzen (auch wenn das wirklich nur die absolute Ausnahme sein sollte), um dem Product Owner ein wenig Zeit zu geben, den nächsten Sprint besser vorzubereiten. In dieser Zeit werden die Anforderungen dahingehend überprüft, ob sie wirklich verständlich und eindeutig formuliert sind, ob noch Fragen offen sind, und der Entwicklungsleiter Architekt oder ein senioriger Entwickler sieht sich die nächsten Anforderungen an und macht sich schon erste Gedanken zur Umsetzung, damit sich das Team auf eine Aufwandsschätzung einigen kann.
Wenn ein Meeting aus dem Ruder läuft, dann liegt das entweder an der Vorbereitung oder an der Disziplin der Teilnehmer. Niemand hat etwas dagegen, wenn man für ein paar Minuten vom Thema abschweift und sich vielleicht einfach nur ein paar Witze erzählt. Zwischendurch muss Zeit für einen Scherz sein – kein Problem. Der Scrum Master achtet lediglich darauf, dass man nach einer angemessenen Zeit wieder auf den Pfad der Tugend zurückkommt.
Es geschieht sehr viel häufiger, dass eine Planungssitzung nicht funktioniert, als dass ein Review den Zeitrahmen über alle Maßen sprengt. In einem Review ist der Umfang klar, und der Product Owner vergleicht die geleistete Arbeit lediglich mit den klar definierten Anforderungen. Hier kommt es nur selten zu längeren Diskussionen. Es kann sein, dass das Team der Meinung ist, eine Anforderung korrekt umgesetzt zu haben, der Product Owner sieht das jedoch anders. Dann wird er die Anforderung zurückweisen. Der Grund hierfür ist allerdings wiederum eine Unklarheit. Das Team hat die Anforderung offenbar anders verstanden, als der Product Owner dies beabsichtigt hatte. Der PO muss daraus die Konsequenz zeihen, seine Anforderungen klarer zu formulieren.
Ebenfalls vollkommen ausufern können Retrospektiven. Wenn das Team diese Möglichkeit nutzt, sich einmal richtig auszukotzen, und das auch kein Ende findet, dann sollten eigentlich alle Alarmsirenen läuten. Der Scrum Master muss dabei natürlich abwägen, ob es sich um Jammern auf hohem Niveau über Kleinigkeiten handelt, oder ob wirklich grundlegende Dinge im Argen liegen. In diesem Fall kann der Job des Scrum Masters sehr unangenehm werden, wenn es z.B. mit der Geschäftsleitung darüber reden muss, wie unzufrieden das Team ist.
Auch eine retrospektive sollten Sie nicht abbrechen. Sammeln Sie die wichtigen Punkte, und betrachten Sie diese einen nach dem anderen. Achten Sie als Scrum Master jedoch darauf, auch diese Diskussion geordnet verlaufen zu lassen. Das 25. Beispiel für die Ungerechtigkeit des Chefs bringt niemanden weiter. Achten Sie auch auf den Punkt, wenn die größeren und wichtigen Punkte besprochen sind, und man sich den Kleinigkeiten zuwendet, weil man kein Ende findet.
