Methoden und Wissen
Software mit Scrum entwickeln
26. Oktober 2021 / Annekathrin Gut
Scrum hilft, komplexe Aufgaben zu lösen. Projekte in der Softwareentwicklung gehören eindeutig dazu, denn sie müssen nicht nur zahlreiche individuelle Anforderungen berücksichtigen, sondern sich auch häufig ändernden Rahmenbedingungen anpassen. Scrum bietet einen Rahmen, um den Entwicklungsprozess ausreichend koordiniert und dennoch flexibel und lernfähig genug zu gestalten.
In der HEC setzen wir Softwareentwicklungsprojekte deshalb meistens nach Scrum um. Großer Vorteil ist das iterative und inkrementelle Vorgehen: Es werden Schritt für Schritt kleine Lösungen erzeugt, die ausprobiert und kontinuierlich verbessert werden und sich auf diese Weise iterativ dem gewünschten Ergebnis nähern. Alle Lösungen sind inkrementell, bauen also aufeinander auf. Bei diesem Vorgehen steht der Endzustand in der Regel nicht von vorneherein fest. Das Projekt wächst organisch.
Wie funktioniert Scrum?
Scrum umfasst feste Rollen in einem Team, Ereignisse innerhalb bestimmter Zeitspannen und Artefakte.
Rollen im Scrum Team
Die zentrale Rolle übernimmt das Scrum Team. Es besteht aus Product Owner, Scrum Master und Entwicklungsteam.
Der Product Owner (PO) wird in unseren Projekten meist vom Unternehmen gestellt, das den Auftrag vergibt. Er – oder sie – trägt die Verantwortung für den Produkterfolg, ist also dafür verantwortlich, dass die fertiggestellte Software einen Beitrag zur Wertmaximierung leistet. Seine Aufgaben bestehen darin, zusammen mit den Stakeholdern ein Zukunftsbild für das Produkt zu entwickeln und für ein gemeinsames Verständnis zu sorgen. Hierzu beschäftigt er sich mit den Anforderungen an das Produkt und bringt diese in eine Reihenfolge (Priorisierung), so dass Risiken frühzeitig angegangen und der Nutzen des Produktes maximiert wird.
Der Scrum Master fördert die Zusammenarbeit des Scrum Teams (Wertstrommaximierung). Er soll unter anderem das Lernen und die Entwicklungsgeschwindigkeit erhöhen.
Das Entwicklungsteam ist cross-funktional. Es enthält alle Kompetenzen, die es zur Umsetzung der Aufgabe benötigt. In der HEC gehören dazu üblicherweise Softwareentwickler:innen, Tester:innen und Anforderungsmanager:innen sowie UX-Designer:innen.
Ereignisse
Das Herz von Scrum ist der Sprint: Innerhalb eines Zeitfensters (time-box) von maximal einem Monat wird ein fertiges, nutzbares und potenziell auslieferbares – oder noch besser: ein ausgeliefertes – Produkt-Inkrement hergestellt.
In fast allen unseren Projekten hat sich herausgestellt, dass zwei Wochen die optimale Dauer für einen Sprint sind. Der Zeitraum von 14 Tagen ist lang genug, damit ein Entwicklungsteam neue Funktionalitäten mit tatsächlichem Mehrwert herstellen kann. Gleichzeitig ist die Spanne kurz genug, um Feedback von Auftraggebern, Nutzern und Stakeholdern einzuholen, um Fehlentwicklungen zu vermeiden, die später nur schwer wieder zu korrigieren wären.
Ein Sprint beinhaltet das Sprint Planning, die Daily Scrums (die tägliche Abstimmung des Entwicklungsteams), die eigentliche Entwicklungsarbeit, das Sprint Review und die Sprint Retrospektive. Außerdem müssen Zeiten für das Refinement eingeplant werden. Die klar vorgegebenen Ereignisse strukturieren die Entwicklung und ver-dichten die notwendige Kommunikation.
Sprint Review
Im Sprint Review werden die während des Sprints umgesetzten Funktionalitäten live am System präsentiert.
Sprint Planning
Beim Sprint Planning legen Product Owner und Entwicklungsteam das Sprintziel und die hierfür umzusetzenden Anforderungen gemeinsam fest.
Daily Scrum
Das tägliche Update des Entwicklungsteams. Es sollte nur eine Viertelstunde dauern!
Sprint Retrospektive
Jeder Sprint wird mit einer Retrospektive abgeschlossen. Zeit für Reflexion und Verbesserung.
Scrum-Ereignisse Schritt für Schritt
Artefakte
Scrum sieht drei Artefakte vor: das Product Backlog, das Sprint Backlog und das Inkrement.
Der PO bereitet das Product Backlog vor (Refinement). Oft ist das Entwicklungsteam daran beteiligt. Die erfahrenen Scrum Master der HEC oder weitere Expert:innen können bei dieser Aufgabe unterstützen.
Beim Sprint Planning legen PO und Entwicklungsteam mit Blick auf das Product Backlog das Sprintziel und die hierfür umzusetzenden Anforderungen gemeinsam fest. Den Umfang bestimmt dabei allein das Entwicklungsteam: Nur sie können realistisch einschätzen, wieviel in dem gesetzten Zeitraum zu schaffen ist.
Die Anforderungen wandern in das Sprint Backlog. Schritt für Schritt und nach festgelegter Priorität werden sie abgearbeitet. Der Fortschritt ist jederzeit einsehbar. Bis zum Ende des Sprints soll eine den Anforderungen entsprechende Leistung (Inkrement) entstehen.
Was passiert bei den weiteren Scrum-Ereignissen?
Im Sprint Review werden die während des Sprints umgesetzten Funktionalitäten live am System präsentiert. Die Präsentation übernimmt idealerweise der PO. Auftraggeber, beziehungsweise dessen Stakeholder, geben unmittelbares Feedback auf die Funktionalität des Inkrements.
Alles was noch nicht oder unvollständig umgesetzt wurde, verbleibt im Product Backlog. Änderungen, Ergänzungen oder Fehler, die im Rahmen des Sprint Reviews erkannt werden, werden in das Product Backlog aufgenommen. Der PO priorisiert die Anforderungen neu. Das Entwicklungsteam zieht sich daraus die neuen Aufgaben für den nachfolgenden Sprint.
Das Produktinkrement, das im Sprint erstellt wurde, wird spätestens direkt nach Abschluss des Sprints an den Auftraggeber übergeben. Nun kann es produktiv gesetzt werden, wenn das zu diesem Zeitpunkt sinnvoll ist.
Jeder Sprint wird mit einer Retrospektive abgeschlossen. Sie bietet dem Scrum Team die Gelegenheit, sich selbst zu überprüfen und sich kontinuierlich zu verbessern – und das im Zusammenspiel mit dem PO des Kunden. Zum Vergleich: Im Sprint Review soll das Produkt selbst überprüft werden. In der Retrospektive werden der Prozess und die Zusammenarbeit im Scrum Team untersucht. Gemeinsam werden Maßnahmen zur Verbesserung erarbeitet, die im nächsten Sprint umgesetzt werden.
Noch Fragen? Dann sprechen Sie mich an:
Kennen Sie den HEC Newsletter?
