Bevor wir in die Arbeit mit Scrum einsteigen, starten wir ganz klassisch in diesem Blogbeitrag erst einmal mit einer kleinen Definition: Das Wort Scrum ist nämlich kein Akronym. Der Begriff stammt aus der Sportart Rugby. Dort beschreibt scrummage das dichte Gedränge, mit dem ein Spiel neu gestartet wird. Die Spieler stehen in dieser Match-Phase alle "auf einem Haufen" zusammen. Die Analogie zu hocherfolgreichen Produktentwicklungsteams liegt darin, dass auch hier Teams "auf einem Haufen" als kleine, autonom organisierte Einheiten arbeiten. Von außen wird nur die Richtung festgelegt, Taktik und das Vorgehen aber werden selbst aus der Einheit heraus bestimmt und somit auch die Art und Weise, wie gemeinsam das Ziel erreicht wird.
Die Arbeiten und die Erledigung von Aufgaben nach der Scrum-Methodik laufen nicht nacheinander ab, sondern finden parallel zueinander statt. Teilaufgaben werden somit gleichzeitig gelöst. Bereits in der Mitte der 90er Jahre legten die Japaner Ikujirõ Nonaka und Hirotaka Takeuchi das theoretische Grundlagengerüst für Scrum. Hierauf aufbauend schufen unter anderen Ken Schwaber und Jeff Sutherland sechs Jahre später das sogenannte „agile Manifest“, welches folgende Leitsätze umfasst:
Wir erschließen bessere Wege, um Software zu entwickeln,
indem wir es selbst tun und anderen dabei helfen.
Durch jene Tätigkeit haben wir diese Werte zu schätzen gelernt:
Menschen und Interaktionen über Prozesse und Werkzeuge
Funktionierende Software über umfassende Dokumentation
Zusammenarbeit mit dem Kunden über vertragliche Leistungsbeschreibung
Eingehen auf Veränderungen über Festhalten an einem Plan
Obwohl wir die Werte auf der rechten Seite wichtig finden, schätzen wir die Werte auf der linken Seite höher ein.
Das "agile Manifest" zeigt auf, dass es neben den Projektzielen auch noch andere Prioritäten in der Arbeit nach Scrum gibt, die genauso wichtig, wenn nicht sogar wichtiger sind als die reine Gewinnmaximierung.
Wie genau funktioniert Scrum?
Scrum ist eine schlanke, innovative und agile Projektmanagement-Methode mit folgenden Vorteilen für die Anwender*innen:
- einfache Regeln
- nur wenige Rollen
- mehrere Arten von Meetings mit bestimmten Zwecken
- einige Schlüssel-Artefakte, deren Pflege die Notwendigkeit eines Overheads vermeidet und welche eine maximale Transparenz und Einfachheit bieten
- Pragmatismus statt Dogmatik
- iteratives Vorgehen
- Selbstorganisation und Eigenverantwortung in interdisziplinären Teams
- Konzentration auf qualitativ hochwertige Arbeit anstatt auf eine Papierflut bei der Spezifikation
- Änderungen in den Kundenanforderungen während des Projekts gelten als normal, nicht als Störfaktor (es gibt keine „fertige“ Spezifikation)
- speziell geeignet für hochkomplexe Projekte mit unklaren Anforderungen
In der Scrum-Theorie existieren drei Rollen für die direkt am Prozess beteiligten Teammitglieder:
- Product Owner (stellt die fachlichen Anforderungen und priorisiert diese)
- Scrum Master (steuert den Prozess und beseitigt Hindernisse)
- Team (entwickelt das Produkt).
Neben diesen gibt es als Beobachtende und Ratgebende noch die Stakeholder*innen.
Wie genau wird Scrum umgesetzt?
Das jeweils zuvor festgelegte Arbeitspaket wird in kleinere Arbeitspakete, sogenannte Tasks, aufgeteilt. Danach werden diese Tasks im Sprint Backlog, der Aufgabenliste, dokumentiert und dort festgehalten.
Die Umsetzung aller Tasks aus dem Sprint Backlog bilden ein sogenanntes Increment of Potentially Shippable Functionality (PSI). Das Increment of Potentially Shippable Functionality beinhaltet immer eine Erhöhung der Produktfunktionalität, welche in einer vollständigen und produktiv einsetzbaren Anwendung mündet.
Das Team gleicht sich in einem täglichen Informations-Meeting, dem sogenannten Daily Scrum Meeting, ab. Seine Dauer ist streng auf 15 Minuten begrenzt. Somit ist der transparente, effiziente und effektive Informationsfluss gesichert.
Am Ende des Sprints präsentiert das Team dem Product Owner, den Stakeholder*innen und anderen interessierten Teilnehmer*innen in einem sogenannten Sprint Review Meeting live am System die implementierte Funktionalität. Das Feedback hieraus fließt in das nächste Sprint Planning Meeting ein, und der Prozess beginnt von Neuem.
Was genau ist die Aufgabe des Scrum Masters?
Der Scrum Master sorgt während des gesamten Prozesses dafür, dass die Regeln eingehalten werden und dass der Status aller Tasks im Sprint Backlog von den jeweils zuständigen Team-Mitgliedern aktualisiert wird. Diese Doings müssen täglich erledigt und gemonitort werden.
Des Weiteren beseitigt der Scrum Master Hindernisse (Impediments), die während der Entwicklung auftreten, oder eskaliert sie gegebenenfalls ans höhere Management.
Anhand eines geeigneten Berichtswesen reportet der Scrum Master außerdem den Projektfortschritt transparent: Mithilfe sogenannter Burndown Charts, die den Fortschritt den aktuellen Sprint, bzw. das gesamte Projekt betreffend, jeweils in Form einer Kurve visualisieren, gelingt dies in effizienter und verständlicher Form. Eingezeichnete Trendlinien erlauben es, mögliche Probleme und Verzögerungen auf einen Blick zu erkennen.
Im Kern basiert Scrum also auf einem schrittweisen Vorgehen, auf der Organisation von Entwicklungsabschnitten und auf Meetings in vordefinierten Zeitabschnitten, den sogenannten Time-Boxes, sowie der Erkenntnis, dass ein funktionierendes Produkt relevanter ist als eine dreihundertseitige Spezifikation.
Selbstverständlich ist darüber hinaus auch die Sprintplanung eine elementare Installation innerhalb von Scrum. Dazu gibt es hier einen weiteren hochinteressanten Blogbeitrag von uns. Wenn es konkrete Fragen zu den Themen Scrum, Sprintplanung und agilen Methoden gibt oder das Interesse an Complementary Pracitces und Verbesserungen innerhalb von Sprints geweckt wurde, schau doch einfach bei unserem Agile Community After Work Event vorbei. Dort kannst du gerne deine offenen Fragen an die agile Community stellen. Nächster Termin: 13.10. um 17:30 in München.