Was ist Scrum und was sind mögliche Hindernisse?

Professional Scrum Master (PSM I)Scrum ist ein Framework, das mich bereits seit meinem Studium an der Technischen Universität Darmstadt beschäftigt. Die Theorie ist einfach und einleuchtend, doch die Umsetzung gilt als kompliziert. Als Professional Scrum Master (PSM I) kenne ich die Theorie und in den vergangenen Jahren habe ich als Entwicklungsleiter Scrum anwenden dürfen. Ich möchte versuchen Scrum kurz zu erläutern, um einen Überblick zu verschaffen.

Was ist Scrum und welche Regeln gibt es vor?

Bei Scrum handelt es sich um ein Framework. Oft wird behauptet Scrum sei eine Projektmanagement-Methode, was allerdings nicht stimmt. Scrum ist auch nicht ausschließlich für die Softwareentwicklung vorgesehen. Stattdessen kann es für alle möglichen Projekte eingesetzt werden und gibt hierfür ein Grundgerüst vor.

Es gibt einen Sprint, der nicht länger als 4 Wochen sein sollte. Direkt im Anschluss an einen Sprint folgt der nächste Sprint, was bedeutet, dass alle anderen Events innerhalb eines Sprints stattfinden. Es gibt vier Arten von Events: Daily Scrum, Sprint Planning, Sprint Review und Sprint Retrospective. Jedes Event dient der „Inspection and Adaption“, also der Prüfung und Anpassung.

Am Anfang eines Sprints wird mit dem Sprint Planning der Product Backlog geprüft und ein Sprint Backlog erstellt sowie ein Sprint Goal formuliert. Jeden Tag findet ein Daily Scrum statt, um den Fortschritt zu prüfen und falls nötig Schritte einzuleiten, um das Sprint Goal zu erreichen. Am Ende eines Sprints findet das Sprint Review statt, in dem das sogenannte Product Increment geprüft und der Product Backlog angepasst werden. Im anschließenden Sprint Retrospective wird die Zusammenarbeit geprüft und es werden Anpassungen geplant, um den nächsten Sprint noch produktiver zu gestalten.

Jedes Event hat zusätzlich eine sogenannte Timebox und ist damit auf eine maximale Dauer begrenzt. Das Daily Scrum dauert maximal 15 Minuten und das Sprint Planning 8 Stunden. Sprint Review und Sprint Retrospective haben jeweils eine maximale Dauer von 4 und 3 Stunden. Dies gilt bei einer Sprintlänge von 4 Wochen. Bei kürzeren Sprints werden die Timeboxen der Events entsprechend angepasst. Dies ist jedoch nur eine grobe Zusammenfassung. Wer die Details der einzelnen Events verstehen möchte, der sollte sich den Scrum Guide durchlesen.

Welche Rollen und Aufgaben gibt es?

Das Framework Scrum gibt exakt drei Rollen vor: Scrum Master, Product Owner und das Development Team. Richtig, das Team zählt als eine Rolle. Hier gibt es keine einzelnen Mitglieder des Teams wie Tester oder DevOps-Experten. Das Team ist eine Rolle und als Ganzes für seine Aufgaben verantwortlich. Dank des Product Owners kennt das Team die Anforderungen und arbeitet selbst- und eigenständig an einer Lösung, um das Sprint Goal zu erreichen und ein Product Increment zu liefern. Was die Größe des Teams angeht wird häufig auf die Regel „7 +/- 2“ verwiesen. Dies würde einer Mitgliederanzahl von 5 bis 9 entsprechen. Tatsächlich steht im Scrum Guide aber, dass das Team nicht weniger als 3 und nicht mehr als 9 Mitglieder haben sollte.

Der Product Owner maximiert den Wert des Development Teams. Dazu gehört die Analyse von Anforderungen und das Setzen von Prioritäten. Damit muss der Product Owner ein Experte im Anwendungsgebiet des Produktes sein. Die einzelnen Aufgaben bzw. Features im Product Backlog werden durch den Product Owner nach Priorität sortiert, denn er kennt die übergeordneten Ziele.

Die dritte Rolle ist der Scrum Master. Er sorgt dafür, dass Scrum korrekt angewendet wird und alle Beteiligten Scrum verstanden haben. Bei den Events beispielsweise achtet der Scrum Master darauf, dass die Timeboxen nicht überschritten werden. Er berät das Team auf Anfrage in Selbstorganisation oder den Product Owner in Product-Backlog-Management.

Wo können bei der Anwendung nun Hindernisse entstehen?

Scrum ist wie gesagt ein Framework und bietet somit ein Grundgerüst zum Vorgehen in Projekten. Die Herausforderungen entstehen allerdings in der Praxis, vor allem bei einem Scrum Master mit wenig Erfahrung. Wenn in einem Unternehmen zu Scrum gewechselt wird, dann ändert sich häufig nicht viel. Das liegt vor allem an einem großen Problem des Menschen: der Gewohnheit. Das Team ist es vielleicht gewohnt, die Prioritäten im Backlog selbst zu bestimmen, da es bislang keinen Product Owner gab oder dieser seine Verantwortung nicht wahrgenommen hat. Einen Scrum Master gab es natürlich auch nicht. Team Meetings wurden dementsprechend nur bei Bedarf oder unregelmäßig abgehalten. Strukturiert waren diese Meetings nicht oder nur schlecht.

Mit Scrum wird angestrebt nach jedem Sprint ein Product Increment und damit eine fertige Version abzuschließen, die veröffentlicht werden kann, aber nicht muss. Ob das Product Increment veröffentlicht wird, das entscheidet der Product Owner. Bei einer Sprintlänge von beispielsweise 4 Wochen, ist somit in festen Zeitabschnitten eine neue Version verfügbar. Ein Team, das bislang nicht mit Scrum und somit nicht mit Sprints gearbeitet hat, wird sich auch hieran erst gewöhnen müssen. Auf Cyril Northcote Parkinson geht das Parkinsonsche Gesetz zurück: „Arbeit dehnt sich in genau dem Maß aus, wie Zeit für ihre Erledigung zur Verfügung steht.“

„Work expands so as to fill the time available for its completion.“

Ist es ein Team nicht gewöhnt in einem fest vorgegebenen Zeitraum ein Product Increment zu liefern, wird es sich möglicherweise zu viele Backlog Items vornehmen. Es können einige Monate vergehen, bis eine neue Version veröffentlicht werden kann. Wie wichtig ein frühzeitiges Release sein kann, selbst wenn es noch nicht alle geplanten Features enthält, werden so manche Product Owner bestätigen können.

Dieser Artikel soll nur einen kurzen Einblick gewähren. Bei Interesse an diesem Thema werden weitere Artikel zu meinen Erfahrungen in der Praxis von Scrum, den häufigen Fehlern bei der Anwendung sowie Tipps zur Umsetzung folgen.