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 2: Schematische Darstellung des Inkrementellen Vorgehens

Abbildung 3: Agile Entwicklung im Vergleich zur Wasserfall Plan Entwicklung

Abbildung 4: 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  zeigt schematisch die Team-Komposition im Scrum-Rahmenwerk auf:

Abbildung 5: 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.

Tags:

Keine Kommentare vorhanden.

    Schreibe einen Kommentar

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