Soll eine Software neu oder weiterentwickelt, ein Projekt gestartet oder allgemein die Zusammenarbeit verbessert werden, dann stellt sich oft die Frage nach dem geeigneten Arbeitsprozess. Vor allem eine Entscheidung zwischen Scrum und Kanban fällt häufig schwer: Aufgaben-Boards und tägliche, kurze Team-Meetings (Daily) gibt es bei beiden Ansätzen, Sprints als feste Lieferzeitfenster nur in Scrum. Aber wie unterscheiden sich Kanban und Scrum? Wo liegen die Spezifika und was ergibt sich daraus für die Wahl der jeweiligen Methode?

Wer ein Scrum-Training absolviert, wird dort mit sehr hoher Wahrscheinlichkeit mit der Stacey-Matrix oder mit dem Cynefin-Modell konfrontiert. Beide können bei der Methodenwahl helfen, das Cynefin-Modell, indem es Situationen oder Probleme in folgende vier Kategorien unterteilt:

Ist etwas «offensichtlich», so ist der Zusammenhang zwischen Ursache und Wirkung klar nachvollziehbar. In solchen Situationen kann auf bewährte Vorgehensweisen (Best Practices) zurückgegriffen werden. «Komplizierte» Sachverhalte sind hingegen nur mit Expertenwissen zu durchdringen und schwerer prognostizierbar. Hilfreich sind hier Analysen. In ­einem «komplexen» Umfeld ist aufgrund von Wechselwirkungen kaum vorab zu bestimmen, was als Nächstes geschieht oder wie zum Beispiel Kunden reagieren. Wie Ereignisse zusammenhängen und welche Aktion welche Resultate erzeugt, wird erst im Nachhinein klar – nicht nur durch Analysen, sondern auch durch experimentieren und lernen. In einem «chaotischen» Gefüge schliesslich fehlt auch das.

Wie hängt das nun mit der Auswahlmöglichkeit zwischen Kanban und Scrum zusammen? Agile Vorgehensweisen wie Scrum sind genau dann im Vorteil, wenn komplexe Aufgaben gelöst werden sollen oder sich das Unternehmen oder Produkt in einem volatilen Umfeld bewegt, in dem sich die Anforderungen schnell ändern können. In solchen Fällen helfen das häufige und frühe Ausliefern in festen Zeitfenstern sowie regelmässige Möglichkeiten zum Einholen von Rückmeldungen und Anpassen des Produkts. Auch Kanban bietet hierzu passende Mechanismen, konzentriert sich aber weniger auf das konkrete Finden der Lösung durch experimentieren, sondern eher auf das Managen der zu erledigenden Arbeit und das Schaffen einer Basis für Ver­änderungen an sich.

Das von Ken Schwaber und Jeff Sutherland begründete Rahmenwerk Scrum basiert auf einem teambasierten, empirischen Vorgehen mit fest eingebundenen Feedback-Schleifen. Das ermöglicht es, mithilfe von ausprobieren, reflektieren und nachjustieren gemeinsam mit dem Kunden und anderen Beteiligten die passende Lösung oder das für den Kunden bestmögliche Produkt zu entwickeln.

Die Feedback-Zyklen spiegeln sich in den fünf im Scrum Guide beschriebenen Ereignissen wider:

Mit diesem schrittweisen Vorgehen, das am Ende eines jeden Sprints ein potenziell auslieferbares Teilstück, zum Beispiel einer Software, anvisiert, wachsen über die Zeit nicht nur Erkenntnisse über die Zusammenarbeit oder das Anwenderverhalten, sondern auch der Nutzen für die Anwenderinnen und User, also die Kunden.

Diese Kundenzentrierung ist elementarer Bestandteil des zugrunde liegenden Manifests für Agile Softwareentwicklung, das insgesamt betrachtet die Zufriedenheit der Kunden, eine vertrauensvolle und enge Zusammenarbeit sowie eine Konzentration auf das Wesentliche in den Vordergrund rückt. Statt ein Feature-Feuerwerk zu entwickeln, wird die Komplexität reduziert, indem zunächst die wirklich wichtigen und nutzenstiftenden Elemente entwickelt werden. Anforderungen können sich im laufenden Prozess noch ändern. Sie werden nicht am Anfang fixiert und plangesteuert abgearbeitet, sondern können sich nach und nach ergeben; lediglich während eines Sprints, der maximal vier Wochen andauert, ist die eingesteuerte Arbeit fix.

Damit die tägliche Arbeit in einem Scrum-Team gut funk­tioniert und keiner der Aspekte aus dem Blickfeld gerät, wurden für dieses Vorgehen drei verschiedene Rollen mit klarer Abgrenzung und jeweils spezifischem Fokus entwickelt. Kurz gesagt kümmert sich der Product Owner um das Was (Was wird entwickelt?), das Entwicklungsteam um das Wie (Wie kann eine Lösung aussehen?) und der Scrum Master um die Optimierung der Zusammenarbeit und des Prozesses.

Die Rollen sind ebenso wie die Ereignisse obligatorisch und müssen bei einer Einführung von Scrum von Anfang an berücksichtigt werden. Um die festgeschriebenen Rollen mit Leben zu füllen, muss Scrum als Ganzes verstanden und umgesetzt werden. Darf beispielsweise ein Product Owner nicht über sein Produkt entscheiden und agiert lediglich als Sprachrohr des Vorgesetzten oder werden im Team Probleme unter den Teppich gekehrt, so ist der Erfolg gefährdet und Scrum nur eine leere Hülle. Das bedeutet: Wer mit Scrum arbeiten möchte, muss sich auf grössere Ver­änderungen von Anfang an einstellen, den neuen Rollen ihre nötige Handlungs- und Entscheidungsfreiheit zugestehen sowie das Team selbstständig arbeiten lassen.

Kanban wurde bereits Mitte des 20. Jahrhunderts erfunden, die Wurzeln liegen in der Automobilproduktion. Das japanische Unternehmen Toyota entwickelte Kanban als System, um Prozesse dezen­tral zu steuern und effizienter zu werden. Produziert wird in der sogenannten Lean Production nur, was gerade nachgefragt wird (Pull-Prinzip). Wenn von Kanban in der Entwicklung die Rede ist, handelt es sich um die von David Anderson angepasste Version, die Ideen der Lean Production an Produktentwicklung, Services und andere Wissensarbeit anpasst. Anderson selbst beschrieb Kanban als Änderungsmanagement-Methode.

Auch Software-Kanban basiert auf einem Pull-System, das die parallel stattfindende Arbeit begrenzt. Diese sogenannten WIP-Limits (WIP steht für Work in Progress) sorgen dafür, dass sich nur die Menge an Aufgaben im System befindet, die auch abgearbeitet werden kann – nicht mehr. Ziel ist ein möglichst konstanter Arbeitsfluss (Flow) ohne Leerlauf oder Engpässe und somit eine schnellere Auslieferung an den Kunden. Zusätzlich stehen – ähnlich wie bei Scrum – auch bei Kanban der Kunde mit seinen Bedürfnissen sowie der eigentliche Wert der gelieferten Ergebnisse im Mittelpunkt des Handelns.

Kanban verfolgt einen evolutionären Ansatz für Veränderungen. Das heisst: Der Entwickler startet da, wo er sich gerade befindet (etwa mit einer Abbildung des aktuellen Arbeitsprozesses via Board), behält die aktuellen Rollen, Jobtitel und Verantwortlichkeiten bei und nimmt Änderungen erst im weiteren Verlauf vor, wenn diese nötig sind. In diesem Punkt ist Kanban einfacher in der Einführung und Handhabung als Scrum: Eine Umstellung auf neue Verhaltensweisen und Abläufe erfolgt erst nach und nach, sodass sich Teams und auch ihre Umwelt nach und nach daran gewöhnen können.

Wichtig zu betonen ist in diesem Zusammenhang auch, dass die Veränderungen durch die in Kanban angestrebte Visualisierung von Arbeit und Prozess auf Basis gemeinsam festgestellter Schwierigkeiten vorgenommen werden und aufgrund dessen eine höhere Chance auf Akzeptanz auf­weisen. Dies ist bei Scrum zwar prinzipiell auch der Fall, zunächst müssen jedoch die Implementierung der neuen Arbeitsweise und die Verinnerlichung der Prinzipien glücken.

Auch das weitere Vorgehen beim Umsetzen der in Kanban bekannten sieben Feedback-Schleifen (Kadenzen) und zwei Rollen ist in der Praxis weniger strikt als bei Scrum. Auf den ersten Blick könnte man annehmen, dass Kanban mit seinen teils sperrig klingenden Kadenzen mehr Overhead mit sich bringt. In der Praxis müssen aber keine sieben Terminserien eingeführt, sondern vielmehr die dahinterliegenden Ziele erfüllt werden – egal, ob im laufenden Prozess oder in gesonderten Meetings. Diese können bei Bedarf stattfinden und müssen keinen festen Rhythmus haben. Beim Kanban-Meeting (täglich), Replenishment zur Planung der Arbeit und Retro­spektiven hat sich jedoch Regelmässigkeit bewährt, um die Personen, die zusammenarbeiten, an das stetige Kommunizieren, Koordinieren und Reflektieren zu gewöhnen.

Die in der Kanban-Theorie formulierten Rollen Service Request Manager (ähnliches Aufgabengebiet wie ein Product Owner) und Service Delivery Manager (unter anderem zuständig für einen guten Arbeitsfluss) werden von Anderson explizit als nicht erforderlich, sondern eher als «Hüte» gekennzeichnet, die dabei helfen können, in der Praxis auch an die Kundenerwartungen und reibungslose Arbeitsabläufe zu denken.

Wer in einem Kanban-Prozess zusammenarbeiten sollte, ist in der Theorie nicht vorgegeben. Vielmehr ergibt sich eine Teamkonstellation von selbst – anfangs durch den Ist-Zustand und später durch eine unter Umständen sichtbar gewordene Notwendigkeit von Optimierung.

Bei der Wahl zwischen Kanban und Scrum ist es in jedem Fall wichtig zu verstehen, mit welchem Hauptaugenmerk die beiden Ansätze entwickelt wurden, und zu prüfen, ob dieser Zweck mit den eigenen Absichten und Zielen zusammenpasst. Es wäre falsch, Scrum einzuführen, damit die Entwickler schneller arbeiten – denn der Fokus von Scrum liegt auf der Effektivität des Produkts, nicht auf der Effi­zienz der Personen. Ebenso wenig sinnvoll ist Scrum in einem stabilen Umfeld, in dem langfristige Planungen problemlos möglich und keine Änderungen zu erwarten sind.

In diesem Fall wäre der Nutzen im Vergleich zum Aufwand zu gering. Schwierig wird es, wenn wegen äusserer Umstände das ­Scrum-Team und der Prozess nicht richtig aufgesetzt werden, weil etwa viele externe Parteien beteiligt sind und die Aufgaben durch mehrere Übergaben nur zeitversetzt und in längeren, schlecht planbaren Abschnitten bearbeitet werden können. Sinnvolle Sprintziele und -umfänge zu bestimmen, wäre dann kaum möglich. In einem solchen Fall ist Kanban die bessere Wahl. Eventuell lassen sich auch beide kombinieren.

Festzuhalten bleibt, dass eine Entscheidung für eine Arbeitsweise nach Scrum bedeutet, dass Sie die Vorgehensweise im Ganzen implementieren sollten, um tatsächlich von ihr zu profitieren. Führen Sie die Rollen ein und bauen Sie den Prozess mithilfe der fünf beschriebenen Scrum- Ereignisse vollständig auf.

Entscheiden Sie sich aber für Kanban, können Sie schlanker und mit einzelnen Elementen starten. Um­gekehrt würde – gerade in Teams ohne Erfahrung mit diesen Methoden – weder ein Scrum-Prozess gut und wie beabsichtigt funktionieren, der nur auf ausgewählten Teilen des Frameworks beruht, noch wäre Kanban ein Erfolgs­garant, nur weil Sie mit sieben Regelterminen und den zwei Kanban-Rollen beginnen. Hier ist weniger mehr.