Bei SCRUM handelt es sich um eine Sammlung von Ereignissen, die sich an agilen Grundsätzen orientieren. Jeder der folgenden Absätze beschreibt eines dieser Ereignisse und erklärt dessen Nutzen im Sinne des Agilen Manifests.

Daily SCRUM

Das Daily SCRUM Meeting ist ein lösungsorientiertes Meeting und damit kein einfaches Status Meeting. Ziel ist es, den Weg für die Erfüllung des jeweiligen Sprint Ziels zu ebnen. Um dies zu erreichen, soll jedes Teammitglied kurz und präzise auf die folgenden Punkte eingehen: Seinen Fortschritt, seine nächsten Schritte, seine Hindernisse bei der Zielerreichung.
Um diesen Prozess zu unterstützen, orientiert sich jeder Teilnehmer anhand des Taskboards. Das Daily SCRUM bedient somit gleich mehrere Punkte des Agilen Manifests. Das Meeting stellt sicher, dass sich Entwickler nicht in einer Sache verkopfen, sondern bei einer einfachen Lösung bleiben. Dies geschieht zum Beispiel dadurch, dass jeder bemerken kann, dass ein Teammitglied schon den dritten Tag in Folge an einem Task arbeitet, der doch eigentlich recht fix erledigt sein sollte. Hierfür ist es vor allem wichtig den anderen Teilnehmern aktiv zuzuhören! Gerade deshalb besteht hier Face-to-Face Pflicht, um zu verhindern, dass mancher Teilnehmer nach gesprochener Pflicht wieder fröhlich drauf los klickt oder nochmal im Bürostuhl einnickt. Und wie wir uns erinnern, ist Face-to-Face Kommunikation sowieso ein agiles Prinzip. Wichtig ist auch die genaue Zeitvorgabe von 15 Minuten und keiner Minute länger (Timeboxing). Kommen Themen auf, die weiterer Diskussion bedürfen, werden diese im Anschluss an das Daily von den Beteiligten besprochen.
Das Daily SCRUM fördert die Transparenz des Entwicklerteams untereinander, beseitigt Hürden und sichert das Sprintziel. Dementsprechend wichtig ist es als Entwickler auf Probleme einzugehen und nicht zu versuchen diese zu verschleiern, im Sinne von „es könnte ja ein schlechtes Bild auf mich werfen“.

Sprint Planning

Das Sprint Planning hat als Ziel die Arbeit der nächsten 2-4 Wochen (je nach Länge des Sprints) zu planen. Das Ergebnis des Sprint Planning ist ein Sprint Backlog, der alle zu erledigenden Aufgaben enthält. Diese Liste an Aufgaben wurde vom Team entweder während des Sprint Planning oder meistens bereits davor in einem sogenannten Grooming geschätzt.
Bereits bei der Schätzung gilt es ein wichtiges agiles Prinzip einzuhalten, das erst im letzten Teil der Artikelreihe erwähnt wurde: das gleichbleibende Tempo. Erfolgt in einem Team die Bewertung des Fortschritts beispielsweise anhand ihrer pro Sprint erreichten Story-Point Zahl, neigen die Teammitglieder vielleicht dazu Tasks höher zu schätzen, um anschließend mehr Points pro Sprint zu bewältigen.
Dasselbe gilt für das eigentliche Planning, das bitte auch wieder Face-to-Face stattfindet, damit auch jeder dabei ist und nicht plötzlich in seinen Mails oder am Handy versinkt. Jedes Planning sollte (bei einem eingespielten Team) dieselbe Anzahl an Story Points für den nächsten Sprint einplanen. Durch diese Konstante, auch Velocity genannt, wird agile Entwicklung planbar. Wenn ein Team pro Woche X Story Points schafft, schafft es in 4 Wochen 4 * X Story Points.
Ein weiteres Prinzip, das ebenfalls in dieser Artikelreihe thematisiert wurde, ist das Belangen, Mehrwert für den Kunden zu liefern. Das bedeutet, dass auch jeder Sprint für den Kunden einen konkreten Mehrwert liefern muss. Aus diesem Grund wird jedem Sprint ein Name zugewiesen, der das Sprint Ziel beschreibt, z.B. „Warenkorb-Funktionalität“. Der Name sollte aussagekräftig genug sein, um den gelieferten Mehrwert direkt greifen zu können.

SCRUM Ereignisse auf einen Blick

Sprint Review

Das Sprint Review ist der Höhepunkt des Sprints für den Kunden. Jetzt wird ihm vorgeführt was die letzten 2 bis 4 Wochen erreicht wurde. Neben den üblichen Spielregeln, wie insbesondere Face-to-Face, kommt hier ein weiteres wichtiges agiles Prinzip zum Tragen: Das wichtigste Fortschrittsmaß ist funktionierende Software. Das Software Produkt muss am Tag des Review funktionieren, hier werden keine „ja, aber es kann gerade nicht verwendet werden“-Versionen abgeliefert. Enthält ein Task einen Fehler, ist er somit nicht abgeschlossen – kein Fortschritt.
Weiterhin wichtig bei der Planung der Reviews ist es genau wie beim Planning kontinuierlich Werte zu liefern. Reviews erfolgen in regelmäßigen Abständen, nämlich immer zum Sprintende.
Werden vom Kunden während des Reviews Wünsche geäußert oder Kritik gesprochen, so gilt es sich daran zu erinnern, offen für Änderungen zu sein. Das bedeutet aber nicht stur das zu programmieren was der Kunde diktiert, sondern vielmehr zusammen eine geeignete Lösung zu finden.

Sprint Retrospektive

Zu guter Letzt die crème de la crème, die Retrospektive. Das Ziel der Retrospektive ist ganz klar Inspect and Adapt. Das Team reflektiert den vergangenen Sprint und überlegt wie es sich in Zukunft verbessern kann. Wie genau eine solche Retrospektive im Detail abgehalten wird, würde den Rahmen dieses Artikels sprengen. Allerdings muss jedem klar sein, dass diese kontinuierliche Verbesserung unerlässlich ist, wenn man nach agilen Prinzipien und SCRUM arbeiten möchte.

Fazit

Das ist sie also, meine Brücke zwischen agilen Prinzipien und SCRUM. Natürlich finden auch alle weiteren Prinzipien, die in diesem Artikel noch keine Beachtung gefunden haben, in SCRUM ihre Anwendung. Dann aber vor allem auch im Projektalltag und dies erfordert ein agiles Mindset.
Dieses Fazit ist zugleich auch das Fazit der gesamten Artikelreihe, die über die letzten Monate entstanden ist. Wie lange es braucht bis man agile Prinzipien verinnerlicht hat, ist von Fall zu Fall unterschiedlich. Manche verfügen von vornherein über ein agiles Mindset, bzw. das entsprechende Werteempfinden, andere eher weniger. Allerdings kann jeder lernen anhand dieser Prinzipien zu arbeiten. Selbstkontrolle und ehrliches Reflektieren sind die Devise. Regelmäßige Verbesserung ist das Stichwort.