Scrum – Kurzübersicht mit BiKaBlo Grafik

Scrum erlangt seit Mitte der 1990er Jahre immer größere Bekanntheit als Prozessrahmenwerk zum Management der Arbeit an komplexen Produkten. Es beruht auf Erkenntnissen von Ken Schwaber und Jeff Sutherland über Wettbewerbsvorteile, die durch die Verbindung von inkrementellem, iterativem und empirischem Vorgehen im Vergleich zum Wasserfallvorgehen in Softwareentwicklungs-Projekten entstehen. Ersteres erzeugt eine Risikominimierung durch eine hohe Transparenz des Entwicklungsfortschrittes und Letzteres sorgt für eine kontinuierliche Überprüfung der Ergebnisse und die gezielte Anpassung der Produktentwicklung. Scrum besticht durch sein minimalistisches Regelwerk und seine leichtgewichtige Struktur, die den Einstieg sehr einfach macht. Die drei internen Verantwortlichkeiten im Scrum Team sind Entwickler, Product Owner und Scrum Master. Gemeinsam sollen sie autark und autonom ein Produkt entwickeln und in fortlaufenden Zyklen, genannt Sprints, ausliefern. Das Team soll cross-funktional und interdisziplinär aufgestellt sein und eine Größe von um die 7 Mitglieder haben, um effektiv und effizient zu arbeiten. Für das zu entwickelnde Produkt definieren sie zu Beginn ein Langzeitziel, das sogenannte Produkt Ziel. Zur Erreichung dieses Ziels schreiben sie dann Anforderungen, zumeist in Form von User Stories, die den initialen Product Backlog bilden. Für die Steuerung der Scrum Produktentwicklung stehen die sogenannten Artefakte zur Verfügung:

  1. Product Backlog (Liste der Anforderungen, um das Produkt Ziel zu erreichen, vom PO verantwortet)
  2. Sprint Backlog (Liste der Anforderungen, um das Sprint Ziel zu erreichen, von den Entwicklern verantwortet)
  3. Product Increment (wird ausgeliefert von Entwicklern nach PO-Freigabe)

Eine Definition of Done gibt an, was erfüllt sein muss, damit ein Inkrement als fertig gelten kann. Sie besteht aus einer Liste mit Fertigstellungskriterien und Definitionen des fertigen Zustands, z.B. kann darinstehen, dass eine bestimmte Testabdeckung nicht unterschritten werden darf und bestimmte Arten von Tests vorgeschrieben sind, wie die für innere Logik und Integration. Sinnvollerweise sollten auch die erforderlichen Schritte zur Auslieferung, die sogenannten Build und Deployment Tätigkeiten, darin festgelegt werden. Der Scrum Prozess läuft dann entlang von sogenannten Events ab:

  1. Sprint (ein Container für die anderen Events)
  2. Sprint Planning
    1. Teil 1: Was kann abgeschlossen werden? Warum ist es wertvoll?
    1. Teil 2: Wie wird es abgeschlossen?
  3. Daily Scrum
  4. Sprint Review
  5. Retrospektive

Die Scrum Events sind zeitlich durch eine feste Timebox (maximale Länge) reglementiert und haben einen festen, wiederkehrenden Abstand. In einem Projekt mit zweiwöchigen Sprints dauern Review und Retrospektive üblicherweise 1-2 Stunden und die Planung 2-4 Stunden. Unabhängig von der Sprint-Länge ist die Timebox des Daily immer 15 Minuten. Jeder Sprint beginnt mit dem Sprint Planning, einem Arbeitstreffen, an dem das gesamte Scrum Team teilnimmt. Darin stellt der Product Owner die am höchsten priorisierten Anforderungen vor, erklärt sie und die Entwickler schätzen erfahrungsbasiert deren Aufwand, oder Komplexität. Die Entwickler entscheiden dann was im Sprint abgeschlossen werden kann und das Scrum Team definiert dafür ein übergeordnetes Sprint Ziel. Nur solche Anforderungen, die vom Team klein genug zerteilt und genau genug beschrieben wurden, können dabei berücksichtigt werden. Dafür findet einmal pro Woche das Product Backlog Refinement Meeting statt. Im zweiten Teil des Sprint Plannings analysieren die Entwickler welche Arbeitsschritte und Bedingungen konkret notwendig sind, um das Sprint Ziel zu erreichen. Sobald der Sprint beginnt, trifft sich das Team einmal täglich immer zur gleichen Zeit, um die Zusammenarbeit zu koordinieren und den Fortschritt auf das Sprint Ziel zu überprüfen. Es wird empfohlen, dieses sogenannte Daily Scrum im Stehen abzuhalten, um Aufmerksamkeit zu fördern. Als Gesprächsgrundlage dient dem Team dabei das Kanban-Board, womit es die Arbeit des Sprint-Backlogs visualisiert und nach dessen Methodik es für eine gute Geschwindigkeit der Fertigstellung sorgt. Am Ende jedes Sprints findet ein Sprint Review Meeting statt, in welchem das Scrum Team die Sprint Ergebnisse den Stakeholdern vorführt. Dabei überprüfen sie den Fortschritt auf das Produkt Ziel und diskutieren über sinnvolle Anpassungen des Product Backlogs auf Grundlage der neuesten Informationen über relevante Veränderungen ihres Umfelds.  In der Retrospektive erfolgt schließlich eine Betrachtung auf die Zusammenarbeit und Abläufe im letzten Sprint und es werden 1-3 Verbesserungen herausgearbeitet, die das Team ab dem nächsten Sprint umsetzen wird. Ein neuer Sprint wird wieder nahtlos mit dem nächsten Sprint Planning Meeting eingeläutet. 

Scrum sieht zusätzlich zu den Entwicklern und dem PO noch den Scrum Master vor. Er soll dem gesamten Scrum Team bei der korrekten Anwendung von Scrum behilflich sein und sie zu einer selbstorganisierten Arbeitsweise hinführen. Der Scrum Master soll auch dabei helfen, agile Prinzipien und Kultur in der übergeordneten Gesamtorganisation zu fördern. Aufgaben des klassischen Projektmanagers werden in Scrum-Projekten verteilt auf den Product Owner, den Scrum Master und die Entwickler. 2010 wurde der Scrum Guide unter scrumguides.org von Schwaber und Sutherland als gültiger Leitfaden für Scrum veröffentlicht und seitdem regelmäßig aktualisiert. Scrum ist mittlerweile das weltweit meistgenutzte agile Verfahren. Unter agilemanifesto.org werden die Agilität definiert und ihre 12 Prinzipien beschrieben, die sich auch in Scrum wiederfinden.