Vor vielen Jahren revolutionierte Scrum als Ansatz für Projektmanagement die Szene enorm. Übernommen aus dem Rugby-Sport wurde es schnell Best Practice in der Softwareentwicklung. Jedoch kann Scrum auch auf jegliche andere Branchen und Projekte angewendet werden. Dabei ist die Größe des Teams auch eher unwichtig, insofern alle wichtigen Rollen besetzt werden. Dies ist nämlich auch des Pudels Kern: Scrum enthält keine konkrete Methodik für die operative Umsetzung von Aufgaben. Es bezieht sich auf das Prozessmanagement innerhalb des Projekts und bietet nach wie vor viele Freiheiten.

Software schön und gut, aber welche Vorteile bietet der Ansatz generell?

Was ist Scrum?

Bei Scrum handelt es sich um ein sogenanntes Rahmenwerk für agiles Projektmanagement. Dabei bedeutet „agil“ so viel wie die Steigerung von Reaktionsfähigkeit durch häufigere Tests oder auch Feedback. Der Ursprung des Namens kommt von einem Spielzug im Rugby, welcher eine Wiederholung oder einen Neustart des Spielzugs selbst zur Folge hat. Man „fängt quasi von vorne an“. Dies ist auch in gewisser Weise mit einem Lernprozess verbunden.

Am Anfang eines Projektes steht in der Regel der Kunde mit seinen Anforderungen an das Ergebnis. Diese sind häufig nicht klar definiert und erfordern wiederholtes Nachfragen. Im Grunde genommen muss eine Übersetzung der Anforderungen in Aufgaben oder ToDos erfolgen. In der Industrie und speziell der Softwareentwicklung spricht man hierbei von der Übersetzung des Lastenhefts ins Pflichtenheft. Da dies häufig zu Missverständnissen führt, gibt es den sogenannten Product Owner. Dieser ist das Bindeglied zwischen Kunde und Team und „übersetzt“ die Anforderungen in Aufgaben oder Tasks.

Während des eigentlichen Ablaufs finden in regelmäßigen Abständen Absprachen des Teams mit dem Product Owner statt. Das Ziel dessen ist eine transparente Feedback-Kultur und frühzeitiges Korrigieren von Fehlern. Durch die begrenzte Freigabe und Aufnahme von Aufgaben durch das Team hält sich die Planung auch in Grenzen und unterstützt den besagten Sachverhalt. Der Scrum Master hilft genau dabei, indem er die besagten Prozesse einhält und auf Termine und Fristen hinweist. Ohne aktiv an der Entwicklung teilzunehmen, wacht er über dem Team und leitet sie zur richtigen Umsetzung von Scrum. Es ist nämlich nur dann effektiv, wenn man es kontinuierlich lebt.

Wie ist der Ablauf von Scrum?

Bereits jetzt sind schon einige neue Begriffe dazugekommen. Bringen wir nun alles in ein einheitliches Bild. Dabei soll gar nicht zu sehr auf Details eingegangen werden, da dieser Artikel Scrum nur als groben Wegweiser darstellt und wir Dich als Anwender nicht eng daran binden möchten. Nach wie vor ist es wichtig, seine eigenen Best Practices zu entwickeln. Zusätzliche Informationen findest Du hier.

Die drei Rollen Product Owner, Srum Master und das Entwickler-Team agieren in sogenannten Sprints. Diese stellen den Zeitraum dar, in welchem die Entwicklung selbst stattfindet. Für die besagte Transparenz dient ein täglich stattfindendes Daily Scrum, an welchem alle Rollen teilnehmen und den aktuelle Stand besprechen.

Wie in der oberen Abbildung zu sehen ist, gibt es einen klaren Prozess bei der Bearbeitung von Aufgaben. Wie in unserem Beitrag zu Kanban gibt es einen sogenannten Product Backlog, welcher alle bisher nötigen, jedoch nicht terminierten Aufgaben enthält. Dafür ist wiederum der Sprint Backlog da, welcher den Workload für den nächsten Sprint absteckt. Die Planung dessen findet im Sprint Planning vor dem Produktivstart des eigentlichen Sprints statt.

Die Dauer eines Sprints kann variieren und soll dem Team bestmöglichen Komfort bieten. Wichtig ist nur, dass das Projektteam die täglichen Meetings nicht vernachlässigt. Ist der Sprint wiederum abgeschlossen und alle geplanten Aufgaben erledigt, kann die Sprint Review stattfinden, welche zur Evaluation der Ergebnisse dient. Um die Feedback-Kultur fest zu etablieren, können alle Beteiligten in einer (meistens monatlichen) Sprint Retrospektive über organisatorische Aspekte sprechen und ihre Meinung kundtun. Die Rolle des Scrum Masters steht hier noch mehr im Fokus.

Wie lege ich den Workload fest?

Es ist nicht überlebenswichtig, die Dauer der Sprints so einzuhalten, wie es in der Literatur festgelegt ist. Je nach Komplexität der Aufgaben sind Anpassungen möglich. Doch wie schätzt man diese Arbeitsaufwände für einzelne Aufgaben ein?

Hier liegt ein weiterer Knackpunkt. Erfahrene Anwender von Scrum (insbesondere der Product Owner) sind in der Lage, mithilfe eines Punktesystems den Arbeitsaufwand von Aufgaben nach Dauer zu quantifizieren. In diese Dauer fließt wiederum ein Multiplikator ein, insofern Absprachen oder kreative Aspekte notwendig sind. Alles in allem steht mit sogenannten „Personentagen“ die ideale Bewertungseinheit zur Verfügung. Natürlich ist es über die Zeit hinweg wichtig zu überprüfen, ob der Workload noch zu bewältigen ist. Darum sollte das Team immer wieder evaluieren, wie viele Personentage oder -stunden möglich sind. So kann die Zielerreichung auch langfristig eingehalten werden.

Was bringt mir diese Agilität in meinen Projekten?

Die Arbeit mit Inkrementen und regelmäßigem Austausch zwischen Team und Kunden (über den Product Owner) verbessert nachhaltig die Kontrolle über eigene Arbeitsergebnisse. Man hält diese Transparenz aufrecht und hat immer den Überblick, wie die Zielerreichung des Projekts voranschreitet.

Die bessere Kontrolle über Arbeitsergebnisse soll langfristig mehr Profit ermöglichen. Da wir heute im Zeitalter der Kundenorientierung (und nicht mehr Produktorientierung) leben, ist die enge Zusammenarbeit mit dem Kunden unerlässlich. Wir wollen diesen langfristig an uns binden und zufriedenstellen. Durch immer neue Märkte und den Zugang zu Informationen können Kunden aus einer riesigen Menge ähnlicher Produkte oder Leistungen von verschiedenen Anbietern wählen. Dabei spielen Zusatzleistungen eine immer wichtigere Rolle.

Hält man seine Ergebnisse transparent und etabliert eine gesunde Feedback-Kultur, steigert man automatisch die Produktivität und Qualität der Ergebnisse. Dies kommt auch daher, weil man seine eigene Vorgehensweise hinterfragt und optimiert. Natürlich ist dabei auch die eigene Einstellung wichtig. Aus der besseren Qualität und Optimierung der internen Prozesse ist das Potential der Wertsteigerung für Kunden und der Wert der eigenen Leistung wiederum enorm groß.

Die einzelnen Rollen müssen zudem (je nach Größe des Teams) nicht einzelnen Beteiligten zugeordnet werden. Es ist durchaus möglich, dass ein Entwickler die Rolle des Product Owners einnimmt. Worauf Du achten musst ist dennoch, dass der grundsätzliche Prozess einzuhalten ist.