Manchmal wundere ich mich über die teilweise heftig geführte Auseinandersetzung zwischen Verfechtern von Scrum und Verfechtern von Kanban. Beide Methoden haben viel mit dem agilen Manifest zu tun und wie immer Vor- und Nachteile. Auch wenn sich vor allem Scrum konkreter an die enthaltenen Aussagen und Prinzipien orientiert, sind die Prinzipien von Kanban auch nicht weit von der agilen Idee weg. Getreu der ersten Aussage des agilen Manifests „Individuen und Interaktionen mehr als Prozesse und Werkzeuge“ gehe ich also davon aus, dass es in erster Linie um eine gute Organisation der Arbeit gehen sollte.
Scrum, Kanban und weitere agile Vorgehensweisen eint ihr ganzheitlicher Blick auf die Projektarbeit sowie die kontinuierliche Weiterentwicklung der Team- und Entwicklungsprozesse. Dahinter steckt die Erkenntnis, dass Probleme und unsere Lösungen nicht statisch sind. Warum sollten es unsere Prozesse sein?Jan Gentsch
Für die gemeinsame Arbeit halte ich es zunächst grundsätzlich für wichtig, dass es ein gemeinsames Verständnis über Verantwortlichkeiten, Aufgaben und Regeln gibt. Gleichzeitig sollte innerhalb der Regeln eine gewisse Flexibilität, ein eigener Gestaltungsspielraum bestehen und die Regeln müssen sich an der Realität orientieren. Methoden wie Scrum und Kanban eignen sich meiner Ansicht nach beide für die Software Entwicklung von komplexen Produkten (und Projekten).
Wenn man also davon ausgeht, dass sich beide durchaus unterschiedlichen Methoden gut eignen und viele Teams gute Erfahrungen damit gemacht haben, stellt sich die Frage, wieso man so schnell versucht ist, lieber „seine eigene individuelle“ Methode zu finden, anstatt sich mit mehr Nachdruck darum zu kümmern, Scrum oder Kanban „richtig“ einzuführen und zu machen. Bevor ich einen ganz eigenen Prozess aufsetze, würde ich es zunächst mit einem der beiden bekannten gut dokumentierten und viel diskutierten Prozesse Scrum oder Kanban versuchen, dabei lernen und dann besser werden. Erst Shu dann Ha und dann Ri.
Die Herausforderung dabei: Beide verlangen von den Mitarbeitern hohe eigene Motivation und die Übernahme von Verantwortung. Die Anforderungen an die Mitarbeiter auch neben ihren technischen Fähigkeiten sind in beiden Methoden vielschichtig und hoch. Wenn man sich entschieden hat, dass man agilen Prinzipien folgen will, besteht diese Herausforderung ohnehin. Dann bleibt die Frage, ob Scrum, Kanban oder Scrumban die bessere Methode ist. Das hängt meiner Erfahrung nach im Wesentlichen von drei Faktoren ab.
- Sind strukturelle Veränderungen nötig und möglich?
- Wie erfahren sind die Mitarbeiter?
- Wie wichtig ist Flexibilität?
Sind strukturelle Veränderungen nötig und möglich?
Scrum ist schwerer einzuführen, weil es ein umfangreicheres Regelwerk als Kanban mitbringt, eine gewisse (neue) Struktur und die Einführung neuer Rollen fordert. Kanban hingegen baut auf dem aktuell bestehenden Prozess auf und kann einfach eingeführt werden.
Wie erfahren sind die Mitarbeiter?
Scrum gibt einen Rahmen vor, an dem sich auch unerfahrene Mitarbeiter orientieren können. Außerdem gibt es mit dem Scrum Master jemanden, der die Einhaltung der Regeln beachtet und den kontinuierlichen Verbesserungsprozess vorantreibt. In Kanban gibt es solche Rollen nicht, die Mitarbeiter müssen erfahren genug sein, um den Prozess kontinuierlicher Verbesserung voranzutreiben.
Wie wichtig ist Flexibilität?
Es gibt Arbeitsumfelder, in denen Management- oder Kundenseitig, eine Flexibilität gefordert ist, die sich nicht mit klar definierten Sprintlängen vereinbaren lassen. Scrum geht von einem geschützten Entwicklungsrahmen von 1-4 Wochen (Sprints) aus. Kanban macht diesbezüglich keine Vorschriften und ermöglicht theoretisch eine kontinuierliche Neupriorisierung von Aufgaben.
Warum dann nicht ein selbstgestricktes Scrumban?
Die Kombination von Kanban mit Elementen von Scrum hört man auch immer wieder. Führt man einen „Scrumban-Prozess“ ein, ist das ein Kompromiss mit den üblichen Vor- und Nachteilen, die aus Kompromissen entstehen. Einfacher einzuführen als Scrum aber schwerer zu leben weil eine tiefere Erfahrung Voraussetzung ist. Scrumban habe ich gut erlebt als nächste „Entwicklungsstufe“ von Kanban, weil im Rahmen der kontinuierlichen Verbesserung des Kanban Prozesses auch Elemente von Scrum ausprobiert und für gut befunden wurden. Mit der direkten Einführung eines selbstgestrickten Scrumban-Prozesses wiederum habe ich weniger gute Erfahrungen gemacht, weil es lange gedauert hat, bis Regeln, Rollen und Verantwortlichkeiten für alle klar definiert waren.
Fazit
Scrum habe ich als einfacher zu lernen erlebt. Die Mitarbeiter konnten leichter ein agiles Mindest entwickeln und die eigene Arbeit einfacher professionalisiert werden. Ein Prozess kontinuierlicher Verbesserung fand sich schneller und selbstverständlicher ein. Durch die festgelegten Rollen und Regeln ist Scrum aber schwerer einzuführen und stark abhängig vom Know-How der „Einführer“.
Kanban ist wesentlich leichter einzuführen, weil es auf dem bestehenden Prozess im Team oder Unternehmen aufsetzt und von der Basis den Arbeitsprozess individuell an die Unternehmensstrukturen angepasst eine kontinuierliche Verbesserung ermöglicht. Gleichzeitig ist es schwerer, Kanban direkt zu leben, weil es darum geht, bestehende Strukturen zu besseren Strukturen zu verändern, ohne dabei einen konkreten Rahmen zu haben, an dem man sich orientieren könnte.
Bisher habe ich die Wahl der Methode vor allem abhängig von den äußeren Rahmenbedingungen gemacht und stelle mittlerweile fest, dass die Erfahrenheit der Mitarbeiter für die Einführung eine viel größere Rolle spielt, als ich bisher gedacht habe. Deswegen tendiere ich dazu, aktuell eher Scrum in Teams einzuführen (auch wenn die Arbeit des Teams wenig komplex ist und Teamarbeit weniger erforderlich ist), als mit Kanban zu beginnen.
Am Ende ist die Einführung jeder der Methoden eine Herausforderung. Die Anforderungen an agile Softwareentwickler sind hoch und die Veränderungen in der ganz individuellen Arbeit und Denkweise sind teilweise grundlegend. Ohne gute und längerfristige Begleitung von erfahrenen Kollegen oder Beratern wird die Einführung schwierig, langwierig und häufig für die Mitarbeiter auch so frustrierend, dass es sehr schwer wird, die Einführung zu einem guten Ergebnis zu führen.