Agilität ist einer der wichtigsten Schlüsselfaktoren für Unternehmen, um sich schnell, flexibel und mit hoher Geschwindigkeit auf sich ändernde Marktbedingungen anpassen zu können. Während die Chefetage vieler Unternehmen zwar behauptet, die eigene Organisation sei bereits sehr agil, sieht die Praxis oft anders aus. In aller Munde ist hierbei die Scrum-Methodik als Rahmen zur Durchführung von Veränderungs- und Transformationsprojekten. Der folgende Artikel bringt die wesentlichen Elemente von Scrum auf den Punkt.
Foto: wavebreakmedia - shutterstock.com
Scrum - eine Definition
Scrum (englisch: Scrum für "Gedränge") ist ein Vorgehensmodell des Projekt- und Produktmanagements, insbesondere zur agilen Softwareentwicklung. Das Grundprinzip besteht darin, dass ein (interdisziplinäres) Team in Eigenverantwortung in kurzen Iterationszyklen schrittweise nutzbare Produkte entwickelt. Hierbei erfolgen möglichst schnell und häufig Produkt-Updates, so dass die jeweilige Evolutionsstufe direkt am Markt getestet und direktes Feedback durch den Kunden eingeholt werden kann.
Lesetipp: Die neue Arbeitswelt der Software-Entwickler
Neben einer kurzen time-to-market der ersten Produktversionen - häufig auch als "MVP" (Minimum Viable Product) bezeichnet - bietet sich somit insbesondere auch die Möglichkeit, nach jeder Entwicklungsschleife gezielt nachzuschärfen. Somit lässt sich das Ergebnisrisiko im Gegensatz zu klassischen Wasserfallprojekten deutlich besser kontrollieren und minimieren. Der Nachteil ist, dass apriori keine Gesamtaufwandsschätzung bis zum finalen Endprodukt vorliegt.
Ein Scrum-Projekt besteht typischerweise aus einer Reihe von Iterationen zur Entwicklung des Produkts, sogenannte Sprints. Jeder dieser Sprint-Zyklen dauert typischerweise zwischen ein und vier Wochen und beinhaltet die Durchführung Scrum-spezifischer Zeremonien und die Erstellung von Artefakten bis hin zu einem nutzbaren Produkt (das Produktinkrement) durch das Scrum-Team.
Scrum - Team & Rollen
Im Zentrum der Methodik steht das Scrum-Team. Die Größe ist hierbei so gewählt, dass hierarchiefreies, selbstständiges und dennoch effizientes und zielgerichtetes Arbeiten mit maximalem Produkt-Output möglich wird.
Hierbei existieren grundsätzlich drei Hauptrollen:
Scrum Master
Product Owner
Team-Mitglied (Entwickler)
Scrum kommt in der Theorie ohne einen Projektleiter aus - ganz im Sinne des Arbeitens auf Augenhöhe ohne Hierarchien. In der Praxis finden sich jedoch alle denkbaren Rollenkonstrukte, insbesondere dann wenn die Entwicklungstätigkeiten über ein einzelnes Entwicklungsteam hinausgehen und erhöhte Koordinationsaufwände erforderlich sind.
Der Scrum Master stellt sicher, dass der Product Owner, das Entwicklungsteam und die Organisation verstehen, wie Scrum im jeweils projektspezifischen Kontext verwendet werden kann und was es zu beachten gilt. Als organisationsweiter "Methoden-Owner" und daher oftmals auch als "Agile Coach" bezeichnet, unterstützt der Scrum Master typischerweise nicht nur ein einzelnes Projekt sondern berät oftmals mehrere Teams bei deren Arbeitsgestaltung. Wichtig ist hierbei, dass die Betonung auf "Beraten" liegt - der Scrum Master ist kein Leiter oder Projektmanager auch wenn der Titel zu dieser Annahme verleitet.
Der Product Owner nimmt typischerweise die Rolle des fachlichen Auftraggebers des Projektes ein und fungiert als Bindeglied zwischen dem Scrum Team und den beteiligten Stakeholdern, insbesondere aus dem Management und den Fachabteilungen. In diesem Sinne besteht die wichtigste Aufgabe des Product Owners darin, den Wert des zu entwickelnden Produkts mit jedem Sprint zu maximieren um die zu Grunde liegende Vision im Sinne der Vorstellungen der Stakeholder umzusetzen. Als Verantwortlicher für das sogenannte Product Backlog nimmt der Product Owner exklusiv die Anforderungen der Stakeholder auf, kommuniziert und priorisiert diese zur Bearbeitung und Umsetzung in den einzelnen Sprints und bewertet schlussendlich die Umsetzungsgüte bei Sprintende.
Die Entwickler sind mit der eigentlichen Umsetzung der Produktanforderungen aus dem Product- beziehungsweise aus dem jeweiligen Sprint Backlog betraut. Je nach Sprintziel findet sich typischerweise eine bunte Mischung unterschiedlicher Hintergründe und Skills, um sämtliche erforderlichen Tätigkeiten und Facetten abbilden zu können. So gibt es nicht die eine "Konfiguration" an UX-/UI-Designern, Backend- und Frontend-Programmierern, Business Analysten oder Testspezialisten - vielmehr variiert die Zusammensetzung mit dem Zielbild, so dass ein möglichst autarkes Arbeiten des Teams in den Sprints erfolgen kann. Hierbei ist Sprint-übergreifende Stabilität im Team ein wichtiger Kerngedanke im Sinne des effizienten Zusammenarbeitens, ebenso wie die exklusive Zugehörigkeit der Entwickler zu einem einzigen Entwicklerteam.
In der Praxis stellen jedoch beide Aspekte häufig eine Herausforderung vor dem oftmals vorhandenen Auslastungsdruck dar. Zudem werden spezifische Skills insbesondere bei länger laufenden Projekten oft auch nur punktuell zu Beginn oder am Ende benötigt.
Scrum-Zeremonien und Meetings
Der grundsätzliche Ablauf eines Sprints nach Scrum folgt vier wichtigen Zeremonien beziehungsweise Meetings, in dem Ziele und Ergebnisse gemeinsam definiert beziehungsweise begutachtet werden:
Sprint Planning
Daily
Sprint Review
Sprint Retrospective
Zu Beginn eines Scrum-Projekts - auch wenn nicht ausdrücklich als Scrum-Zeremonie definiert - empfiehlt es sich zusätzlich einen Kickoff-Termin durchzuführen um die "soziale Basis" zu legen und Vision und Ziele der Stakeholder beziehungsweise das Endprodukt gemeinsam zu verstehen.
Der "Startschuss" eines jeden Sprints fällt mit dem sogenannten Sprint Planning Meeting. Je nach Sprintdauer findet hierzu alle 2-4 Wochen das gesamt Scrum-Team zueinander. Auf Basis des Product Backlogs werden die als nächstes umzusetzenden Anforderungen ausgewählt und priorisiert und im sogenannten Sprint Backlog notiert. Wenngleich der Product Owner grundsätzlich dafür verantwortlich ist, was in welcher Reihenfolge aus dem Product Backlog umgesetzt werden soll, erfolgt die Erstellung des Sprint Backlogs in gut funktionierenden Teams gemeinsam und berücksichtigt technische Restriktionen und Synergieeffekte aber auch Verfügbarkeiten und Zusammensetzung des Entwicklungsteams.
Jeden Tag zur gleichen Zeit trifft sich das Entwickler-Team im sogenannten Daily (Scrum) oder auch Daily Standup, um aktuelle Informationen auszutauschen und den Fortschritt in Richtung des Sprint-Ziels zu diskutieren. Hierbei erläutert jeder Teilnehmer kurz was seit dem vorangegangenen Tag fertiggestellt wurde, was als nächstes ansteht und welche Herausforderungen es gegebenenfalls gibt.
Sinn und Zweck des Sprint Reviews ist der gemeinsame Blick auf das "Geschaffte" am Sprintende. Nach Abschluss der Entwicklungstätigkeiten stellt das Scrum-Team daher dem Product Owner und gegebenenfalls auch den relevanten Stakeholdern die konkreten Arbeitsergebnisse vor und es wird diskutiert was gegebenenfalls noch einmal anzupassen ist sowie welche grundlegengenden nächsten Schritte im Folgesprint im Fokus stehen sollen. Sofern es der Fortschritt des Produkts zulässt ist hierbei sehr zu empfehlen es nicht bei einer live Demonstration des Produkts zu belassen, sondern erste Nutzererfahrungen durch eigenes "Ausprobieren" sammeln zu lassen.
Die sogenannte Sprint Retrospective findet wiederum im kleineren Kreis des Scrum-Teams statt. Ziel ist es positive aber auch negative Erfahrungen aus der gemeinsamen Team-Arbeit zu reflektieren und gegebenenfalls entsprechende Optimierungsmaßnahmen zu beschließen. Für die bei Scrum so essentielle, sehr enge Arbeit im Team ist es aber unabkömmlich durch offenes Ansprechen und Lösen von Konflikten das Team weiter zu formen.
Scrum-Artefakte
Während eines Scrum-Projekts beziehungsweise den Sprints, arbeitet das Team an drei sogenannten grundsätzlichen Artefakten, welche die geleistete Arbeit und den hierdurch geschaffenen Mehrwert repräsentieren und messbar machen:
Product Backlog
Hierbei handelt es sich im Kern um eine aktuelle Liste aller Anforderungen, die im Rahmen des Projekts in Form des Endprodukts umgesetzt werden sollen.Sprint Backlog
Das Sprint Backlog wird zu Beginn eines jeden Sprints (Sprint Planning) auf Basis der im Product Backlog noch enthaltenen Anforderungen befüllt.Produktinkrement
Das ist das Ergebnis eines jeden Springs in Form einer neuen oder aktualisierten, aber auf jeden Fall nutzbaren Version des Produkts.
Scrum vs. Kanban
Scrum wird oft im selben Atemzug wie Kanban genannt, denn beide sind sowohl lean als auch agil im eigentlichen Sinne. Kein Wunder also, dass es auch Kombinationen gibt (Scrumban), welche die Philosophien beider Ansätze kombinieren.
Beide arbeiten mit dem Ziel, dass Teams sich selbst organisieren und bei Ihren Aufgaben möglichst hohen Durchsatz generieren. Dieses gemeinsame Ziel eint und hierfür wird im Detail dann auch das jeweilige Instrumentarium angeboten.
Trotzdem gibt es Unterschiede: Auch wenn die Scrum-Elemente alle auf einen "Bierdeckel" passen, ist dies schon mehr Prozessvorgabe als bei Kanban. Kanban kennt keine Rollen, Zeremonien oder Artefakte (neben dem Kanban-Board) und kommt insgesamt mit deutlich weniger vordefinierten Vorgaben und Regeln daher. Daher empfiehlt sich zum Einstieg in die agile Projektwelt eher der Einsatz von Scrum mit klaren Leitplanken, während erfahrenere und eingespielte Teams die Freiheitsgrade von Kanban nutzen um ihre eigenen, spezifischen Regeln und Abläufe auszugestalten. Am Ende wird jedoch bei richtiger Anwendung mit beiden Methoden eine hohe Stringenz und Disziplin sichergestellt. (bw)