Das SCRUM Projektmanagement ist eine agile Methode für die Durchführung und Organisation von Softwareprojekten. Das SRCUM Management wirkt empirisch, iterativ und inkrementell. Einfacher formuliert bedeutet es, dass der Prozess aufgrund neuer Erfahrungen wiederholt und das Produkt so schrittweise angepasst wird. Auch wenn SCRUM ursprünglich für Software-Engineering konzipiert wurde, kann man es auch für andere Projekte anwenden. Im Rahmen meines Studiums hatte ich schon Gelegenheit, mit diesem Modell zu arbeiten. Es basiert auf drei verschiedenen Artefakten und drei verschiedenen Rollen. Grundsätzlich wird an dem Projekt immer in Zyklen gearbeitet, welche man Sprints nennt. Am Ende einer Einheit kann so reflektiert und weiter geplant werden.
Die Akteure von SCRUM
Die drei verschiedenen Rollen sind der Product Owner, der SCRUM Master und das Entwicklungsteam. Der Product Owner trägt die Verantwortung über das Projekt bzw. das Produkt und hat das Product-Backlog zu führen. Der SCRUM Master organisiert das Team und sorgt dafür, dass die SCRUM Regeln eingehalten werden. Er vertritt das SCRUM Team auch gegenüber externen Stakeholdern. Das Entwicklerteam hat die Aufgabe, das eigentliche Produkt zu erstellen und trägt dafür kollektiv die Verantwortung gegenüber dem SCRUM Team. Das Entwicklerteam führt auch das Sprint Backlog.
Der Ablauf des SCRUM Projektmanagements:
Product Owner, SCRUM Master und das Entwicklerteam arbeiten in periodischen Abständen am Softwareprojekt. Diesen Zeitraum nennt man Sprint. Der Sprint beginnt mit der Sprint Planungssitzung. Diese Sitzung wird vom SCRUM Master geleitet und organisiert. Damit wird der Sprint eingeleitet. Für die Dauer des Sprints wird max. 1 Monat vorgegeben.
Während dieser Zeit arbeitet das Entwicklungsteam an der nächsten Version des Productinkrements (des Produkts). An jedem Arbeitstag findet der sogenannte Daily SCRUM statt. Dies ist ein Ritual, in welchem sich die Entwickler besprechen und die nächsten 24 Stunden planen. Diese Besprechung soll ca. 15 min dauern. Der Daily SCRUM wird vom Entwicklungsteam selbst organisiert.
Am Ende eines jeden Sprints wird das Productinkrement im Sprint Review geprüft. Zu dieser Gelegenheit kann der Product Owner Funktionen im Product Backlog auf „done“ setzten. Dies liegt in seinem Ermessen. Der SCRUM Master plant dieses Treffen und kann auch andere Stakeholder dazu einladen. Dieses Treffen dauert 4 Stunden.
Zwischen der Sprint Review und der Sprint Planungssitzung findet die Sprint Retrospektive statt. Hier werden Verbesserungsmöglichkeiten für zukünftige Sprints ermittelt.
Die SCRUM Artefakte
Wie bereits angesprochen gibt es beim SRCUM Management drei Artefakte. Diese Artefakte müssen stets auf dem neusten Stand, fehlerfrei und detailliert sein. So kann im Ablauf immer geprüft werden, welche Aufgaben schon erledigt sind und welche Aufgaben noch anstehen. Ebenfalls ist es wichtig, dass diese allen berechtigten Interessensgruppen zu Verfügung stehen. Die Artefakte beinhalten alle Informationen zum aktuellen Stand des Projekts. Es ist die Aufgabe des SCRUM Masters die Validität der Artefakte zu überprüfen. Er ist dafür verantwortlich, dass die Artefakte stets up-to-date sind. Für den Inhalt der Artefakte ist er nicht verantwortlich. Es handelt sich bei den SCRUM Artefakten um den Product Backlog, den Sprint Backlog und das Produktinkrement.
Das Product Backlog kann man mit einem Lasten- oder Pflichtenheft vergleichen. Im Product Backlog stehen alle Anforderungen, die das Produkt erfüllen soll. So gibt es eine Definition des Produktes vor. Der Product Owner ist für das Product Backlog verantwortlich. Die Inhalte werden darin vom Product Owner priorisiert und erstellt. Das sind in der Regel Attribute und Funktionen an die Software bzw. an das Produkt. Pro Produkt gibt es folglich nur ein Product Backlog und einen Product Owner. Das Product Backlog wird stetig ergänzt und angepasst. Selbst während der Softwareentwicklung können Funktionen geändert oder verschieden priorisiert werden. Abgeschlossen ist das Product Backlog niemals. Das Product Backlog enthält auch immer den passenden Status zur Funktion. Beispielsweise kann eine Funktion den Status „done“ haben, ein anderer Status hingegen wäre „ready“. In dem letzten Fall kann mit der Ausarbeitung der Funktion begonnen werden.
Das Sprint Backlog ist die Auflistung aller Arbeitsschritte, die im Product Backlog auf „ready“ gesetzt sind. Das Sprint Backlog ist sozusagen die „To-Do Liste“ für das Entwicklerteam. Da der Ablauf des SCRUM Projektmanagements in Zyklen aufgeteilt ist, steht ein Sprint Backlog immer nur für einen Sprint (der Zyklus). Anhand des Sprint Backlogs kann und muss das Entwicklerteam feststellen wie lange es noch für die Abarbeitung der Aufgaben benötigt. Gegebenenfalls können neue Aufgaben in einem Sprint hinzugefügt werden, so kann das Entwicklerteam intern Zeitmanagement betreiben. Vollendete Aufgaben können am Ende des Sprints im Product Backlog auf „done“ gesetzt werden.
Das Productinkrement ist die aktuelle Version der Software/ des Produkts. Das Productinkrement muss von Anfang an funktionstüchtig sein und (theoretisch) auslieferbar sein. Bewertet wird es am Ende eines Sprints. Ziel ist es, dass die aktuelle Version immer den Anforderungen aus allen vorigen Sprints genügt.
Fazit
Meiner Meinung nach ist das SCRUM Management bestens geeignet für agile Softwareentwicklung und Projektplanung. Ich finde es sehr nützlich, dass das Entwicklerteam immer wieder die Möglichkeit bekommt zu reflektieren und sich abzusprechen. Missverständnisse werden vermieden und man bleibt zielorientiert. Ideal wird die SCRUM Organisation dann, wenn die Leitung des SCRUM Masters redundant wird. Das Projektmanagement ist perfekt, wenn der SCRUM Master das Team nicht länger organisieren muss. So findet man leichter in die Eigenorganisation. Die Transparenz und das Arbeiten auf empirischer Wissensbasis wird durch dieses Modell stark gestützt und sollte die Grundlage aller Projekte sein. Der Ablauf ist für jeden zu verstehen und die Planung gut organisiert.
Differenziert muss man jedoch sagen, dass der Kommunikationsaufwand gewaltig ist und viel Zeit und Energie beansprucht. Das kann eventuell den Abschluss verzögern. Für dieses Modell muss die Bereitschaft aller da sein, sich auf das Konzept einzulassen und die SCRUM Regeln zu befolgen. Das ist eventuell nicht gegeben.