Kanban – der bessere Hammer?

Kanban – der bessere Hammer

In meinem letzten Artikel https://markus-kling.de/2020/08/01/scrum-der-hammer-fur-jede-schraube/ habe ich geschrieben, dass Scrum mitunter außerhalb der Grenzen seiner sinnvollen Anwendbarkeit eingesetzt wird und habe empfohlen, zuerst über den aktuellen Standort und das angestrebte Ziel nachzudenken und danach zu entscheiden, ob der Scrum-Weg der passende ist – nach dem Motto: Das richtige Werkzeug für den richtigen Zweck.

In den Reaktionen darauf bekam ich die Anregung, diese Überlegungen auf Lean auszuweiten. Da ich Herausforderungen mag, komme ich daran nicht ganz vorbei… Ich will mich aber – wie im vorherigen Artikel – auf ein spezifisches Framework beschränken, das ich auch ganz gut kenne: Kanban.

Kanban ist Lean

Mit Lean ist es wie mit Agil – die Welt ist groß und die Geschmacksrichtungen sind vielfältig und unterschiedlich. Zu unterschiedlich für mich, um alles in einem Blogbeitrag unterbringen zu können.

Ich weiß, was Sie denken, und Sie haben Recht: „Wieso überhaupt Lean? Kanban ist doch agil?!“

In der Tat hat David Anderson versucht, Organisationen agiler zu machen, als er Kanban als Methode schuf:

„Bei meiner damaligen Arbeit […] stand ich zwei großen Herausforderungen gegenüber. Erstens: Wie kann ich mein Team vor den steigenden Ansprüchen des Managements schützen […]? Und zweitens: Wie kann ich agile Ansätze erfolgreich auf ein ganzes Unternehmen hochskalieren, ohne dabei mit den unausweichlichen Widerständen gegen Veränderungen kämpfen zu müssen?“

David J. Anderson, Kanban – Evolutionäres Change Management für IT-Organisationen, dpunkt.verlag 2011, S. 3

Um diesen Herausforderungen zu begegnen, bediente er sich bei Goldratts Engpasstheorie, Demings System of Profound Knowledge – und eben zu großen Teilen bei Lean.

Das ist für mich auch der Grund, warum Kanban als Methode eine andere Sichtweise einnimmt als die „übrigen“ agilen Ansätze: Während dort der Scope meist auf ein Team oder ein Projekt beschränkt ist, betrachten wir in Kanban – ganz im Sinne von Lean – die gesamte Wertschöpfungskette, mitunter die ganze Organisation. Das entspringt der Erkenntnis, dass man nur dann das große Ganze optimieren kann, wenn man eben nicht versucht, die einzelnen Teile für sich zu optimieren.

Lassen wir diesen Gedankengang mal so stehen – das wäre Stoff für einen weiteren Artikel – und sehen uns Andersons Aussage nochmal genau an:

Es ging ihm dabei hauptsächlich um zwei Dinge: Zum einen: die Mitarbeiter / Entwickler vor dem Management zu schützen und zum anderen: Widerstände gegen Veränderung zu vermeiden.

„I’m all about progress. It’s change I object to.“

Mark Twain

Sehen wir uns den Untertitel des Buchs nochmal genauer an: Evolutionäres Change Management für IT-Organisationen.

Kanban ist evolutionär

„Hä?“

Scrum ist ein gutes Gegenbeispiel: Scrum ist nicht evolutionär, Scrum ist revolutionär – jedenfalls dann, wenn es erstens: seinen Namen verdient (also vollständig implementiert wird) und zweitens: auf eine Organisation trifft, für die es nicht gemacht wurde (was auf die meisten Organisationen zutrifft, die ich kenne). Dann wirft es dort so einiges über den Haufen. Was dann oft auch der Grund ist, warum es entweder nicht richtig funktioniert oder nicht richtig implementiert wird. Was dann wiederum auch dazu führt, dass es nicht richtig funktioniert, sondern sich mehr wie ein Hängen und Würgen anfühlt.

Einschub: Es gibt einige die glauben, Scrum fühlt sich immer wie Hängen und Würgen an. Aus eigener Erfahrung kann ich sagen, dass das nicht stimmt: Richtig gutes Scrum fühlt sich auch richtig gut an. Hab ich schon gesehen, hab ich schon gemacht.

Warum ist Scrum so revolutionär? Ein Beispiel: Scrum kommt mit drei Rollen daher, zwei davon sind einzigartig für Scrum: Der Scrum Product Owner und der Scrum Master. Außer diesen speziellen Scrum-Rollen gibt es nur noch Entwickler. In einer Organisation, die bisher auch auf Arbeitsebene mit einer Hierarchie gearbeitet hat (Junior Entwickler, Entwickler, Senior Entwickler, Lead Entwickler, Principal Entwickler) und eine Vielzahl an Rollen verwendet hat, um Software zu entwickeln (Projektleiter, Project Management Office, Teilprojektleiter, Arbeitspaketverantwortliche, Quality Manager, Release Manager, Test Manager, Tester, Business Analyst, wer zählt die Völker, kennt die Namen…) – in so einer Organisation ist Scrum ein Schock für fast alle Beteiligten, denn zualldem hat Scrum Ähnlichkeit mit monotheistischen Religionen: „Du sollst keine anderen Rollen neben mir haben.“

Plötzlich gibt es nur noch den Product Owner, der das Sagen darüber hat, was getan wird, und das Entwicklungsteam, das jetzt nur noch aus Entwicklern besteht (ohne extra Lametta und ohne die Rollennamen Tester, Business Analyst usw. mit jeweils eigenem Lametta) und allein darüber bestimmen soll, wie etwas getan wird.

Ganz zu schweigen vom Management, das bei Scrum überhaupt nicht vorkommt.

Erst recht ganz zu schweigen von diesem Scrum Master; eine Rolle, mit der viele traditionelle Organisationen erst mal gar nichts anfangen können: Er entwickelt nicht, er testet nicht, er schreibt keine Anforderungen auf, er trifft keine Entscheidungen – was macht dieser Kerl da den ganzen Tag?

Beginne dort wo du stehst

Aber hier soll es um Kanban gehen: Kanban geht einen anderen Weg: Beginne dort wo du stehst, starte mit dem was du bisher auch getan hast und – ganz wichtig für die psychologische Sicherheit: respektiere (für den Moment) die bestehenden Rollen, Aufgaben und Titel.

Von diesem sicheren Startpunkt aus wird dann mit kleinen Schritten eine Verbesserung um die andere probiert, ohne dabei zu viel Zeit mit Analysen und Diskussion zu verbringen. Auch das ist ganz im Sinne von Lean: Man erzählt sich, als Shigeo Shingo und seine Kollegen Mitte der 1990er Jahre vom damaligen Porsche-Chef Wiedeking engagiert wurden, um Porsche aus der Krise zu helfen, haben sie sofort mit der Arbeit in der Fabrik begonnen. Nach einer Woche zeigten sich bereits die ersten Verbesserungen, während die von Porsche-Mitarbeitern ins Leben gerufene, parallel arbeitende Gruppe nicht übers Diskutieren hinausgekommen war:

„At the end of the week, the initial rundown in inventory was complete […] and the effects were both dramatic and completely visible. The Porsche internal teams, meanwhile, had made hardly any progress on their parallel tasks and concluded that they should simply join the next consultant-led kaizen.“

Womack & Jones, Lean Thinking, Verlag Simon & Schuster, 2. Ausgabe 2003, S. 203

Es ist meiner bescheidenen Meinung nach dieser evolutionäre Ansatz, der Kanban wesentlich universeller einsetzbar macht als Scrum.

Oder – um es in Lean Lingo auszudrücken: Kanban ist Kaizen, man kann es häufig und immer und immer wieder tun. Viele kleine Schritte führen über kurz oder lang auch zu großen Veränderungen. Und weil die Schritte so klein sind, sind sie leicht wieder rückgängig zu machen, falls einer mal in die falsche Richtung geführt hat. Damit ist Kanban auch mit wesentlich weniger Risiko verbunden als Scrum.

Scrum dagegen ist Kaikaku – eine einzelne große Veränderung der Prozesse. Manchmal notwendig, aber mit großen Risiken und Nebenwirkungen.

Ich weiß, was Sie denken, und Sie haben schon wieder Recht: „Aber ich kann auch Scrum langsam und nach und nach einführen.“

Ja, das geht. Aber ich kann mir auch ein Loch ins Knie bohren und dann mit einer Schraube den Schmerz regulieren. Das geht auch – und ist in etwa genauso sinnvoll. Denn während Kanban ein Werkzeug für Change Management ist, haben wir es bei Scrum mit einem Prozessrahmenwerk zu tun.

„Hä?“

Wenn ich Scrum einführe, führe ich damit in der Regel einen komplett neuen Prozess ein – neue Rollen, neue Artefakte, neue Aktivitäten. Mache ich das langsam und sukzessive, dann habe ich ein Flickenwerk aus alten und neuen Elementen, die in der Regel nicht kompatibel zueinander sind. Wie wollte ich zum Beispiel langsam von einem phasenorientierten Ansatz mit Lasten- und Pflichtenheft umsteigen auf einen iterativ-inkrementellen Ansatz mit Product Backlog?

Leider wird es trotzdem immer wieder versucht. In den letzten Jahren stoße ich immer wieder und in unterschiedlichen Umfeldern auf Leute, die sich darüber beschweren, dass Scrum so viel Overhead mit sich bringe und es einfach zu viele Meetings gäbe.

Zuerst konnte ich mir keinen Reim darauf machen, denn Scrum an sich ist relativ schlank und bringt – alles zusammen genommen – nur max. 20% Overhead mit sich, sprich: Maximal 20% der Zeit wird mit den Scrum Ereignissen verbracht, mindestens 80% der Zeit können alle Beteiligten in Ruhe am Produkt arbeiten.

Als die Vorkommen sich häuften, begann ich stärker nachzufragen. Nach kurzer Zeit war ein Muster zu erkennen: In all diesen Organisationen war Scrum „so nach und nach“ eingeführt worden. Was war genau passiert? Man hatte die „alten“ Termine und Meetings nicht durch die „neuen“ Scrum Ereignisse ersetzt, sondern die Scrum Ereignisse zusätzlich eingeführt. Und sich dann gewundert und beklagt.

Bei Kanban ist das anders. Kanban ist kein Prozessrahmenwerk, das schon viele Eckpfeiler mitbringt und nur noch etwas ausgestaltet (implementiert) werden muss.

Kanban ist Change Management

Kanban kommt nicht mit einem Prozessrahmen wie Scrum, sondern Kanban wird auf einen bestehenden Prozess angewendet. Es ist ein Werkzeug zum Change Management.

Deshalb ist die Frage „Scrum oder Kanban?“ in etwa so zielführend wie die Frage „Suppe oder Löffel?“. Denn so wie ich meine Suppe mit dem Löffel essen kann, kann ich Kanban auf eine Scrum Implementierung anwenden.

Laut den Machern von Scrum ist das Ergebnis dann zwar kein Scrum mehr (die ersten, die das gemacht haben, haben den Begriff „Scrumban“ geprägt), aber wen kümmert das, wenn das Ergebnis besser passt?

Oder, um es anders auszudrücken: Wenn ich Scrum richtig implementiere, dann bekomme ich Scrum. Ob diese Lösung zum Problem passt, ob dadurch das Problem gelöst wird, ist oft die Frage.

Wende ich Kanban richtig an, dann bekomme ich nicht Kanban, sondern ich bekomme den Prozess, der zum Problem passt, also das Problem löst.

Ist das nicht tröstlich? Selbst wenn ich mich mit Scrum in eine Ecke gepinselt habe, kann ich Kanban dazu verwenden, dort wieder herauszukommen. Es geht vielleicht langsam und ist danach auch kein Scrum mehr, aber wenn Scrum von vornherein nicht gepasst hat, ist das kein Bug, sondern ein Feature.

Wo ist der Haken?

Ich weiß, was Sie denken: „Das ist doch alles zu schön, um wahr zu sein! Wo ist der Haken an der Sache?“

Und Sie haben Recht: Wo Licht ist, ist auch Schatten und jede Medaille hat zwei Seiten. So gibt es auch Situationen, in denen Kanban nicht das Mittel der Wahl ist.

Das ist immer dann der Fall, wenn die notwendigen Voraussetzungen nicht erfüllt sind.

„Schönen Gruß von Captain Obvious, Schlauberger. Was sind die Voraussetzungen?“

Bereitschaft zur Zusammenarbeit

Die Voraussetzung: Alle an der Wertschöpfungskette beteiligten Einheiten müssen mitspielen. Jede Kette ist nur so stark wie ihr schwächstes Glied.

Was meine ich mit „mitspielen“? Mitspielen bedeutet nicht, „bei dem neuen Spiel mit Namen Kanban“ mitzuspielen. Im Idealfall belästige ich die Organisation ohnehin mit so wenigen neuen Begriffen wie möglich. Mitspielen bedeutet für mich in diesem Fall: Zusammenarbeiten. Wenn ich andere Organisationseinheiten, die auch an der Wertschöpfungskette beteiligt sind, nicht zur Zusammenarbeit bewegen kann, dann werde ich auch mit Kanban keine Verbesserung erzielen.

In diesem Zusammenhang wird mir immer wieder klar, dass ein Leerzeichen einen bedeutenden Unterschied machen kann: Zusammen arbeiten ist nicht gleichbedeutend mit zusammenarbeiten. Wir brauchen hier die Version ohne Leerzeichen.

„Okay, so weit, so gut. Zusammenarbeit, ein Nobrainer. Was noch?“

Tja, das ist es aus meiner Sicht. Ich meine, natürlich braucht es die grundsätzliche Bereitschaft zu Veränderungen in einer Organisation. Wenn eine Organisation auch kleine und kleinste Veränderungen ablehnt, kommt sie auch mit Kanban nicht weiter. Andererseits denkt sie dann aber wahrscheinlich auch nicht darüber nach…

Fallstudie: Heiliges Römisches Reich der Kostenrechnung

Und ganz nebenbei, so ein Nobrainer ist das auch nicht. Ich hatte einmal in einer Organisation zu tun, in der die interne Kostenrechnung die Zusammenarbeit entlang von Wertschöpfungsketten wirkungsvoll verhindert hat. Natürlich war das nicht beabsichtigt: Der Gedanke, der dahinter stand, war der: Wenn ich alle meine Kostenstellen optimiere, dann bekomme ich die optimalen (= niedrigsten) Kosten für meine Gesamtorganisation.

Was dabei heraus kam, war ungefähr so etwas wie das Heilige Römische Reich Deutscher Nation der Kostenrechnung: In etwa 300 kleine Fürstentümer (Kostenstellen), deren 300 kleine Fürsten jeder erstmal nach sich selber und seinem Fürstentum schaute und danach, möglichst gut dazustehen. Jede Menge Energie wurde aufgewendet, die eigene Kostenstelle „sauber“ zu halten und nach Wegen gesucht, unliebsame Kosten auf andere Kostenstellen umzubuchen. Energie, die für die Wertschöpfung verloren war.

Dabei mache ich den Fürsten keinen Vorwurf: Der Kaiser hatte genau das befohlen, weil er dachte, dabei käme für das Reich das beste Ergebnis heraus. Das Gegenteil war der Fall: Auf dem Weg durch das Reich wurden (wie im echten Heiligen Römischen Reich auch) die Waren an jeder Grenze einem Zoll unterworfen, was den Weg langsam und teuer machte. Langsamer und teurer als in den umliegenden Nationalstaaten – und der Kaiser wundert sich, dass die anderen schneller und besser sind…

In diesem Fall hätte der Einsatz von Kanban in einer oder mehreren Wertschöpfungsketten nichts gebracht. Man hätte zuerst die Kostenrechnung ändern müssen, denn diese liegt querschnittlich über allem drüber. Das aber ist eine Herkulesaufgabe und hätte vermutlich einen gewonnenen Krieg und einen Bismarck gebraucht – genug mit den Metaphern jetzt.

Fazit

Kanban ist ein Werkzeug für Change Management. Kanban wird auf bestehende Prozesse angewendet und verändert sie in kleinen Schritten so lange bis der passende Prozess daraus geworden ist. Einzige Voraussetzung: Bereitschaft zur Zusammenarbeit innerhalb der Organisation.

Damit ist Kanban universeller einsetzbar als ein Prozessrahmenwerk wie zum Beispiel Scrum, denn es setzt eine Ebene höher an.

Im Laufe der Jahre wurde aus dem zunächst kleinen und einfachen Ansatz eine ausgefeilte Methode, die – natürlich – inzwischen auch über eine Menge an Zertifizierungen verfügt und ein eigenes Reifegradmodell entwickelt hat – das Kanban Maturity Model. Aber das hebe ich mir für später auf…

P.S.: Noch einen schönen Gruß von Captain Obvious: Auch wenn Kanban fast immer verwendet werden kann, ist es unerlässlich, dass ich a) weiß wo ich stehe („beginne dort wo du stehst“, remember?) und b) weiß wo ich hin will, bevor ich mich auf den Weg mache. Das kann mir Kanban auch nicht ersparen.

„Wer nicht weiß, in welchen Hafen er segeln will, der findet auch keinen günstigen Wind.“

Lucius Annaeus Seneca
Veröffentlicht in Blog

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.