Scrum (engl. das Gedränge) ist eine Sammlung von Arbeitstechniken, Strukturen, Rollen und Methoden für das Projektmanagement im Rahmen agiler Softwareentwicklung. Es ist ein Vorgehensmodell, das wenige Festlegungen trifft. Teams bzw. Entwickler organisieren sich weitgehend selbst und wählen auch die eingesetzten Methoden. Das Vorgehen und die Methoden werden fortlaufend aktuellen Erfordernissen angepasst.
Die o.g. Beschreibung aus Wikipedia trifft im Großen und Ganzen das, was Scrum ist und wofür es eingesetzt wird. Scrum ist eine relativ junge Verfahrensmethodik in der Software-Entwicklung. Nichtsdestotrotz wird es schon oft und gerne angewendet. Als “Interpretation” des Agilen Manifests gilt Scrum als ein agiles und sehr leichtgewichtiges Rahmenwerk für Management in der Software-Entwicklung.
Ein erster und leicht zu merkender Überblick über Scrum als agiles Framework lässt sich im Kern durch die “3×3″-Regel schaffen:
- Drei Gremien:
- Daily Scrum – Die tägliche Einsatzbesprechung;
- Sprint Planung – Planung eines Arbeitszyklusses;
- Sprint Review – Der Abschluss einer Arbeitsphase und die Abnahme eines Arbeitspaketes.
- Drei Artefakte:
- Product Backlog – Eine priorisierte Liste aller Anforderungen;
- Sprint Backlog – Eine Liste von Aufgaben zur Erfüllung eines Arbeitspaketes;
- Release Plan – Eine Prognose und Vorausplanung der Veröffentlichungsdaten des Produktes.
- Drei Rollen:
- Product Owner – zuständig für den wirtschaftlichen Erfolg und das Produkt;
- Scrum Master – wacht über die Methodik und die Produktivität des Teams;
- Team – das selbst-organisierte, teilautonome Team.
Gremien
Die Hauptaufgabe allen Software-Managements ist unbestritten die Organisation, Koordination und Planung der
Software-Entwicklung. Wie auch bei anderen Management-Frameworks gibt es in Scrum wohldefinierte Ankerpunkte, die die Kommunikation fördern. Wie zuvor schon erwähnt, gibt es dazu in Scum drei wesentliche Gremien (oder Institutionen).
Daily Scrum
Das Daily Scrum (auch “Daily” oder “Huddle”) ist das essentielle Organisations-Element in Scrum. Hier ist die Empfehlung, ein komplettes Team-Meeting (das Daily) jeden Tag zur gleichen Zeit am gleichen Ort durchzuführen. Das Meeting sollte nicht länger als 15 Minuten dauern und dient dem täglichen Status-Austausch und Feedback innerhalb des Teams. Während des Meetings werden die drei sog. “Scrum-Fragen” an jeden Teilnehmer mit der bitte um zügige und kurze Antwort gestellt:
- Was hast Du gestern getan?
“Bist Du gestern mit dem fertig geworden, was Du Dir vorgenommen hast?” - Was wirst Du heute tun?
“Welche Aufgaben wirst Du bis zum nächsten Meeting bearbeiten?” - Alles ok?
“Gibt es ein Problem, das Dich bei Deiner Aufgabe blockiert / hindert?”
Sprint Planung
Zu Beginn eines Sprints wird ein Planungsmeeting abgehalten, bei dem die Ziele und Aufgaben der gesamten Sprintdauer besprochen und geplant werden. Zunächst werden aus dem Product Backlog (der groben Anforderungsliste) die nächsten anstehenden Anforderungen besprochen und geklärt.
Daraufhin wird das sog. “Commitment” durchgeführt; es wird also eine Zusage über die zu erledigenden Dinge innerhalb des nächsten Sprints herbeigeführt. Anschließend wird das Commitment detailliert geplant und die einzelnen Aufgaben zur Erfüllung der Anforderungen abgeleitet. Diese Liste wiederum bildet das Sprint Backlog.
Review & Retro
Nach einem Sprint wird ein sog. Review (meist auch nur “Demo” genannt) durchgeführt. Das Sprint-Review dient vornehmlich zum Vorzeigen und Diskutieren der Ergebnisse des Sprints. Im Review-Meeting wird zumeist die neu geschaffene Funktionalität der Software dem Kunden und dem Team vorgeführt (Demo). Des Weiteren wird ein allgemeines Feedback abgefragt bzw. eine offene Diskussionsrunde abgehalten.
Ähnlich zum Review wird zum Ende eines Sprints auch eine “Retrospektive” abgehalten, in der explizit die Meinungen, Hürden und Verbesserungsmöglichkeiten im Team diskutiert werden. Diese werden festgehalten und für die nächste Sprint-Planung in Betracht gezogen. So können z.B. methodische oder arbeitstechnische Verbesserungen während der Entwicklung erkannt und durchgeführt werden.
Der Unterschied zwischen Review und Retro liegt in der Betrachtungsweise des Sprints: Während beim Review auf das “Was” geachtet wird, liegt der Schwerpunkt der Retro auf dem “Wie”. Nichtsdestotrotz werden Review und Retro öfters in ein Meeting zusammengefasst.
Es fällt deutlich auf, das Scrum wenige Vorgaben enthält und sich gegen definierte Prozesse und Arbeitsabläufe stellt. Der Kern dieser “Scrum-Ethik” bedründet sich durch das Argument, das Software-Entwicklung ein derart komplexer und variabler Prozess ist, dass es niemals in ein definiertes, prozessuales Korsett eingefasst werden kann. Vielmehr wird davon ausgegangen und akzeptiert, das der Prozess der Software-Entwicklung ein semi-chaotischer ist, dem man nur durch empirische Management- und Kontroll-Mechanismen Herr werden kann.
Artefakte
Dementsprechend ist auch das Planungs- und Aufgabenmanagement minimal. Scrum definiert nur drei essentielle Listen.
Product Backlog
Das Product Backlog ist eine Liste mit allen Anforderungen, Aufgaben, Features, Bugs und Problemstellungen für das Produkt. Die einzelnen Einträge in der Product Backlog-Liste werden nach kundenorientierter Priorität (z.B. Geschäftszweck, Benefit) und Komplexität sortiert. Dabei muss es für diese keine Kennzahlen geben, alleine die Sortierung des Product Backlogs ist entscheidend. Die Product Backlog-Liste ist öffentlich für alle Teammitglieder verfügbar und kann jederzeit geändert und erweitert werden. Jeder Eintrag bedarf auch einer ersten Schätzung des Aufwandes.
Sprint Backlog
Der Sprint Backlog ist eine Liste von Aufgaben, die innerhalb eines Sprints (i.d.R. eine 2-4 wöchige Iteration) durchgeführt werden soll. Der Sprint Backlog wird zu Beginn eines Sprints erstellt und innerhalb dessen abgearbeitet. Im Gegensatz zum Product Backlog ist hier die Sortierung nicht entscheidend, kann aber weitergeführt werden.
Viel wichtiger ist hier die Vorgabe, dass eine einzelne Aufgabe des Sprint Backlogs nicht länger als 3 Tage dauern sollte (je kürzer, desto besser). Ist dies dennoch der Fall, sollte die Aufgabe in Teilaufgaben zerlegt werden. Des Weiteren werden beim erstellen des Sprint Backlogs alle Aufgaben nochmals in der Schätzung verfeinert.
Release Plan
Der Release Plan ist eine Liste der definierten “Meilensteine” eines Software-Produkts, bei dem eine Veröffentlichung fachlich, strategisch oder unternehmerisch angebracht ist. Der Release Plan richtet sich nach der “Velocity” des Teams (also nach dem Produktivitätsgrad). Der Release Plan ist zumeist ein Prognose-Barometer und ein Kernelement der Integration des Scrum-Teams in die Organisation eines Unternehmens bzw. anderer Abteilungen.
Rollen
Scrum definiert drei unterschiedliche und klar getrennte Rollen: Den “Product Owner”, den “Scrum Master”, sowie das “Team”. Alle drei verfolgen während des Entwicklungsprozesses das gleiche Ziel, nämlich die “Vision” der zu entwickelnden Software.
Product Owner
Der Product Owner (oder auch nur “Owner”) ist derjenige, der die “geschäftliche” oder “fachliche” Seite der zu entwickelnden Software vertritt. Er ist also letztendlich der Kunde bzw. Kundenvertreter, der die fertige Software entgegennimmt und den Wert der Software ausschöpft. Innerhalb des Scrum ist der Product Owner eine einzelne Person (darauf legt sich das Scrum-Verfahren fest).
Er ist derjenige, der die Anforderungen an die Funktionalität der Software stellt und arbeitet dementsprechend die Anforderungen und Aufgaben mit den anderen Team-Mitgliedern in das Product Backlog ein. Er ist für die Priorisierung der Aufgaben zuständig und damit auch für das Zustandekommen des Sprint Backlogs.
Scrum Master
Der Scrum Master (im Alltag meist nur “SM” genannt) ist eine einzelne Person (auch hier eine Vorgabe von Scrum), die sich um die Einhaltung der Scrum-Regeln und Verfahrensweisen kümmert. Überdies hinaus ist der Scrum Master für “das Wohlergehen” des Teams zuständig – und zwar im Sinne von Problembehebung, Unterstützung, Motivation und Coaching.
Er ist quasi ein “Projekt-Manager-Ersatz”, allerdings ohne Weisungsbefugnis, disziplinarische oder fachliche Führung. Des Weiteren ist der Scrum Master faktisch weder ein Teil des Teams noch aus den Reihen des Product Owners – er hat also eine quasi “unparteiische” Rolle. Obwohl in Scrum oft empfohlen wird, dass der Scrum Master eine Person aus dem Team ist (z.B. ein Entwickler), ist in der Praxis der Scrum Master zumeist ein “klassischer” Projekt-Manager, der maßgebliche Verantwortungen an das Team und den Product Owner übergibt.
Trotz dieser “Verantwortungslosigkeit” ist der Scrum Master Dreh- und Angelpunkt des Scrum-Verfahrens. Er ist explizit dafür verantwortlich, das alles so gut wie nur möglich ablaufen kann.
Team
Das Team ist die einzige Rolle in Scrum, die mehrere Personen umfassen darf. Hier wird explizit auf Hierarchien und Verantwortlichkeiten verzichtet, jeder einzelne des Teams ist einfach “nur” ein Team-Mitglied. Das Team besteht meist aus Personen verschiedener Expertise oder Abteilungen, wie z.B. Entwickler, Architekten, Administratoren, Analysten und Testern.
Als Rolle ist das Team dasjenige mit der meisten Verantwortung und Wirkungskraft, denn es entscheidet eigenständig über Aufgabenverteilung und -organisation, regelt und steuert die Arbeitsweise und “kontrolliert” sich idealerweise selbst.
Scrum liefert zum Team eine Reihe von Empfehlungen, zu denen eine Teamgröße von ca. 7 (+/- 2) Mitgliedern zählt. In der Praxis ist dies bei größeren Projekten kaum machbar, dementsprechend baut man in diesem Fall N Teams mit N Scrum Mastern und N Product Ownern auf.
Metriken
Scrum als agiles Framework richtet sich nach den Maßgaben eines empirischen Managements. Es geht von vornherein davon aus, dass Schätzgrößen und Entwicklungsgeschwindigkeit im Laufe eines Software-Projektes immer tendenziell auf Basis von Erfahrungswerten ermittelt werden können. Dies wird in Scrum ermittelt, visualisiert und kontrolliert durch ein sog. “Burndown-Chart”.
Sprint Burndown Chart
Der Sprint Burndown Chart ist ein täglich aktualisiertes Diagramm, welches die Abarbeitung der einzelnen Aufgaben innerhalb eines Sprints messt und visualisiert. Er ist ein einfaches und zugleich zuverlässiges Mittel, die Entwicklungsgeschwindigkeit messbar zu machen und Problemstellungen während der Entwicklung oder der Anwendung von Scrum zu identifizieren. Der Sprint Burndown ist ein essentielles Werkzeug von Scrum.
Product Burndown Chart
Ergänzend zum Sprint Burndown erstellt man des öfteren ein Release/Product Burndown Chart, der aus der Sicht der Product Backlog Einträge und deren Abarbeitung ein Diagramm darstellt. Er ist besonders für die Sprint-Übersicht und die Voraussage von Sprintanzahl bzw. übergreifenden Terminen hilfreich.
Kickstart: Einsatz & Durchführung
Bevor ein Software-Projekt mit Scrum überhaupt durchgeführt werden kann, muss – wie bei jedem Projekt – ein Projektziel und eine “Vision” des Projektes greifbar sein.
Es gibt viele klassische und agile Methoden, die bei dieser ersten Phase des Projektes helfen, eine Projektziel zu erfassen. Generell aber gilt: Es sollte von Anfang an eine klare Fokussierung eines Ziels möglich sein. Dies umfasst nicht nur die “visionäre” Zielsetzung, sondern auch geschäftliche Faktoren (Nutzen, Markt, Einsatz) sowie einen grundlegenden Umfang der zu erstellenden Software.
Fundament: Team & Rollen
Sind diese grundlegenden Bausteine des Projektes geklärt, kann man zur Bildung des Scrum-Teams übergehen. Grundsätzlich sollten in dieser Phase schnellstmöglich alle Scrum-Rollen besetzt werden. Hierbei hilft oft das sog. “Best-Match”-Prinzip, deren Kernaussage es ist, eine bestmögliche Besetzung der Rollen anzustreben.
Product Backlog: Die Anforderungsliste
Sind Product Owner, Scrum Master sowie das Team formiert, kann quasi sofort “losgelegt” werden. Doch bevor es so “richtig losgeht”, muss der Product Owner initial das Product Backlog mit dem für Ihn wichtigsten Anforderungen befüllen. Die Einträge im Product Backlog sind nach geschäftlicher (kundenorientierter) Priorität aufgelistet, so dass immer gewährleistet ist, dass das Team an den “richtig wichtigen” Aufgaben arbeitet. Die wichtigsten Anforderungen im Product Backlog werden auch genauer und ausführlicher beschrieben und definiert. Das Team hilft dem Product Owner bei dieser Aufgabe und schätzt gleichzeitig grob die Aufwände jedes Product Backlog Eintrages.
Sprint-Planung: Das Versprechen des Teams
Nach erfolgreicher Befüllung des Product Backlogs kann “gesprintet” werden. Das Team wird also sofort produktiv. Doch bevor es an die Abarbeitung der Aufgaben geht, wird der bevorstehende Sprint im Sprint Planungs-Meeting geplant. Dabei wird die wichtige Entscheidung getroffen, wieviele Product Backlog Einträge das Team im Sprint abarbeiten kann. Die Entscheidung des Sprint-Volumens obliegt einzig und allein dem Team.
Sprint Backlog: Die Aufgabenliste
Um diese Entscheidung qualifiziert herbeiführen zu können, wird ein Product Backlog Eintrag (Anforderung) analysiert und in einzelne, kleine Aufgabenpakete granularisiert. Diese Aufgabenstellungen werden möglichst genau geschätzt und in das Sprint Backlog eingetragen. Hier wird auch die Grundregel angewendet, dass eine Sprint Backlog-Aufgabe nicht länger als 3 Tage andauern darf.
Als Ergebnis der Sprint-Planung liegt ein befülltes Sprint Backlog vor, welches zugleich das sog. “Commitment” (feste Absichtserklärung) an den Product Owner ist, dass alle diese Aufgaben zum Ende des Sprints erledigt sein werden.
Sprint: Daily Scrum & Work
Von nun an werden alle Sprint Backlog-Einträge vom Team abgearbeitet. Dabei organisiert sich das Team selbst – legt also eigenständig fest, wer an welcher Aufgabe arbeitet. Auch hier wird eine besondere Faustregel angewendet, nämlich dass jedes Teammitglied nur eine einzige Aufgabe im Sprint Backlog übernehmen darf.
Diese Selbstorganisation während des Sprintverlaufs wird durch das “Daily Scrum”, also die tägliche kurze Einsatzbesprechung des Teams gestützt und gefördert. Im Daily Scrum werden Aufgaben aktualisiert und verteilt sowie grundlegende Status-Informationen an alle Teammitglieder mitgeteilt.
Sprint-Review: Das Ergebnis
Neigt sich der Sprint dem Ende zu, werden zum Abschluß zwei Meetings durchgeführt. Das erste Meeting ist das sog. “Sprint-Review”, in dem die Ergebnisse des Sprints dem Product Owner präsentiert werden und zur Abnahme vorliegen. Im Review entscheidet der Product Owner, ob das zu Beginn des Sprints gegebene “Versprechen” des Teams eingehalten wurde und ob er mit den Arbeitsergebnissen zufrieden ist. Sollten (Teil-)Ergebnisse unzufriedenstellend sein, werden diese vom Product Owner abgelehnt und werden automatisch zur “Nachbesserung” in den nächsten Sprint mit eingeplant.
Sprint-Retrospektive: Immer besser & besser
Nach dem Review des Sprints folgt sofort die sog. “Sprint-Retrospektive”. In diesem Meeting setzt sich das Team und der Product Owner zusammen um festzustellen, welche grundlegenden Probleme es beim Sprint gab bzw. um herauszufinden, wie man in den Sprints besser arbeiten kann. Die Retrosüektive kümmert sich also um die Verbesserung des Teams, der Methoden und Prozesse. Als Ergebnis werden Verbesserungsvorschläge und Maßnahmen in das Product Backlog eingearbeitet.
Nochmal, nochmal
Nach erfolgreichem Abschluß des Sprints geht “das Spiel wieder von vorne los”, d.h. es wird sofort wieder der nächste Sprint geplant und umgesetzt.
Comments