Scrum und Kanban erklärt

Teil 2 Scrum und Kanban erklärt

Scrum:

Scrum erlangte seit Mitte der 1990’er Jahren durch Publikationen und Vorträge von Ken Schwaber und Jeff Sutherland größere Bekanntheit als Prozessrahmenwerk zum Management der Arbeit an komplexen Produkten (Abbildung 10). Es beruht auf durch Schwaber und Sutherland in der Praxis gewonnen Erkenntnissen, über den Wettbewerbsvorteil der durch die Verbindung von inkrementell, iterativem mit empirischem Vorgehen in Softwareentwicklungs-Projekten entsteht, insbesondere im Vergleich zum Wasserfall Vorgehen. Ersteres erzeugt Risikominimierung durch hohe Transparenz des Entwicklungsfortschrittes und letzteres sorgt für die kontinuierliche Überprüfung der Ergebnisse und die Anpassung der Entwicklung an neue Erkenntnisse. Damit erhöht sich die Wahrscheinlichkeit deutlich, Projekte innerhalb von Budget und Zeit abzuschließen und dabei ein marktgerechtes Produkt abzuliefern. Abbildungen 7, 8 und 9 machen dies anschaulich.

Abbildung 5

Abbildung 6

Abbildung 7

Abbildung 8

Scrum besticht durch sein minimalistisches Regelwerk und seine leichtgewichtige Struktur die den Einstieg sehr einfach macht. Es definiert ein Team bestehend aus: den Entwicklern (3-9 Personen), dem Produkt Owner (PO) und dem Scrum Master. Gemeinsam sollen sie autark und autonom ein Produkt entwickeln und in fortlaufenden Zyklen, genannt Sprint, alle 1-4 Wochen ausliefern. Dazu müssen sie alle technologischen und fachlichen Kompetenzen die dazu nötig sind im Team vereinigen. Dieses Team erzeugt, inspiziert und adaptiert dazu laufend drei Artefakte: den Produkt Backlog (Anforderungskatalog), den Sprint Backlog (die Anforderungen des laufenden Entwicklungszyklus) und das potentiell auslieferbare Produkt Inkrement als Ergebnis jeden Sprints. Die Auslieferbarkeit der Produkt Inkremente wird vom Team gegen die Definition of Done (Akzeptanz und Abnahmekriterien) des Projektes im Rahmen der Sprint Review Sitzungen geprüft, bevorzugt im Beisein der Kunden und Anwender. Das Review markiert den Abschluss eines Sprints, zusammen mit der nahtlos folgenden Retrospektive Sitzung, in der das Team plant wie es sich noch weiter verbessern kann. Der neue Sprint wird schließlich auch nahtlos durch die Sprint Planungssitzung eingeläutet. In dieser Sitzung stellt der PO die am höchsten priorisierten Anforderungen vor und das Entwicklungsteam schätzt erfahrungsbasiert deren Aufwand, bevor es entscheidet wie viele es in den Sprint Backlog zieht und dann die Details der Umsetzung bespricht. Nur solche Anforderungen können dabei berücksichtigt werden, die vom Team im Vorfeld klein genug geteilt und genau genug spezifiziert wurden. In der Sprint Planung formuliert das Team auch das Sprint Ziel an dem sich das nächste Inkrement messen muss. Sobald der Sprint angefangen hat 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. Dieses sogenannte Daily Scrum wird meistens im Stehen abgehalten um Aufmerksamkeit zu fördern. Zusammengefasst sprechen wir von den vier
Scrum Ereignissen die zeitlich reglementiert sind durch eine feste Timebox (maximale Länge), sowie einem 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, der seinem Team bei der korrekten Anwendung von Scrum behilflich sein und sie zu einer selbstorganisierten Arbeitsweise hinführen soll. 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 Projekt Managers werden in Scrum Projekten nicht vom Scrum Master, sondern vom PO und den Entwicklern übernommen.

Abbildungen 7 und 8 zeigen schematisch das Rahmenwerk Scrum und dessen Team Komposition.

Die meisten Scrum Teams ergänzen innerhalb von Scrum auch die im vorherigen Kapitel beschriebenen Kanban Methoden, 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.

Seit 2010 wird unter der Führung von Schwaber und Sutherland der Scrum Guide als weltweit gültiger Leitfaden für Scrum veröffentlicht und regelmäßig aktualisiert. Er steht übersetzt in etlichen Landessprachen zur Verfügung.

Diese einheitliche und klare Beschreibung von Scrum, hat dessen Popularität stark gefördert und es zum weltweit meist angewendeten agilen Verfahren gemacht.

Seit 2018 gibt es nun von Scrum.org und Schwaber auch einen Guide zur Anwendung von Kanban innerhalb von Scrum. Was Kanban ist und wie es verwendet wird erkläre ich im nächsten Abschnitt.

Abbildung 9

 

Abbildung 10

Kanban

Ursprünglich wurde Kanban als Teil des Toyota Production System (TPS), auch Lean Production System genannt, in der Automobilproduktion eingesetzt. Das Wort ist Japanischen Ursprungs und bezeichnet eine Signalkarte zur Materialbestellung. Ab 2009 wurde es unter anderem durch Veröffentlichung von D.J. Anderson und Henrik Kniberg für den Einsatz in der Softwareentwicklung populär gemacht.

Kanban besteht aus Strategien zur Flussoptimierung von Wert an Stakeholder durch den Einsatz eines visuellen Pull Systems, dem Kanban Board, dass die angefangene Arbeit limitiert. Dieses Limit ist bekannt unter dem Englischen Akronym WIP Limit (Work in progress limit). Pull bedeutet hierbei das Aufgaben nicht mehr zugewiesen werden, sondern ein Entwickler aus dem Team den Zeitpunkt bestimmt wann er oder sie damit beginnt. Dabei bestimmt das Team auch wieviel Aufgaben gleichzeitig begonnen werden dürfen.

Das zentrale Element von Kanban ist also das Prinzip des Flusses von wertvollen Liefereinheiten durch alle Produktentwicklungsstufen. Durch Verbesserung von Effizienz, Effektivität und Vorhersagbarkeit des Entwicklungsprozesses soll dieser Fluss kontinuierlich verbessert werden.

Dadurch das Teams darauf achten nur wenige Aufgaben gleichzeitig in Arbeit zu ziehen und möglichst schnell die angefangenen Aufgaben zu beenden, können sie ihre durchschnittliche Cycle Time messen und bestimmen. Cycle Time ist die Zeit die eine Funktionalität vom Beginn der Entwicklung bis zur Bereitstellung beim Kunden benötigt. Damit kann ein Team nach einer Weile relativ präzise Vorhersagen treffen, wie lange es dauern wird bis Funktionalität X zur Verfügung steht, gemessen ab dem Zeitpunkt an dem die zugehörige Anforderung vom Product Owner (Kundenvertreter) an die Spitze des Backlogs (Liste der Anforderungen) geschoben wurde. Vorausgesetzt wird hierbei, dass es dem Product Owner gelingt die Anforderungen in ähnlich große Blöcke zu schneiden.

Andere Messgrößen in Kanban sind das Alter von Aufgaben (Work Item Age) und wieviel Aufgaben pro Zeiteinheit fertig werden (Throughput). In der Praxis lässt sich Work Item Age gut visualisieren in dem das Team einen Punkt pro Tag auf die Kanban-Karte am Board malt, solange die zugehörige Aufgabe in Bearbeitung ist. Wenn es dann noch das Datum ab wann eine Aufgabe begonnen wurde auf die Karte schreibt, kann das Team einfach ablesen wie hoch der Throughput ist.

Folgender Comic „One Day in Kanban Land“ (Abbildung 3 -6) von Henrik Kniberg bringt das Kanban Prinzip auf den Punkt, bekanntlich sagt ein Bild mehr als tausend Worte:

One Day in Kanban Land Comic:

Abbildung 1                     Abbildung 2

Abbildung 3                     Abbildung 4

Teil 3 DevOps erklärt

Teil 1: Scrum, Kanban und DevOps in der Praxis

Quellen Angabe:

Anderson, D. J.: Kanban -Successful Evolutionary Change for your Technology Business (2010)

Henrik Kniberg – One Day in Kanban Land (2009)

Henrik Kniberg – Produkt Owner in a nutshell

Scrum Guide 2017 Deutsch PDF

Kanban Guide for Scrum Teams 2018

Das Scrum Team – Grafik von Daniel Foo – Daniel Foo

Scrum.org 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.