Wie Scrum und Kanban sich unterscheiden und ergänzen

Ich finde es wichtig, dass wir kontextabhängig und vom Problem kommend den Ansatz wählen, der (initial) am besten zur Herausforderung passt. Ich bin ein großer Fan von Scrum, aber auch von Kanban. Beide Ansätze nutze ich gerne und häufig – abhängig vom Kontext und der Aufgabenstellung. Dabei kommt öfter dann auch die Frage auf, warum ich im einen Kontext Scrum vorziehe, in einem anderen Kanban den Vorzug gebe. Diese Frage möchte ich heute in Teilen versuchen zu beantworten, denn eine abschließende Antwort im Sinne einer Checkliste kann es meines Erachtens nicht geben.

Die Unterscheidung, die man oft hört, dass Scrum als Rahmenwerk für (komplexe) Projekte geeignet, während Kanban eher für die „Linienarbeit“ geeignet sei, wird meiner Meinung nach weder Scrum noch Kanban wirklich gerecht. Auch wenn bei einer oberflächlichen Betrachtung genau dieser Eindruck entsteht. Eine Möglichkeit der Differenzierung hat Ralf Kruse in einer Podcast-Folge sehr schön ausgearbeitet, die ich sehr hörenswert finde. Er unterscheidet nach dem Kontext des Einsatzgebietes und der Frage, was man erreichen will.

Erkunden unbekannter Gebiete vs. evolutionäre Veränderung bestehender Strukturen

 Worauf müssen Scrummer bei Kanban achten?

Ralf Kruse bringt es, wie ich finde, sehr gut auf den Punkt, wenn er auf der einen Seite von „evolutionären Veränderungen“ und auf der anderen Seite von disruptiver Neuentwicklung spricht, worin die Stärken der jeweiligen Vorgehensweisen liegen. Scrum ist ein Rahmenwerk, das das explorative Lernen erleichtert und mit seinen Rollen, Artefakten, Events den notwendigen Rahmen bietet, in dem sich die Beteiligten auf die Entdeckung neuer Erkenntnisse in einem schwer überschaubaren Kontext einlassen. Einer Erkundungsexpedition gleich tastet sich das Scrumteam durch fremdes Terrain und erkundet Schritt für Schritt die Thematik. Wir haben es mit einer Vielzahl von Unbekannten zu tun, die durch kontinuierliche Reflexion entdeckt und erforscht werden. Die notwendige Stabilität und Orientierung, die die Fokussierung auf das unbekannte Land ermöglicht, bietet das – auf die wesentlichen Gelingensgründe reduzierte, leichtgewichtige – Rahmenwerk, ohne dabei zum Hindernis der notwendigen Flexibilität und Adaptionsfähigkeit zu werden.

Dem gegenüber steht Kanban als Methode des evolutionären, kontinuierlichen Wandels. Die meisten nehmen bedauerlicherweise Kanban ausschließlich als Visualisierung von Arbeitsprozessen mit einer Limitierung der parallelen Arbeit und visuellen Signalen. Sie übersehen dabei jedoch die Change-Prinzipien, denen Kanban zugrunde liegt:

Hier wird ersichtlich, Kanban strebt die kontinuierliche Verbesserung und Weiterentwicklung im Sinne von Kaizen an und bietet sich eben nicht nur für die Visualisierung von Arbeitsflüssen und die Steuerung der Arbeitsmenge an, die durch die Visualisierung möglich wird, sondern setzt darauf, ausgehend von der IST-Situation, die Organisation (basierend auf empirischen Ergebnissen) zu entwickeln, ohne einen Bruch mit der Gesamtstruktur herbeizuführen.

Anders als Scrum gibt Kanban kein klares Rollenkonzept mit Events wie Retrospektive, Review, Planning und Sprint sowie Artefakten vor, sondern lässt die Details offen. Der Fokus liegt allerdings nicht darauf, sich auf vollkommen neues Terrain zu begeben, sondern das Bestehende an sich verändernde Rahmenbedingungen anzupassen. Während Scrum genau hier ansetzt. Scrum ist darauf ausgerichtet, ein schnelles Lernen in einem weitgehend unbekannten Terrain zu ermöglichen.

Einsatzfelder von Scrum und Kanban

Scrum gebe ich daher immer dann den Vorzug, wenn wir uns in einem „disruptiven“ Umfeld bewegen, dass wir noch genau erforschen müssen und hierfür möglichst schnell und kurze Feedbackzyklen benötigen. Dies tue ich in aller Regel nicht mit der gesamten Organisation, sondern mit einer ausgewählten Schar von Experten und Spezialisten, die ich zu einer „Expedition“ zusammenhole. Damit sich dieses Expeditionsteam auf seine Aufgabe konzentrieren kann, geben wir ihm mit dem Scrum Rahmenwerk den passenden Rahmen. Die wäre etwa der Fall, wenn wir für eine konkrete Problemstellung, in der wir noch sehr wenig bis kaum Erfahrung gesammelt haben, eine Lösung entwickeln müssen zum Beispiel die Einführung eines neuen IT-Systems wie die eAkte oder die Erstellung eines Stadtentwicklungsplans in Zusammenarbeit mit einem Bürgerrat.

Kanban setze ich hingegen dann ein, wenn im Fokus steht, die bestehende Organisationsstruktur weiterzuentwickeln, indem wir die akuten Schmerzpunkte sichtbar machen und durch Verbesserungsexperimente zu lösen beginnen. Wir reden hier von einer evolutionären, langsamen Veränderung, die darauf gerichtet ist, möglichst die Dinge stabil zu halten, die bereits gut funktionieren, und die sich darauf fokussiert, die Dinge anzupassen, die Probleme erzeugen. In aller Regel sind dies Schnittstellen in Prozessen zwischen Organisationseinheiten, Arbeitsstationen, Teams. Daher bietet sich auch die Skalierung von Kanban auf die Gesamtorganisation an. Denn auch crossfunktionale Teams haben Schnittstellen. Egal wie gut sie aufgestellt sind. Das ist allerdings ein anderes Thema für einen eigenen Blogartikel. Aus den genannten Gründen passt Kanban für mich sehr gut zum Thema Veränderungsmanagement im Zuge der Organisationsentwicklung als Hilfsmittel, genauso als Werkzeug zur Visualisierung von Prozessen und Abläufen (auf unterschiedlichen Flughöhen) mit dem Ziel, dies zu vereinfachen oder gar Informationsflüssen transparent zu machen.

Kombination aus Scrum und Kanban

Übrigens lassen sich Scrum und Kanban sehr gut kombinieren. Auf Teamebene gibt es die Möglichkeit, einzelne Elemente wie das WiP-Limit u. ä. zu übernehmen. Aber auch um mehrere Scrum-Teams zu koordinieren, bietet sich Kanban an. Diese Idee spiegelt sich übrigens in einem sehr beliebten Skalierungsrahmenwerk mit dem Namen Scaled Agile Framework (SAFe) wider. Allerdings stört mich an diesem skalierten Rahmenwerk, dass hier die Change-Management-Prinzipien von Kanban ignoriert werden und zusätzlich neue Begrifflichkeiten sowie Rollen eingeführt werden. Auch verleitet die blaupausenartige Darstellung allzu sehr zu einer unreflektierten Übertragung in den jeweiligen Organisationskontext, der meines Erachtens der Sache sehr abträglich ist. Im Prinzip ist SAFe nicht viel anderes als eine Kombination von Scrum of Scrums auf operativer Ebene und Portfolio-Kanban auf übergeordneter Flughöhe, das erfolgreich vermarktet wird. Es gibt jedoch wesentlich leichtgewichtigere Möglichkeiten wie zum Beispiel LeSS, Nexus, Scrum@Scale und das Konzept der Flight Levels bzw. die Skalierung mit Kanban. Auch hier kommt es bei der Auswahl allerdings darauf an, genau zu prüfen was erreicht werden soll ehe man sich für einen Weg entscheidet.

Resümee

Ob Scrum oder Kanban die richtige Wahl ist, hängt sehr stark vom Umfeld und dem zu erreichenden „Ziel“ ab. Auch lassen sich beide Ansätze sehr gut kombinieren. Gerade Kanban bietet über die Teamebene hinaus sehr gute Möglichkeiten in der Organisationsentwicklung. Beide Ansätze haben ihre Stärken, die sich gezielt zur Geltung bringen lassen und ergänzen sich je nach Kontext sehr gut. Erkennbar auch daran, dass in der agilen Community beide Ansätze zunehmend zusammenrücken. Unter anderem sind die Flowmetriken aus Kanban in das Modell der evidenzbasierenden Agilität eingeflossen und Scrumban-Implementation lassen sich immer häufiger beobachten.