Methoden und Wissen
Software mit Scrum entwickeln: So geht's
11. August 2023 / Annekathrin Gut
Woher kommt Scrum?
Scrum ist eine Form der agilen Zusammenarbeit, die auf Flexibilität und Selbstorganisation des Teams setzt. Entstanden ist sie in der Softwareentwicklung in den 1990er Jahren und wird heute in vielen Bereichen eingesetzt. Ziel ist es, schneller funktionsfähige Softwareprodukte an die Kund:innen ausliefern zu können. Kurze Entwicklungszyklen sollen dafür sorgen, dass der gewünschte Nutzen für die Anwender:innen tatsächlich gewährleistet ist.
Für die Anwendung gibt es einen offiziellen Scrum Guide, der genaue Regeln und Handlungen vorschlägt. Obwohl viele Personen Scrum als agile Entwicklungsmethode bezeichnen, handelt es sich eigentlich nicht um eine Methode, sondern um ein „Framework“. Scrum ist ein Vorgehensmodell, das im Produkt- und Projektmanagement angewendet wird. Die Entwicklung läuft in Iterationen ab, den Sprints. Diese sind immer gleich lang - zwei bis vier Wochen - und geben den Entwicklungsrhythmus vor.
Nice to know: Der Begriff Scrum kommt aus dem Rugby und bezeichnet dort eine kreisförmige Aufstellung von zwei Mannschaften, die gemeinschaftlich versuchen, dem Gegner keinen Raum zu überlassen.
Wann ist Scrum sinnvoll?
Scrum hilft, komplexe Aufgaben zu lösen. Es ist für Projekte geeignet, in denen viel Unklarheit herrscht. Häufig sind das Vorhaben, die nach neuen Lösungen suchen und deren Kombination aus unvorhersehbaren Risiken der Implementierung und noch unklaren Anforderungen bestehen. Auch dass das Ergebnis nicht vorhergesagt werden kann, spricht dafür, Scrum einzusetzen. Scrum ist weniger sinnvoll, wenn es um vorhersehbare Lösungen geht, also Lösungen, die standardisiert sind und bei denen das Ergebnis schon genau feststeht.
Projekte in der Softwareentwicklung fallen in die Kategorie "komplex". Sie müssen nicht nur zahlreiche individuelle Anforderungen berücksichtigen, sondern auch auf sich häufig ändernde Rahmenbedingungen eingehen. Scrum bietet einen Rahmen, um den Entwicklungsprozess ausreichend koordiniert und dennoch flexibel und lernfähig genug zu gestalten.
Wie funktioniert Scrum?
Scrum bietet einen klaren Rahmen für die Arbeit - ganz im Gegensatz zur unstrukturierten Aufgabenstellung und dem unvorhersehbaren Ergebnis. Das Vorgehensmodell umfasst
- feste Rollen in einem Team,
- Ereignisse innerhalb bestimmter Zeitspannen
- und Artefakte als Wert oder Arbeitsergebnis.
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. Auf diese Weise nähern sie sich dem gewünschten Ergebnis immer mehr an. Alle Lösungen sind inkrementell, das heißt sie bauen aufeinander auf. Das Projekt wächst organisch.
Rollen im Scrum Team
Die zentrale Rolle übernimmt das Scrum Team. Es besteht aus Product Owner (PO), Scrum Master und Entwicklungsteam.
Product Owner
Der oder die PO wird in unseren Projekten meist vom Unternehmen gestellt, das den Auftrag vergibt. Er oder sie trägt die Verantwortung für den Erfolg des Produktes. Die Product Owner sind also dafür verantwortlich, dass die fertiggestellte Software einen Beitrag zur Wertmaximierung leistet.
Aufgabe der Product Ownership ist es, zusammen mit den Stakeholdern ein Zukunftsbild für das Produkt zu entwickeln und für ein gemeinsames Verständnis zu sorgen. Hierzu beschäftigen sich die PO mit den Anforderungen an das Produkt und bringen diese in eine Reihenfolge (Priorisierung), so dass Risiken frühzeitig angegangen und der Nutzen des Produktes maximiert wird.
Scrum Master
Der oder die Scrum Master fördert die Zusammenarbeit des Scrum Teams (Wertstrom-Maximierung). Diese Rolle ist dafür verantwortlich, Scrum einzuführen sowie das Team und die Kund:innen darin zu unterstützen, die agile Grundhaltung zu verstehen. Die Scrum Master sorgen dafür, dass sich alle an die Scrum-Prinzipien und -Praktiken halten. Damit erhöhen sie das Lernen und die Entwicklungsgeschwindigkeit.
Entwicklungsteam
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, Qualitätsexpert:innen bzw. Tester:innen, Anforderungsmanager:innen sowie UX-Designer:innen oder Security-Expert: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 – Produktinkrement 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 Auftraggeber:innen, Nutzer:innen und Stakeholder:innen einzuholen. So können Fehlentwicklungen vermieden werden, die später nur schwer wieder zu korrigieren wären.
Ein Sprint beinhaltet das Sprint Planning zu Beginn, die Daily Scrums (die tägliche Abstimmung des Entwicklungsteams), die eigentliche Entwicklungsarbeit und am Ende das Sprint Review sowie die Sprint Retrospektive. Außerdem müssen Zeiten für das Refinement eingeplant werden. Die klar vorgegebenen Ereignisse strukturieren die Entwicklung und verdichten die notwendige Kommunikation.
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 - das Inkrement - entstehen.
Welche Rolle spielen die abschließenden Sprint Ereigniss?
Sprint Review
Im Sprint Review werden die während des Sprints umgesetzten Funktionalitäten live am System präsentiert. Die Präsentation übernehmen idealerweise die PO. Auftraggeber:innen, idealerweise auch die Stakeholder:innen, 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. Die PO priorisieren 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.
Retrospektive
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 oder der 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.