Scrum

Scrum erlangte seit Mitte der 1990’er 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 inkrementell, iterativem mit 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 Anpassung der Produktentwicklung. Damit erhöht sich die Wahrscheinlichkeit deutlich, Projekte innerhalb von Budget und Zeit abzuschließen und gleichzeitig ein marktgerechtes Produkt abzuliefern. Die nachfolgenden Abbildungen zeigen eben Beschriebenes schematisch auf.

 Abbildung 1: Wasserfallmodell vs. inkrementelle Lieferung

Abbildung 1: Schematische Darstellung des Inkrementellen Vorgehens

 Abbildung 1: Wasserfallmodell vs. inkrementelle Lieferung

Abbildung 2: Agile Entwicklung im Vergleich zur Wasserfall Plan Entwicklung

 Abbildung 1: Wasserfallmodell vs. inkrementelle Lieferung

Abbildung 3: Komplexität eines Projektes

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 (Sprints) alle 1-4 Wochen ausliefern. Für die Steuerung eines Scrum-Projekts stehen die sog. „Artefakte“ zur Verfügung:

  • Produkt Backlog (Anforderungskatalog)
  • Sprint Backlog (die Anforderungen des laufenden Entwicklungszyklus)
  • Product Increment (potentiell auslieferbares Produkt)

Eine Definition of Done gibt an, wann eine Inkrement als fertig gelten kann. Sie besteht aus einer Liste mit Fertigstellungskriterien und Definitionen, die im Sprint bearbeitet werden sollen. Das bedeutet also, möchte man ein im Sprint Planning sich vorgenommenes Product Backlog-Item abschließen, dann muss das der Definition of Done entsprechen.
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 neue Anforderungen definiert bzw. eine Neuausrichtung eingeschlagen. In der Retrospective 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. Anschließend wird bestimmt, in welcher Weise und welcher Reihenfolge die Arbeitspakete erreicht und welche Details umgesetzt werden. Nur solche Anforderungen können dabei berücksichtigt werden, die vom Team im Vorfeld genau genug spezifiziert wurden. Weiterhin formuliert das Team im Spring Planning Meeting das Sprint Ziel an dem sich das nächste Inkrement messen muss.
Sobald der Sprint beginnt, trifft sich das Team einmal täglich immer zur gleichen Zeit zu einer kurzen Sitzung, 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 Ereignissen, 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.

Abbildung 5 - Team-Komposition im Scrum-Rahmenwerk

Abbildung 4: Team-Komposition im Scrum-Rahmenwerk

2010 wurde der Scrum Guide 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 die Popularität von Scrum stark und entwickelte sich dadurch zum weltweit meist angewendeten agilen Verfahren. Seit 2018 gibt es nun von Scrum.org und Schwaber auch einen Guide zur Anwendung von Kanban innerhalb von Scrum.

Kanban

Ursprünglich wurde Kanban als Teil des Toyota Production Systems (TPS), auch Lean Production System genannt, in der Automobilproduktion eingesetzt. Das Wort mit japanischen Ursprungs bezeichnet eine Signalkarte zur Materialbestellung. 2009 wurde erstmalig der Einsatz von Kanban in der Softwareentwicklung von D.J. Anderson und Henrik Kniberg beschrieben und führte zu einer größeren Popularität.
Hauptziel von Kanban ist die Prozessoptimierung durch die Visualisierung von Arbeitsflüssen und Ressourcenauslastungen auf einem sog. Kanban-Board. Dadurch können Engpässe schnell identifiziert und behoben werden. Außerdem können damit Abhängigkeiten untereinander abgebildet werden.
Das Grundprinzip von Kanban ist, dass sich jeder Bearbeiter selbstständig Aufgaben aus der To Do Liste oder vom Vorgänger nimmt, sobald er für neue Arbeiten bereit ist. Dieses Prinzip nennt man Pull-Prinzip. Mögliche Engpässe werden im Kanban Board dadurch sofort ersichtlich. Die Konsequenz dieser Methode ist, dass die Anzahl an Aufgaben in Bearbeitung limitiert wird, genannt WIP Limit (Work in progress limit). Dabei entscheidet das Projektteam, wie viele Aufgaben gleichzeitig begonnen werden dürfen.
Ein wichtiges Instrument in der Arbeit mit Kanban ist die Messgröße zur Bestimmung der durchschnittlichen Cycle Time. Die Cycle Time beschreibt die Zeitspanne, die für die Fertigstellung (von Beginn der Entwicklung bis zur Bereitstellung) einer Funktionalität benötigt wird. Diese kann schnell ermittelt werden, da das Projektteam die Bestrebung hat, wenige Aufgaben gleichzeitig zu bearbeiten und dabei diese zügig zu beenden. Werden Anforderungen vom Product Owner in ähnlich große Blöcke aufgeteilt, können durch die Bestimmung der durchschnittlichen Cycle Time relativ präzise Vorhersagen über die Dauer zur Fertigstellung einer Funktionalität getroffen werden.
Weitere wichtigen Messgrößen in Kanban sind „Work Item Age“ (Alter von Aufgaben) und Throughput (wieviel Aufgaben pro Zeiteinheit werden fertig?). Dabei lässt sich das Work Item Age in der Praxis gut visualisieren, beispielsweise während der Bearbeitungsphase einer Aufgabe wird pro Tag ein Punkt auf einer Kanbankarte aufgemalt. Wird zusätzlich noch das Datum, wann die Aufgabe begonnen wurde, aufgeschrieben, dann kann das Team die Höhe des Throughput ablesen.
Wer mehr über Kanban erfahren will, aber keine Lust hat, viel Literatur zu lesen, dem empfehle ich Henrik Knibergs Comic „One Day in Kanban Land“. Dort hat er das Prinzip von Kanban auf den Punkt gebracht – ein Bild sagt bekanntlich mehr als tausend Worte.

Scrum und Kanban in der Praxis

Nicht selten wird in der Praxis Scrum und Kanban miteinander verbunden. So wird Scrum häufig mit Kanban-Methoden ergänzt, da sie eine noch feinere Optimierung des autonomen Arbeitens ermöglichen. Die Kanban Visualisierungstechnik fördert die Scrum-Prinzipien der Transparenz, Überprüfung und Anpassung wesentlich. Außerdem gilt das Pull-Prinzip gleichermaßen in Scrum, da es wie Kanban auf selbstorganisiertes Arbeiten setzt.

Jetzt teilen auf:

2 Comments

  1. Sophie-Marie Rudolph 11. Mai 2021 at 19:18 - Reply

    Gelungener Artikel! Du hast die Unterschiede sehr deutlich gemacht. Ich nutze für meine Projekte sowohl Kanban als auch Scrum. Hast du schon von der Methode Scrumban gehört? Diese vereint die Vorteile beider Methoden. Ich habe hier einen Artikel für deine Leser, der vielleicht noch weitere Informationen gibt. Ich freue mich über jedes Feedback!
    https://zenkit.com/de/blog/kanban-oder-scrum/

  2. Daniel Lachmann-Nishibane 26. Mai 2021 at 8:16 - Reply

    Hallo Sophie,
    danke für Dein Interesse!
    Ich denke für ein Scrum Team ist es sehr sinnvoll die Kanban Methode anzuwenden um den Flow der Aufgaben innerhalb ihres Sprint Backlog zu organisieren und zu visualisieren.
    Dann kann es auch sinnvoll sein, weitere Kanban Boards z.b. für Support Aufgaben zu pflegen, wenn das Scrum Team auch den Betrieb des Produkts unterstützt und dafür ein festes Zeitbudget einplant.
    In manchen Situationen kann es auch sinnvoller sein Kanban ohne Scrum anzuwenden, wenn die Arbeit mehr in Richtung Maintainance und Support geht, also eher reaktiv und wenig planbar ist.
    In meinen Augen gibt es keine „Scrumban Methode“, es gibt Scrum Teams die Kanban einsetzen und es gibt Teams die nur Kanban nutzen. Für Scrum Teams die Kanban nutzen empfehle ich den „Kanban Guide for Scrum Teams“ von Scrum.org: https://www.scrum.org/resources/kanban-guide-scrum-teams
    Schöne Grüße
    Daniel

Jetzt kommentieren