Wir hören immer mal wieder, dass Entwickler:innen Scrum hassen - wegen der vielen Meetings.
(Der Scrum Guide spricht übrigens von Events.)
Events in Scrum
Nimmt man die Event-Dauern aus dem Scrum Guide, kommt man für einen zweiwöchigen Sprint auf:
- max. 4 Stunden Sprint Planning
- max. 15 Minuten täglich für Daily Scrums, in Summe 2,5 Stunden
- max. 2 Stunden Sprint Review
- max. 1,5 Stunden Sprint Retrospektive
Das ergibt zusammen 10 Stunden, also 5 Stunden pro Woche. Das sind bei einer 40-Stunden-Woche 12,5% der Arbeitszeit.
Das ist eine Menge nicht-wertschöpfender Arbeit. (Ich benutze einen engen Wertschöpfungsbegriff: Wertschöpfend ist, was eine positive Veränderung des Produktes bewirkt. Meetings tun das nicht.)
Zur Verteidigung kann man anführen, dass die Zeiten Maximalzeiten sind und das für die Scrum-Events auf die anderen Meetings in Unternehmen verzichtet werden soll. Das passiert leider häufig nicht und dann sitzen Entwickler:innen in Summe auch mal 30-50% ihrer Arbeitszeit in Meetings. Nimmt man dann noch die Kontextwechselkosten dazu, kommen sie kaum noch zu arbeiten. Da wäre ich auch angepisst. Aber kann man das wirklich Scrum ankreiden?
Was ist der eigentliche Punkt?
Der eigentliche Punkt ist aber ein anderer.
In vielen Scrum-Implementierungen ist den Beteiligten der Zweck der Scrum Events unklar. Dabei definiert der Scrum Guide den Zweck der meisten Events explizit:
- Daily Scrum:
„... den Fortschritt in Richtung des Sprint-Ziels zu überprüfen und das Sprint Backlog bei Bedarf anzupassen, um die bevorstehende geplante Arbeit zu justieren.“ - Sprint Review:
„... das Ergebnis des Sprints zu überprüfen und künftige Anpassungen festzulegen.“ - Sprint Retrospektive:
„Wege zur Steigerung von Qualität und Effektivität zu planen.“
Leider bleibt der Scrum Guide ausgerechnet beim längsten Event, dem Sprint Planning, den Zweck schuldig.
Ich würde den Zweck wie folgt definieren:
- Sprint Planning:
Alignment zwischen Product Owner und Entwickler:innen darüber herstellen, was im Sprint wichtig ist und Alignment unter den Entwickler:innen herstellen, wie das geschafft werden kann.
Die Dauer der Events laut Scrum Guide sind für mich eine Empfehlung für den Start. Da weiß man ziemlich sicher, wie man den jeweiligen Zweck auch mit einem unerfahrenen Team erreichen kann. Aber danach geht es darum, die Events zu verschlanken.
Warum sollte ich 4 Stunden mit Sprint Planning verbringen, wenn es auch in 10 Minuten geht (das ist tatsächlich möglich!)? Warum sollten wir uns jeden Tag 15 Minuten zusammenstellen, wenn wir den ganzen Tag Mob Programming mit dem ganzen Team praktizieren und jede:r ständig über alles informiert ist?
Wenn man konsequent nach leichtgewichtigeren Ansätzen sucht, um den jeweiligen Zweck zu erreichen, kommt man mit viel weniger Zeit aus.
Eine gute Idee, um alle Beteiligten in diese Diskussion einzubinden, ist, am Ende eines jeden Events eine kleine Mini-Retrospektive zu machen. Das kann z. B. mit einem ROTI oder einer schnellen Plus/Delta abfrage sein. Damit bleibt die Diskussion um die Dauer und Inhalte des Events am Leben. Ein „das haben wir immer schon so gemacht“ wird so deutlich seltener.
Aber wenn ich die Zwecke gar nicht brauche?
Dann brauche ich vermutlich Scrum auch nicht.
Scrum kann nützlich sein, wenn es darum geht, in einem komplexen Umfeld mit einem echten Team eine Lösung zu schaffen. Ein echtes Team zeichnet sich dadurch aus, dass die Mitglieder ein gemeinsames Ziel verfolgen und dabei gegenseitige Abhängigkeiten haben. Gegenseitige Abhängigkeit bedeutet, dass das Ziel nicht durch die Summe der Einzelbeiträge der Teammitglieder erreicht werden kann, sondern nur wenn durch enge Kooperation Synergien entstehen.
Wenn die gegenseitige Abhängigkeit nicht oder nur rudimentär vorhanden ist, braucht man tatsächlich Sprint Planning und Daily Scrum in der Scrum-Form nicht mehr und Retrospektiven vermutlich weniger häufig.
