Scrum – Kurzübersicht mit Infografik

Scrum erlangte seit Mitte der 1990er Jahren größere Bekanntheit als Prozessrahmenwerk zum Management der Arbeit an komplexen Produkten. Es beruht auf Erkenntnisse von Ken Schwaber und Jeff Sutherland über Wettbewerbsvorteile, die durch die Verbindung von inkrementellem, iterativem und empirischem Vorgehen im Vergleich zum Wasserfallvorgehen in Software­entwicklungs-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 Anpassung der Produktentwicklung. Damit erhöht sich die Wahrscheinlichkeit deutlich, Projekte innerhalb von Budget und Zeit abzuschließen und gleichzeitig ein marktgerechtes Produkt abzuliefern.

Scrum besticht durch sein minimalistisches Regelwerk und seine leichtgewichtige Struktur, die den Einstieg sehr einfach macht. Die drei wichtigsten internen Rollen des Projektteams sind der Scrum Master, der Product Owner und das Entwicklungs-/Umsetzungs-Team. Jeder dieser Rollen werden feste Aufgaben und Verantwortlichkeiten zugeordnet. Gemeinsam sollen sie autark und autonom ein Produkt entwickeln und in fortlaufenden Zyklen ausliefern. Für die Steuerung eines Scrum-Projekts stehen die sogenannten „Artefakte“ zur Verfügung:

  • Sprint (kontinuierlicher Entwicklungszyklus, 1 – 4 Wochen, abhängig davon wie oft Lieferung und Feedback sinnvoll sind)
  • Produkt Backlog (Anforderungskatalog, gepflegt vom PO)
  • Sprint Backlog (die Anforderungen des laufenden Entwicklungszyklus, umgesetzt vom Entwicklungsteam)
  • Product Inkrement (wird ausgeliefert vom Entwicklungsteam nach Abnahme durch PO und Stakeholder)

Eine Definition of Done gibt an, wann ein Inkrement als fertig gelten kann. Sie besteht aus einer Liste mit Fertigstellungskriterien und Definitionen des fertigen Zustands, z.B. kann darin stehen, dass eine bestimmte Testabdeckung nicht unterschritten werden darf und bestimmte Arten von Tests vorgeschrieben sind, wie die für innere Logik (Unit) und Integration. Sinnvollerweise sollten auch die erforderlichen Schritte zur Auslieferung, die sogenannten Build und Deployment Tätigkeiten, darin festgelegt werden.

Nach jedem Sprint findet ein Sprint Review Meeting statt, in welchem das Team dem Product Owner und dem Kunden das Sprintergebnis vorstellt. Idealerweise handelt es sich um ein Produktinkrement, welches in Echtzeit vorzuführen ist. Je nach Zufriedenheit mit dem Ergebnis wird das Produkt akzeptiert, oder es werden ergänzende Anforderungen definiert bzw. eine Neuausrichtung eingeschlagen. In der Retrospektive erfolgt eine Betrachtung auf den vergangenen Sprint, um für künftige Sprints Optimierungsmöglichkeiten aufzudecken.

Ein neuer Sprint wird schließlich nahtlos mit einem Sprint Planning Meeting eingeläutet. In dieser Sitzung stellt der Product Owner die am höchsten priorisierten Anforderungen vor und das Entwicklungsteam schätzt erfahrungsbasiert deren Aufwand. Gemeinsam legen sie fest, welche Anforderungen im Sprint umgesetzt werden und bestimmen (optional) dafür ein übergeordnetes Sprint Ziel. Nur solche Anforderungen können dabei berücksichtigt werden, die vom Team im Vorfeld genau genug spezifiziert und klein genug zerteilt wurden. Dieses sogenannte Refinement wird zumeist als regelmäßiges Arbeitstreffen vom Team durchgeführt.  Anschließend an das Sprint Planning wird im Sprint Planning 2 von den Entwicklern bestimmt, in welcher Weise die Arbeitspakete erreicht und welche Details umgesetzt werden.

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.

Zusammengefasst sprechen wir von den vier Scrum Events, die zeitlich durch eine feste Timebox (maximale Länge) reglementiert sind, sowie einen festen, wiederkehrenden Abstand haben. 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.

Scrum sieht zusätzlich zu den Entwicklern und dem PO noch den Scrum Master vor. Er soll seinem 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. Das heißt, die Aufgaben des klassischen Projektmanagers werden in Scrum-Projekten nicht vom Scrum Master, sondern vom Product Owner und den Entwicklern übernommen.

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. Die einheitliche und klare Beschreibung von Scrum förderte dessen Popularität stark und es entwickelte sich dadurch zum weltweit meist angewendeten agilen Verfahren. Unter agilemanifesto.org werden die Agilität definiert und ihre 12 Prinzipien beschrieben, die sich auch in Scrum wiederfinden. Meine Scrum-Kreislauf Grafik bringt das Ganze auf den Punkt:

Scrum Infografik mit BiKaBlo

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.