Das agile Vorgehensmodell Scrum
Scrum ist ein Vorgehensmodell der agilen Softwareentwicklung.
Wofür steht der Name "Scrum"?
Scrum (zu deutsch: Gedränge) beschreibt einen Spielzug im Rugby, der auf den ersten Blick wie ein unüberschaubares Gedränge wirkt, tatsächlich aber sorgsam einstudiert ist. Der Ansatz basiert auf wenigen klaren Regeln, die es erlauben, auf geänderte Anforderungen kontrolliert, aber flexibel zu reagieren.
Wozu brauchen wir Scrum?
Software-Projekte sind besonders vielen Änderungen unterworfen. Häufig sind derartige Projekte zu Beginn sehr vage formuliert und Fortschritte sind schwer auszumachen. Außerdem ist es keine Seltenheit, dass sich sowohl grundlegende Bausteine wie z.B. Programmiersprachen, Hardware und Industriestandards als auch die Kundenanforderungen im Laufe der Zeit ändern. Eine Studie der Standish Group hat ergeben, dass nur 16% aller IT-Projekte erfolgreich sind. Folglich enden 84% aller IT-Projekte mit überzogenen Zeitplänen, überzogenen Budgets oder mit nicht fertiggestellten Funktionen.
Prinzipiell hat ein Unternehmen, das IT-Projekte realisiert, zwei Möglichkeiten: Die erste Möglichkeit wäre, den Kunden darauf hinzuweisen, dass sein Projekt mit einer Wahrscheinlichkeit von 84% länger dauert als geplant, teurer wird als veranschlagt bzw. er unfertige Funktionen erhält. In jedem Fall wird sich die Begeisterung des Kunden in Grenzen halten. Die zweite und logischere Vorgehensweise bestünde in der aktiven Steigerung der Erfolgsquote von Projekten. Scrum setzt mit einem iterativen und inkrementellen Vorgehen auf den zweiten Lösungsansatz.
Warum Scrum für Sie als Kunde interessant ist
- Striktes Vorgehen nach Ihren Prioritäten
- Sie erhalten regelmäßig einen funktionsfähigen Zwischenstand
- Sie profitieren von wissenschaftlichen Erkenntnissen aus dem Qualitätsmanagement
- Sie gewinnen mehr Flexibilität
- Ihre Arbeitslast verteilt sich besser
- Scrum-Teams arbeiten nachhaltig
Ausführlichere Informationen zu den Vorteilen von Scrum für Sie als Kunde.
Kompromiss bei Funktionalität, nicht bei Qualität
Das klassische Dreieck des Projektmanagements wird in Scrum abgeändert: Aus einem Kompromiss aus Kosten, Zeit und Qualität wird ein Kompromiss aus Kosten, Zeit und Funktionalität. Es gibt also keine Kompromisse hinsichtlich der Qualität. Der Vorteil für die Auftraggeber: Sie erhalten dafür über den gesamten Projektzeitraum hinweg in regelmäßigen Abständen eine funktionstüchtige Software ausgeliefert und nicht erst am Ende des Projekts. Es wird eine Software entwickelt, die dauerhaft Freude bereitet und nicht mit "Quick and Dirty"-Lösungen versehen ist.
Agilität durch Selbstorganisation und Kommunikation
Die Anwendung von Scrum ist im Grunde einfach, da sie nur wenigen einfachen Regeln unterliegt:
- Zuweisung und Ausübung der drei Rollen „Product Owner“, „Scrum Master“ und „Team“
- Führen eines priorisierten Product Backlogs
- Erstellen von “auslieferbaren Produktinkrementen” in klar definierten, kurzen zeitlichen Intervallen (Sprints)
Eine zentrale Bedeutung bei der Durchführung von Projekten haben hierbei die Selbstorganisation und die Kommunikation innerhalb der Teams. Einen klassischen Projektmanager, der bestimmt, wer was zu tun hat, gibt es nicht. Vielmehr entscheidet das Team in verschiedenen Meetings selbst, was realistisch in einem bestimmten Zeitraum umsetzbar ist. Zur Förderung der Kommunikation und Weiterentwicklung des Teams werden verschiedene Meetings als Instrumente eingesetzt: Die Sprint-Planungssitzung, Daily Scrum, Sprint Review und Sprint Retrospektive. Dank der Einhaltung klar definierter Regeln werden diese Meetings nicht zum Zeitfresser, sondern gewährleisten eine klare Anforderungsbeschreibung, die frühzeitige Erkennung von Problemen und deren Lösung sowie eine kontinuierliche Verbesserung der Arbeitsabläufe und damit der Ergebnisse.
Die Scrum-Meetings
Sprint-Planungstreffen
Das Sprint-Planungstreffen dient, wie der Name bereits vermuten lässt, der Planung der Arbeiten für den anstehenden Sprint. Der Product Owner erklärt dem Team das Sprintziel und die von ihm getroffene Vorauswahl von Anforderungen. Er stellt dann zunächst die am höchsten priorisierte Anforderung vor. Diese wird soweit besprochen, dass eine gemeinsame Vorstellung von der Anforderung entsteht. Auch die Kriterien für die Abnahme der Anforderung am Ende des Sprints werden gemeinsam erörtert.
Das Team zergliedert anschließend die Anforderung in alle erforderlichen Aktivitäten, inklusive Design-, Test- und Dokumentationsaufgaben. Diese Aufgaben werden beschätzt und das Team prüft, ob es sich zutraut, diese Anforderung inklusive aller Aufgaben im aktuellen Sprint umzusetzen. Ist das für die Anforderung der Fall, wird sie in das Sprint-Backlog übernommen.
Nun ist die Anforderung mit der nächsthöchsten Priorität an der Reihe und durchläuft die gleichen Schritte. Das Team übernimmt nur so viele Anforderungen in das Sprint-Backlog, wie es sich umzusetzen zutraut.
Eine auch bei //SEIBERT/MEDIA angewendete Variante des Planungstreffens sieht eine Aufteilung in zwei Meetings vor: Im ersten Teil besprechen wir mit dem Product Owner, welche Anforderungen für den Sprint eingeplant werden. Erst nach dem Commitment des Teams auf die Anforderungen werden in einem zweiten Meeting die Details abgeklärt und die Unterteilung in die einzelnen Aufgaben vorgenommen.
Nach der Klärung der Aufgaben kann sich das Team schließlich die ersten Aufgaben vornehmen und mit der Realisierung starten.
Daily Scrum
Das Daily Scrum ist ein tägliches Treffen von maximal 15 Minuten Dauer. Es dient der Selbstorganisation des Teams und findet jedenTag zur gleichen Zeit am gleichen Ort statt. In diesem Meeting beantwortet jedes Teammitglied kurz drei Fragen:
- Was habe ich seit dem letzten Daily Scrum erledigt?
- Welche Herausforderungen sind aufgetreten?
- Was nehme ich mir für das nächste Daily Scrum vor?
Mit Unterstützung des Daily Scrum wird ein täglicher PDCA-Zyklus durchlebt. Das Meeting beginnt mit einem Check, ob das Team die Ziele, die es sich im letzten Meeting vorgenommen hat, auch erreichen konnte. Die Erkenntnisse aus dem Vortag können dann in die Planung des Tages gleich einbezogen werden.
Dieses Zusammentreffen hilft, den täglichen Informationsaustausch und die Aufgabenverteilung sicherzustellen. Alle Teammitglieder werden über den aktuellen Fortschritt informiert und das Team erhält frühzeitig die Möglichkeit, ggf. Gegenmaßnahmen einzuleiten („Inspect and adapt“), wenn der gewünschte Fortschritt nicht erreicht wird.
Sprint-Review
Am letzten Tag des Sprints findet ein Sprint-Review statt, in dessen Rahmen das Team seine Arbeitsergebnisse dem Product Owner zur Abnahme vorstellt. Mit dem Sprint-Review hat das Team zum Ende des Sprints einen festen Abgabetermin vor Augen, zu dem ein potenziell auslieferbares Produktinkrement vorliegen muss. Abnehmen kann der Product Owner nur Anforderungen, die bis zum Sprint-Review vollständig und fehlerfrei umgesetzt sind. Angefangene, aber nicht abgeschlossene Arbeiten werden als nicht erledigt gewertet. Beim Sprint-Review mit seinem Check-Charakter wird in besonderem Maße sichtbar, was bereits erarbeitet wurde und wo möglicherweise noch Anpassungsbedarf besteht.
Sprint-Retrospektive
Am Ende des Sprint-Zyklus’ steht eine Retrospektive. Diese unterscheidet sich sehr stark von den anderen Scrum-Meetings. Der produktive Teil des Sprint-Zyklus ist mit dem Sprint-Review abgeschlossen. In der Sprint-Retrospektive wird die Zusammenarbeit der Beteiligten nun offen und ehrlich reflektiert. Das Team spricht Probleme konkret an, lastet sie aber einzelnen Mitarbeitern nicht an. Die Ursachen für Komplikationen werden gemeinsam durchdacht, damit nicht Symptome, sondern die Wurzeln der Probleme angegangen werden können.
Vergleichbar ist die Sprint-Retrospektive mit einer Einsatz-Nachbesprechung bei der Feuerwehr oder einem Debriefing beim Militär. Wie das Review-Meeting hat auch die Retrospektive vor allem einen Check-Charakter, hier ist der Fokus jedoch nicht auf das Produkt, sondern auf den Prozess und die Zusammenarbeit gerichtet. Die Erkenntnisse aus dem Sprint-Review und der Retrospektive gilt es dann zu nutzen, um Verbesserungsmaßnahmen einzuleiten.
Die Rollen in Scrum
Product Owner
Der Scrum Product Owner ist dafür verantwortlich, den ROI des Projekts zu maximieren.
ScrumMaster
Der ScrumMaster unterstützt das Team bei der Verbesserung ihres Prozesses.
Entwicklungsteam
Das Scrum-Team
Wenn vom Scrum-Team die Rede ist, wird in der Regel das Team im engeren Sinne gemeinsam mit ScrumMaster und Product Owner gemeint.
Die Artefakte in Scrum
Wie läuft ein Scrum-Projekt mit //SEIBERT/MEDIA ab?
Beiträge aus dem Blog von //SEIBERT/MEDIA über Scrum
- Welche Vorteile bietet mir als Kunde ein Scrum-Projekt?
- Live-Session zu Agilität mit Scrum und Kanban
- Greenhopper und Jira: Agile Projekte digital abbilden
- Arbeiten im Scrum-Team: Der visuelle Teamraum
- Scrum in der Praxis: Papier und Jira
- Scrum: Agile Software-Entwicklung bei //SEIBERT/MEDIA