Scrum – Ein Einblick

Worum geht es?

Scrum [skrʌm] ist die agile Sau, die seit einigen Jahren immer schneller nicht nur durch die Softwaredörfer der Welt gejagt wird. Mittlerweile suhlt sie sich auch in anderen Pfützen. Doch Spaß beiseite: was bedeutet Scrum, was heißt agil. In den nächsten Zeilen, versuche ich, Dir eine Erklärung zu geben.

Agile Softwarentwicklung nach Scrum

Scrum (zu deutsch „Gedränge“) ist in der eigentlichen Bedeutung ein Spielzug aus dem Rugby. Hierbei handelt es sich um eine Standardsituation, mit der das Spiel nach kleineren Verstößen neu begonnen wird. In die Welt der agilen Softwarentwicklung übertragen bedeutet dies:

Scrum ist empirisch, es ist inkrementell und iterativ. Hä? Ok, nochmal auf Deutsch: Scrum basiert auf der Erfahrung des Teams, welches in der Entwicklung des Produkts schrittweise vorangeht und diese Schritte wiederholt.

In seinem Wesen setzt Scrum auf die Selbstorganisation der Teammitglieder, so dass es den klassischen Projektleiter nicht benötigt.

1990 ins Leben gerufen, wuchs Scrum in der Dunkelheit der Entwicklerschmieden und im Schatten der Wasserfälle auf und mauserte sich heimlich still und leise über die Jahre zu einer anerkannten Projektmanagement-Methode.

Das Team und die Rollen

Product Owner

Der Product Owner (PO) erarbeitet eine konkrete Vision eines Produktes. Dies kann sowohl digital als auch "stofflich" sein. Seine Aufgabe ist es, fachliche Anforderungen an das Produkt zu stellen und diese zu priorisieren. Der PO handelt stets als Einzelperson. Er hat weder ein Gremium noch eine andere Art von Gruppe hinter sich.

Entwicklungsteam

Das Entwicklungsteam liefert das Produkt in eigener Verantwortung. Die Reihenfolge der fertig zu stellenden Eigenschaften des Produkts gibt der PO vor und das Team setzt diese selbstorganisiert um.

Scrum Master

Der Scrum Master trägt dafür Sorge, dass das Team ungestört arbeiten kann, das es also "funktioniert". Hierbei hat er keinesfalls die Rolle eines Projektleiters inne, vielmehr übernimmt er den Posten eines Moderators. Er lässt weder Störungen von außen noch von innen zu und er sorgt dafür, dass die Kommunikation läuft. Außerdem moderiert er die zahlreichen Meetings, die mit Scrum einhergehen (übrigens der Kritikpunkt vom Scrum-Gegnern innerhalb der Organisation schlechthin). Die häufigste Störung von außen ist übrigens das "Reinschieben" von Anforderungen in das Sprintbacklog.

Hiermit sind die Scrum-Rollen im Wesentlichen erklärt. Auf weitere Rollen wie beispielsweise der Scrum Customer (Auftraggeber) oder die User werde ich an dieser Stelle nicht eingehen.

Der Ablauf

Scrum verläuft in sogenannten Sprints. Das bedeutet, dass die Projektlaufzeit in Etappen eingeteilt wird. Ein Sprint kann zwischen 5 und 30 Tagen dauern. Kürzere bzw. längere Zyklen erscheinen als nicht sinnvoll. Innerhalb eines Sprints werden dem Produkt entweder neue Funktionen hinzugefügt oder bereits vorhandene werden verbessert. Ein Sprint ist zeitlich und inhaltlich fix, er darf nicht ausgedehnt werden. Sollte man während eines Sprints merken, dass wesentliche inhaltliche Änderungen geändert werden müssen, kann bzw. muss der Sprint abgebrochen werden.

Der wichtigste Punkt bei der ganzen Geschichte ist, dass am Ende eines jeden Sprints ein funktionsfähiges (Zwischen-) Produkt ausgeliefert wird. Dieses wird dem Auftraggeber zur Überprüfung vorgelegt und er gibt sein Feedback. Je nachdem wie dieses ausfällt, wird an dem Produkt weitergearbeitet.

Artefakte

Product Backlog

Das Product Backlog ist die Sammlung von Anforderungen (Requirements). Er wird vom Product Owner gepflegt und weiter entwickelt. Er ordnet die Einträge und sorgt für deren Priorisierung.

Sprint Backlog

Im Sprint Backlog ist die Auswahl aller Anforderungen aus dem gesamten Anforderungskatalog, die innerhalb eines Sprints bearbeitet werden sollen. Hieraus leitet sich dann die Funktionalität des nächsten Product Increments ab.

Product Increment

Das Product Increment ist das funktionsfähige Zwischenprodukt am Ende des Sprints.

Aktivitäten

Kommen wir zum wichtigsten Aspekt in der agilen Zusammenarbeit, der gleichzeitig der größte Kritikpunkt auf Seiten der Gegner ist: die Kommunikation.
Die oberste Regel für Meetings im Scrum: alle Termine sind time-boxed. Das bedeutet: ist die Zeit abgelaufen, ist das Meeting vorüber. Nach anfänglichen Diskussionen wird sich das Team selbst erziehen und sich so timen, dass sie bereits nach wenigen Terminen die Meetingdauer einhalten werden.

Sprint Planning

Im Sprint Planning wird der nächste Sprint, also der nächste Entwicklungszyklus geplant. Dabei werden die Anforderungen in konkrete Aufgaben (Tasks) zerschnitten. Diese Tasks sollten im Idealfall innerhalb eines Tages bearbeitet werden können. Das Ziel des Sprint Plannings ist das gefüllte Sprint Backlog.

Daily Scrum

Das Daily (auch Standup genannt) ist schnell erklärt. Das Team kommt täglich zu einem immer gleichen Zeitpunkt und Ort zusammen und jeder einzelne berichtet, welche Aufgaben er seit dem letzten Daily erledigt hat und welche gerade vor ihm liegen. Der Termin dauert eine Viertelstunde, nicht länger. Sollte weiterer Diskussionsbedarf bestehen, etwa über mögliche Hindernisse, so kann dies nach dem Termin besprochen werden.

Sprint Review

Der Sprint Review findet am Ende eines jeden Sprints statt. Moderiert und organisiert wird es - wie alle anderen Termin auch - durch den Scrum Master. Die Vorstellung des Sprintergebnisses erfolgt durch das Entwicklungsteam. Es erfolgt ein Feedback durch den PO / Stakeholder und weitere Schritte werden besprochen.

Sprint Retrospective

Die Retrospektive ist der KVP im Scrum, also der kontinuierliche Verbesserungsprozess. Hierbei geht es weniger um fachlich-inhaltliche Themen, als vielmehr darum, die Zusammenarbeit des Teams zu verbessern und voranzubringen.

Product Backlog Refinement

Hin und wieder taucht der Begriff des Backlog-Refinements auf. Dies ist letzten Endes eine Art Vorabplanning. Hierbei konkretisiert, aktualisiert und priorisiert der PO das Product Backlog.

Kritik ... gibt es auch

In einer optimalen Welt funktioniert Scrum wunderbar. Jedoch in einer Organisation, die nicht in der agilen Kultur unterwegs ist - die agilen Denkansätze also nicht nachvollziehen kann - wird Scrum scheitern. Diesbezüglich habe ich meine eigenen Erfahrungen gemacht. Auch wenn es nur wenige Regeln im Scrum gibt, so ist deren Einhaltung aus meiner Sicht dringend nötig. Beachtet man diese Regeln nicht, endet das Projekt schlimmstenfalls im Desaster.

Auch wenn Scrum als Framework "verkauft" wird, so ist es nicht irgendeine Toolbox, aus der ich mir herauspicke, was ich gerade für richtig halte. Scrum funktioniert nur in seiner Gesamtheit. Und wenn ich agiles Vorgehen gleichsetze mit: Ich kann machen was ich will, dann sieht meine Software oder welches Produkt auch immer hinterher genau so aus: chaotisch.

Lässt sich die Organisation jedoch in ihrer Gesamtheit auf die agilen Muster ein, funktioniert das System.