Wenn man etwas zu Kanban erzählt, kommen immer Fragen wie: "Ist das besser als Scrum?", "Wann verwendet man Kanban, und wann Scrum?" usw. Diese Fragen ergeben genau genommen keinen Sinn, denn Scrum und Kanban sind keine Gegensätze. Henrik Kniberg hat es einmal sehr nett ausgedrückt [1]: Genau so gut könnte man fragen, was besser ist, Messer oder Gabel? Manchnmal braucht man ein Messer, manchmal eine Gabel, manchmal beides, und manchmal etwas ganz Anderes, z.B. einen Löffel.
Scrum ist ein Management-Framework (zumindest lautete so die offizielle Sprachregelung der ScrumAlliance bis zur Einführung des Certified Scrum Developers). D.h. Scrum sagt etwas dazu, welche Rollen man besetzen sollte, welche Artefakte man benötigt, und welche Meetings zu welchen Zeitpunkten durchgeführt werden sollten, um erfolgreich Produkte zu entwickeln. Kanban ist kein Management-Framework, sondern eine Change-Management-Methode. In Kanban geht es darum, den bestehenden Prozess (wie auch immer der aussehen mag) durch Visualisierung, Limitierung und Messungen immer weiter zu verbessern. Es kann durchaus sein, das man Kanban verwendet, um Seine Scrum-Implementierung noch weiter zu verbessern (das nennt sich dann Scrumban [2]). Es kann aber auch sein, dass man Kanban auf einen Wasserfall-ähnlichen Prozess aufsetzt, um ihn in kleinen Schritten immer agiler zu machen
Wenn man genau hinhört, dann wird zwar gefragt, ob Scrum oder Kanban besser sei, aber dahinter steht meistens eine ganz andere Frage: Nämlich die Frage nach dem Sinn und Unsinn von Iterationen. Hierzu macht Scrum ja die klare Aussage, dass es Iterationen (Sprints) fester Länge geben muss - zwei Wochen scheint inzwischen die häufigste Sprintlänge zu sein. Es gibt also alle zwei Wochen ein Priorisierungsmeeting, ein Sprint Review und eine Retrospektive. Kanban sieht keine Iterationen vor - es verbietet sie jedoch auch nicht. David Anderson ampfiehlt immer wieder, auch in Kanban regelmäßige Rhythmen (cadences) zu etablieren. Wie lang diese Rhythmen sind und ob sie miteinander gekoppelt sind, hängt vom jeweiligen Kontext ab, in dem das Team und die Organisation sich befindet. Wenn der Aufwand für ein Release sehr hoch ist, dann ist es vielleicht (zunächt einmal) sinnvoll, nur alle zwei Monate zu releasen und sich immer wieder Gedanken zu machen, wie man die Kosten für das Release (Koordinierungs- und Transaktionskosten) kontinuierlich senken kann, um einmal pro Monat, alle zwei Wochen oder wöchentlich releasen zu können. Wenn aber auf der anderen Seite die Kosten für die Priorisierung neuer Anforderungen sehr gering sind (z.B. weil es bereits regelmäßige Abstimmungsmeetings gibt, in denen die richtigen Leute für die Priorisierung zusammensitzen), dann kann es sehr sinnvoll sein, die Priorisierungen in einem viel kürzeren Takt vorzunehmen. Dann gibt es zwar immer noch nur alle zwei Monate ein neues Release, aber die meisten Anforderungen, die in diesem Release umgesetzt werden, sind wesentlich jünger als zwei Monate. Auch hier gilt wieder: Nur weil etwas im Moment so ist, bedeutet das noch lange nicht, dass es so bleiben muss. Aber der Startpunkt sieht erst einmal genau so aus.
Kanban schreibt also keine Iterationen vor, verbietet diese jedoch auch nicht. Deshalb lässt sich Scrum auch als eine spezifische Ausprägung eines Kanban-Systems ansehen (bei dem nämlich die drei genannten Rhythmen in Form von Iterationen gekoppelt sind). Und tatsächlich könnte ich mir vorstellen, dass man mit einem Wasserfall-ähnlichen Entwicklungsprozess startet und ihn mit Kanban kontinuierlich immer weiter anpasst, bis eines Tages Scrum dabei herauskommt (oder etwas sehr Scrum-Ähnliches).
Scrum als Management-Framework steht also nicht im Widerspruch zu Kanban als Change-Management-Methode. In dieser Hinsicht ist die Frage "Scrum oder Kanban" tatsächlich unsinnig. Allerdings führen die meisten Organisationen agile Methoden ja nicht auf der grünen Wiese ein, sondern sie haben bereits einen etablierten Entwicklungsprozess, mit dem sie aber unzufrieden sind. Und sie versprechen sich von Scrum massive Verbesserungen (oft auch den einzigen Ausweg). In diesem Szenario geht es also um Veränderungen, und Scrum ist der Trigger, um diese Veränderungen anzustoßen, bzw. erst einmal das volle Ausmaß der Probleme transparent zu machen. Wenn wir aber von Veränderungen sprechen, dann ist es sinnvoll, sich zu überlegen, ob man diese disruptiv (also revolutionär) oder evolutionär einführen möchte. Scrum steht für den ersten Ansatz, Kanban für den zweiten. Keiner der beiden Ansätze ist per se besser oder schlechter, sondern der Kontext entscheidet. Wenn ein Unternehmen mit dem Rücken zur Wand steht, ist Scrum vielleicht der einizig mögliche Ausweg. Und in dieser Situation sind die Beteiligten häufig auch bereit, schmerzhafte Veränderungen durchzuführen. In anderen Situationen hingegen werden revolutionäre Veränderungen nicht akzeptiert - oder nach ersten Erfolgen bei einzelnen Teams wird die Skalierung durch Vertragsgestaltungen, Prämienmodelle o.ä. ausgebremst. Dann könnte Kanban der bessere Ansatz zur Veränderung sein. Eine Erfolgsgarantie gibt es weder hier noch dort.
P.S. Eigentlich sollten in diesem Post zwei Graphiken zum Zusammenhang zwischen Kanban und Scrum abgebildet sein. Nach einer Dsikussion mit Bernd Schiffer und Stefan Roock (vielen Dank dafür!) bin ich jedoch zu dem Schluss gekommen, dass ich darüber erst noch weiter nachdenken muss und daraus wohl ein eigener Post wird.
Referenzen
[1] Henrik Kniberg und Mattias Skarin (2010): "Kanban and Scrum - Making the Most of Both." Buch bei Amazon oder kostenloser Download
[2] Corey Ladas (2009): "Scrumban - Essays on Kanban Systems for Lean Software Development." Buch bei Amazon
No comments:
Post a Comment