Scrum – Kurzübersicht mit BiKaBlo Grafik

Scrum erlangt seit Mitte der 1990er Jahren 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 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 internen Rollen des Scrum Teams sind Entwicklungsteam, Product Owner und Scrum Master. 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 Increment (wird ausgeliefert vom Entwicklungsteam nach Abnahme durch PO und Stakeholder)

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 (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 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 schließlich nahtlos mit einem Sprint Planning Meeting eingeläutet. Darin stellt der Product Owner die am höchsten priorisierten Anforderungen vor und das Entwicklungsteam schätzt erfahrungsbasiert deren Aufwand. Gemeinsam legen sie fest, was davon im Sprint umgesetzt wird und bestimmen dafür ein übergeordnetes Sprint Ziel. Nur solche Anforderungen können dabei berücksichtigt werden, die vom Team im Vorfeld klein genug zerteilt und genau genug, inklusive der Akzeptanzkriterien, beschrieben 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, welche Arbeitspakete gebraucht werden, welche Abhängigkeiten es gibt und mit welchen technischen Mitteln das Ziel erreicht werden soll.

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 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 das Entwicklungsteam.

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 meist genutzte agile Verfahren. Unter agilemanifesto.org werden die Agilität definiert und ihre 12 Prinzipien beschrieben, die sich auch in Scrum wiederfinden. Die Scrum BiKaBlo Grafik bringt das Ganze auf den Punkt:

BiKaBlo Scrum Grafik

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.