Das Agile Manifest ist der kleinste gemeinsame Nenner aller agilen Vorgehensmodelle, das in nur vier Sätzen ausdrückt, welche Prinzipien für die agile Entwicklung zugrunde gelegt werden sollten.
Scrum und Kanban gehören dabei zu den bekanntesten agilen IT-Projektmethoden und erweitern das Agile Manifest um weitere Leitsätze. Scrum schreibt dabei im Vergleich zu Kanban mehr vor und setzt umfassendere Rahmenbedingungen voraus. Dennoch haben sie beide ihre Daseinsberechtigung.
Unter manchen Agilisten wird Scrum jedoch geradezu dogmatisch eingesetzt ohne die Begebenheiten der Organisation und die individuellen Charakterzüge eines Projekts zu betrachten. Dabei sollten beide Ansätze als empirisch aufgefasst werden, die dabei helfen sollen, den Weg einer kontinuierlichen Verbesserung zu finden. Es fällt einem dabei nicht immer leicht, eine Richtung zu finden und glaubt man einmal die richtige Richtung gefunden zu haben, kann sich diese mit der Zeit wieder „falsch“ anfühlen.
Anhand der Erfahrung aus einem mittlerweile erfolgreich beendeten Projekt, das als Scrum aufgesetzt wurde und im weiteren Verlauf immer mehr Kanban-Züge erhielt, möchte ich euch konkrete Fragestellungen beschreiben, die damals dafür sorgten, den Kompass neu zu justieren. Ich hoffe, sie helfen auch euch, euer Projekt / eure Situation aus dem Korsett des Scrums zu befreien, um das Kind beim Namen zu nennen: Hallo Kanban!
- Ü„ndern sich die Anforderungen bzw. deren Prioritäten schlagartig?
Falls ja, ist dies als Zeichen für ein Kanban-Vorgehen zu werten, da innerhalb von Scrum die Sprints geschützt werden sollten. In einem Sprint committed sich das Team (neuerdings wird es als Forecast des Teams betrachtet) darauf, bestimmte Anforderungen innerhalb eines Sprints zu bearbeiten und idealerweise am Ende dessen produktiv auszuliefern. Das Team identifiziert sich vollkommen mit dem Sprintinhalt und ist sich sicher, diese Inhalte am Sprintende auch ausliefern zu können. Ü„ndert sich plötzlich der Inhalt oder Umfang des Sprints, geht das meist auf die Motivation des Teams und die langfristige Teamleistung (Velocity), was sich letztendlich kontraproduktiv auswirkt.
In Kanban können dafür neue Anforderungen jederzeit an das Team zugetragen werden. Idealerweise gelingt ein gleichmäßiger Arbeitsfluss. Ergeben sich jedoch neue Erkenntnisse und somit Anforderungen, können laufende Aktivitäten an anderen Anforderungen zurückgestellt oder sogar komplett verworfen werden. Die Auslieferung der Anforderung kann ggf. sofort erfolgen. Die Leistung des Teams (Cycle Time) kann sich durch diese Veränderung sogar erhöhen, wenn die neue Anforderung schneller umgesetzt werden kann.
- Trägt die Schätzung und die Planung noch zu einem Mehrwert bei?
Im Kontext von Scrum-Projekten hat sich das Schätzen von Anforderungen in abstrakten Einheiten wie Story Points oder T-Shirt-Größen etabliert. Daraus lassen sich die Planbarkeit (Passt sie noch in den Sprint?) als auch die Machbarkeit einer Anforderung abschätzen. Nach einer gewissen Projektzeit verlieren diese Informationen an Relevanz. Schätzrunden und Planungsmeetings werden vermehrt als überflüssig angesehen, da die Meetings inhaltliche, sich wiederholende Muster erkennen lassen („ist doch alles die gleiche Komplexität“) oder weil das gemeinsame darüber sinnieren keinen Mehrwert mehr bringt („dazu kann ich nichts sagen, das macht dann eh ein anderer“). In der IT sind das meist Projekte in der Wartungsphase, wo Teams an ungeplanten Ü„nderungen bzw. Verbesserungen der Software arbeiten. Die Aufgaben sind zumeist auch technisch wie fachlich voneinander unabhängig und können nur von gewissen Teammitgliedern bearbeitet werden.
Die Komplexität und der langfristig aufkommende Workload sind in solchen Fällen kaum abschätzbar und somit gestaltet es sich immer schwieriger, stabile Sprints zu bilden. Stattdessen sollte eigentlich ein kontinuierlicher Aufgabenfluss stattfinden, wie Kanban es vorsieht.
- Können nur bestimmte Teammitglieder bestimmte Aufgaben erledigen?
Wenn es immer öfter vorkommt, dass anstehende Aufgaben nur von Teammitgliedern erledigt werden können, die spezielles Expertenwissen oder Vorwissen besitzen, sollten die Alarmglocken läuten. In Scrum darf diese Situation nämlich nicht auftreten, da hier jedes Teammitglied über ein cross-funktionales (T-Shaped) Wissen besitzt. Das bedeutet, dass jeder Einzelner im Team fähig ist bzw. befähigt werden kann eine anstehende Aufgabe von Anfang bis Ende erfolgreich zu bearbeiten.
- Finden Reviews und Retrospektiven nicht mehr (regulär) statt?
Falls Reviews und Retrospektiven immer weniger oder nicht stattfinden, ist das ein Zeichen dafür, dass Scrum nicht (mehr) gelebt wird. Meist ist dies eine Folge der Veränderungen, die sich u.a. auch aufgrund der vorherigen Erläuterungen ergeben haben. Auch wenn beide Projektmethoden eine kontinuierliche Verbesserung anstreben, sind diese beiden Meetings in Scrum so essentiell, dass eine kontinuierliche Verbesserung fast nur durch sie ermöglicht werden.
Die kontinuierliche Verbesserung in Kanban erfolgt dagegen meist durch Beobachtung und Anpassung des gelebten Prozesses. Meistens geschieht dies nicht in einem ordentlichen Retrospektive-Meeting, sondern fortwährend (Stichwort PDCA-Zyklus). Wenn dann mögliche „Bottelnecks“ identifiziert und beseitigt werden sollen, wird der Prozess so schnell wie möglich angepasst. Dabei kann er beispielsweise durch „WIP Limit erhöhen oder senken“, „mehr oder weniger Leute im Team“, „Abläufe anpassen“, etc. entsprechend neu justiert, beobachtet und ggf. wieder angepasst werden.
- Die Frage aller Fragen“¦
Eine moderne Interpretation der agilen Prinzipien. Bildquelle: http://modernagile.org
Abgesehen davon sollte man sich stets die Frage aller Fragen stellen: Leben wir (noch) die agilen Prinzipien? Wenn nicht, dann könnten der Ehrlichkeit halber nämlich beide weg ;-).
