Du bist auf der Suche nach einer agilen Methode, die die Arbeitsprozesse deines Projektteams effizienter gestaltet und euch mit Sicherheit zum erfolgreichen Abschluss des Projektes bringt, bei gleichzeitiger Geringhaltung der Overhead-Kosten? Dann könnte dich die Scrum-Methode interessieren! Diese Technik aus dem agilen Projekt- und Produktmanagement stellt ein grundlegendes Rahmenwerk für das gesamte Entwicklungsteam dar. Indem Rollen, Meetings und Artefakte klar definiert werden, ermöglicht die Scrum-Methode eine effiziente und flexible Zusammenarbeit des Projektteams auf dem Weg zur Fertigstellung deines Produktes, wobei eine stetige Anpassung an die wechselnden Anforderungen sichergestellt werden kann. Was das Scrum-Prinzip ist, wo es angewendet werden kann und wer welche Rolle übernimmt, erfährst du hier.
Das Scrum-Prinzip: Was ist das?
Der Begriff „Scrum“ (engl.) hat zunächst einmal nichts mit dem agilen Produkt-, bzw. Projektmanagement zu tun, sondern ist auf die amerikanische Sportart Rugby zurückzuführen und bedeutet übersetzt „angeordnetes Gedränge“. Diese wörtliche Übersetzung spiegelt allerdings den Grundgedanken der agilen Management Methode gut wider: Das Projekt wird in unterschiedliche, gleich aussehende Phasen unterteilt (Sprints), die dicht aufeinanderfolgend vom Projektteam bestritten werden und das Ziel verfolgen, iterativ (Schritt für Schritt) ein fertiges Produktinkrement, bzw. ein fertiges Produkt, auf die Beine zu stellen. Die Rollen und Arbeitsprozesse sind dabei, wie wir im Verlauf sehen werden, klar definiert, sodass die Teammitglieder stets wissen, was ihre Aufgabenstellung ist. Die Scrum-Arbeitsweise stellt jedoch keineswegs eine normative Methode dar, sondern soll vielmehr ein Framework für die Arbeit eines Teams bilden, das auf Prinzipien des agilen Projektmanagements beruht. Effizienz, Flexibilität und Kostensenkung sind dabei wesentliche Gesichtspunkte.
Für die Umsetzung der Technik wird ein interdisziplinär aufgestelltes Projektteam benötigt, das die Verantwortung kollektiv teilt, transparent miteinander kommuniziert und den kontinuierlichen Fortschritt sichert. Durch die Eingrenzung der Phasen auf einen bestimmten und kurzen Zeitrahmen, kann die Vorgehensweise fortwährend an entstehende Veränderungen der Anforderungen und auf die Bedürfnisse des Kunden angepasst werden, mit dem Ziel den bestmöglichen Mehrwert hervorzubringen. Wesentlich ist dabei, dass das Ziel zwar klar vorgegeben ist, das Projektteam jedoch über die Umsetzung entscheidet und somit selbstwirksam arbeitet, was in dem Grundprinzip der Autonomie festgehalten ist.
Scrum: Die Grundprinzipien
- Wertorientierung
Ergebnisse werden an dem Mehrwert für Kunden und Unternehmen gemessen - Vision
Das langfristige Ziel stets im Blick, auf welches hingearbeitet wird - Transparenz
gesamte Dokumentation für jeden Beteiligten, jedes Teammitglied zugänglich - Prozesstreue
Standardisierung der Arbeitsprozesse (-> Transparenz und Sicherheit) - Fokus
Priorisierung der Aufgaben wird konsequent eingehalten - Autonomie
Projektteam arbeitet selbstständig, selbstwirksam und autonom - Feedback
wird zum gegebenen Zeitpunkt von Stakeholdern, Kunden und Anwendern gegeben
Die Scrum-Methode basiert auf einem empirischen (erfahrungsbasierten), inkrementellen (kleinschrittigen) und iterativen (sich wiederholenden) Arbeitsprozess. Dieser Arbeitsprozess wird in zwei- bis vier-wöchige „Sprints“ aufgegliedert, die jeweils folgende Meilensteine abarbeiten:
- Sprint Planning
- Daily Scrums
- Sprint Review
- Sprint Retrospektive
Das Sprintziel ist das Vorlegen eines fertigen Produktinkrements, sodass das Entwicklungsteam Feedback dazu empfangen kann. Doch nach dem Sprint ist vor dem Sprint, denn im Anschluss beginnt direkt die nächste Sprint-Zyklus.
Wer macht was? Die Rollen
Der Product Owner
Der Product Owner, oder auch Produktverantwortliche, hat stets die Bedürfnisse des Kunden vor Augen und die Maximierung des Nutzens des Projekts. Dabei muss er jedoch auch die Bedürfnisse des Teams im Blick behalten, weshalb seine Aufgabe darin besteht eine Balance zwischen beiden Parteien herzustellen. Er entscheidet zudem über die Eigenschaften des Produktes, den Auslieferungszeitpunkt und die Kosten. Dies dokumentiert er in dem sogenannten „Product Backlog“ und hält somit alle relevanten Anforderungen für das gesamte Projektteam fest. Dabei stellt er zudem eine klare Priorisierung heraus, an welcher sich das Entwicklerteam orientieren muss. Die Schwierigkeit darin besteht vor allem in der Abwägung zwischen „Business Value“ und „User Value“, weshalb der Product Owner ein grundlegendes Verständnis der Kunden- und Unternehmensbedürfnisse aufweisen muss.
Das Entwicklungsteam
Das Entwicklungsteam, bestehend aus Developern/ Entwicklern, ist für die Umsetzung der Aufgabenstellungen zuständig. Das Team ist geprägt durch eine interdisziplinäre Besetzung aus Softwarearchitekten, Programmierern, Dokumentationsexperten, Produkttestern, usw.. Sie setzen die im „Product Backlog“ festgehaltenen Anforderungen um, wobei sie jedoch selbst über die Aufgabenzuteilung entscheiden. Dieser Zuteilungsprozess findet während des Plannings statt. Meist besteht das Team aus drei bis acht Personen.
Der Scrum- Master
Den Scrum -Master kann man auch als Moderater des Product Owners und des Entwicklungsteams auffassen. Er stellt die Einhaltung der Rahmenstruktur sicher und überprüft die Befolgung der Prinzipien. Sollte es in der Kommunikation im Team oder zwischen Team und Product Owner Probleme geben, ist er zur Stelle. So unterstützt er das Team und erlaubt diesem die Konzentration auf die priorisierten Arbeitsprozesse. Er ist somit ein wichtiger Baustein der Effizienzsteigerung.
Wie funktioniert die Scrum-Methode? Der Ablauf
Wie bereits beschrieben, unterscheidet sich der Projektablauf nach der Scrum-Methode von dem einer klassischen Verfahrensweise. Die gesamte Entwicklung eines Produkts wird nicht auf einmal geplant, sondern in aufeinanderfolgende „Sprints“ gegliedert, die erst nach und nach (inkrementell) geplant werden. Diese Sprints finden immer in einem bestimmten Zeitfenster, einer „Timebox“, statt. Meist erstreckt sich dieser Zeitraum auf ein bis vier Wochen und ist standardisiert. Jeder Sprint, der sozusagen das oberste Ordnungsprinzip darstellt, ist wiederum unterteilt in Meetings, die jeweils speziellen Zielen und Regeln folgen. Der gesamte Ablauf ist darauf ausgelegt, die Effizienz zu steigern und die Kosten zu senken und dabei das organisatorische Overhead ebenfalls gering zu halten. Wir können also festhalten:
Sprint
- 1-4 Wochen -> Je länger der Sprint, desto mehr sinkt die Planungsqualität
- Fixe Dauer (Änderung nur bei festgestellter effizienterer Dauer -> diese wird dann für die nächsten Sprints beibehalten)
- „Gedränge“ -> vorheriger Sprint geht unverzüglich in den nächsten über
- Abbruch nur in seltenen Fällen, falls Product Owner keinen Wert mehr darin sieht
Scrum Meetings
- klare und standardisierte Abfolge der Meetings in jedem Sprint
- festgelegter Zeitpunkt und Umfang jeden Meetings im Sprint
- jedes Meeting verfolgt bestimmtes Ziel, das allen bekannt ist
1. Sprint Planning
Das Sprint Planning bildet den Beginn jedes Sprints. Hier werden die Aufgaben und deren Umfang diskutiert sowie ein Zeitbudget für jede Task festgelegt. Auf Grundlage dieser Diskussion priorisiert der Product Owner die Arbeitsprozesse und legt das Sprint Ziel fest. Eine effiziente und transparente Kommunikation ist hierbei von großer Bedeutung. Für das Sprint Planning werden bei einem vier-wöchigen Sprint ca. acht Stunden angesetzt und die Ergebnisse im sogenannten „Sprint Backlog“ verschriftlicht. Dies enthält den detaillierten Sprint Plan und kann jederzeit als Referenz herangezogen werden.
2. Daily Scrum
Unter dem „Daily Scrum“ ist ein einmal täglicher Austausch unter den Teammitgliedern zu verstehen. Dieser sollte maximal 15 Minuten in Anspruch nehmen. Alles, was in dieser Zeitspanne nicht gelöst werden kann, wird an den Scrum-Master weitergegeben. Wichtige Fragen, die während des Meetings von dem Entwicklerteam geklärt werden sollten, sind:
- Welche Aufgaben konnten abgeschlossen werden?
- Welche Arbeitsprozesse laufen bis zum nächsten Meeting?
- Sind Hindernisse oder Probleme aufgetreten?
3. Sprint Review
Die Sprint Review bildet das Ende jeden Sprints. Es werden die Ergebnisse, bzw. Inkremente präsentiert und in einer „Demo“ dem Product Owner, den Stakeholdern und dem Kunden vorgestellt. Hier kann und soll Feedback erfolgen, Frage gesammelt werden und Kunde und Stakeholder hat die Chance Einfluss auf die Priorisierung des Product Owners zu nehmen. Wichtig ist hier jedoch festzuhalten, dass es sich noch um keine Abnahme des Produktes handelt. Letztendlich entscheidet der Product Owner darüber, welche Anmerkungen er priorisiert. Grundsätzliche Unzufriedenheiten werden erst in der Retrospektive geäußert.
4. Sprint Retrospektive
Die Retrospektive dient der Überprüfung der gesamten Arbeit des Projektteams und ermöglicht durch ehrliche Reflexion eine stetige Verbesserung der Arbeitsprozesse und Herangehensweisen. Damit dies auch wirklich funktioniert sind die Akzeptanzkriterien zu beachten und eine offene Selbstreflektion an den Tag zu legen. Nur, wenn alle Teammitglieder nach dem Wunsch der Verbesserung agieren, kann die Retrospektive einen Mehrwert bieten. Es werden daher Problematiken und Hindernisse besprochen, alternative Priorisierungen, aber auch positive Aspekte herausgearbeitet, die so weitergeführt werden sollten. Ganz nach dem Prinzip „Drop, Keep, Try“. So entstehen To-Dos für den folgenden Sprint. Den Abschluss des Meetings bildet schließlich eine wertschätzende Danksagung an alle Beteiligten. An der Retrospektive nehmen sowohl das Entwicklungsteam als auch der Product Owner und der Scrum-Master teil.
5. Product Backlog Refinement
Im Gegensatz zu den anderen Meetings folgt das Product Backlog Refinement keiner klaren Struktur. Es handelt sich vielmehr um eine kontinuierliche Aktivität des Product Owners und des Entwicklerteams, bei welcher die Anforderungen an das Produkt verfeinert, Details besprochen und die Einträge in das Product Backlog geordnet werden. Es geht somit um eine Synchronisation zwischen Product Owner und Entwicklungsteam sowie um die Weiterentwicklung des Produktes. Erfolgen kann dies im Vorfeld jeden Sprint Meetings. Allerdings sollte dies nicht mehr als fünf bis zehn Prozent der Timebox während eines Sprints einnehmen.
Artefakte der Scrum-Methode
Die Artefakte, bzw. Werkzeuge, der Scrum-Methode stellen das Product Backlog, das Product Increment und das Sprint Backlog dar.
Product Backlog
Im sogenannten „Product Backlog“ trägt der Product Owner alle Anforderungen und Priorisierungen des Projekts ein. Es kann somit als eine Art To-Do Liste angesehen werden, die stetig an die Veränderungen der Anforderungen angepasst wird. Hier erfolgt aber noch keine Aufgabenzuteilung, denn dies wird im „Sprint Backlog“ von dem Entwicklerteam vorgenommen.
Sprint Backlog
Im Sprint Backlog werden alle Arbeitsprozesse und Aufgaben, die während des Sprints erledigt werden, dokumentiert. Es wird vom Team geführt, welches auch für die Zuteilung der sogenannten „Tickets“, also Aufgaben, zuständig ist. Daraus kann abgelesen werden, wo noch Arbeit investiert werden muss und wie funktionstüchtig das nächste Inkrement ist.
Produktinkrement
Das Produktinkrement ist das Ergebnis eines Sprints. Es ist also ein Zwischenprodukt, dass bereits funktionsfähig ist und wäre theoretisch einsatzbereit. Dies zu entscheiden, unterliegt jedoch dem Product Owner, der festlegt, ab wann das Produkt ausgeliefert werden kann.
Fazit: Vor- und Nachteile der Scrum-Methode
Die Scrum-Methode überzeugt vor allem durch ihre flexible Anwendbarkeit und den geringen administrativen Aufwand. Sie ist dadurch gerade für das agile Produkt- und Projektmanagement eine vielversprechende Methode einen kontinuierlichen Verbesserungsprozess zu gewährleisten und gleichzeitig die Effizienz zu steigern und die Overhead-Kosten zu senken. Trotz dieser Vorzüge ist die Technik nicht auf alle Bereiche ausweitbar, da beispielsweise in Branchen wir der Pharmazie eine detaillierte Dokumentation priorisiert wird. Zudem ist ein derartig großer Kommunikationsaufwand nicht immer umsetzbar. Trotzdem stellt die Scrum-Methode für das agile Projektmanagement eine erfolgreiche Planungsstrategie dar und wird kontinuierlich an die digitale Transformation angepasst. Diese Anpassungen werden unter www.scrum.org dokumentiert. Als Orientierung und Rahmenwerk einer Projektarbeit ist die Verwendung der Scrum-Methode daher äußerst empfehlenswert.
