Kanban in der IT

Wie kommt Bewegung in den Kopf?
oder: „Immer auf dem letzten Stand des Irrtums“

Herr Leopold, wenn Kanban in der IT zum ersten Mal aufs Tapet kommt – überwiegt dann Skepsis oder Neugier?

Klaus Leopold: Beides begegnet uns: Sowohl Skepsis als auch Neugier. Aber es lässt sich ein Muster erkennen, wo welche Stimmung dominiert. Wenn ich in ein junges, kleines Unternehmen komme, treffe ich auf mehr Neugier. In großen Konzern hingegen überwiegt die Skepsis. Egal, in welcher Branche man da unterwegs ist.

Woran kann das liegen?
Große wie kleine Unternehmen sind auf der Suche nach dem nächsten großen Ding. Insoweit herrscht Neugierde auf beiden Seiten. Interessanterweise orientieren sich die Ziele in großen Unternehmen aber eher an den Kosten, während die Kleinen nach Umsatzquellen suchen. Die Suche nach Umsatz macht hungrig, die Suche nach Einsparungen lähmt. Außerdem haben die Leute in etablierten Unternehmen schon sehr viel gesehen. Da herrscht oft so eine Stimmung: Ach, wieder so eine Sau, die durchs Dorf gejagt wird. Bei kleineren Unternehmen ist das konträr.

Welche Motivation steckt denn dahinter, sich mit Kanban zu beschäftigen?
Das ist ziemlich verschieden. Viele hoffen, dass ihnen die neue Methode helfen kann, ihre time-to-market zu verkürzen, also vorne dabei zu sein. Sie wollen durch neue Arbeitswelten konkurrenzfähig bleiben. Und dann gibt es Unternehmen, die Kanban machen wollen, weil man eben Kanban macht. Agilität hat gerade einen hohen Coolness-Faktor. Spotify zum Beispiel wird gerne kopiert. Die Company gilt als cool und ist im Moment das Vorzeigeunternehmen schlechthin, wenn es um Agilität geht. Da heißt es dann nur: Wir müssen so sein wie die.

Aber wäre das schlimm?
Nur en vogue sein zu wollen, reicht nicht. Nur zu kopieren, erst recht nicht. Nochmal das Beispiel Spotify: Dort gibt es keine Teams oder Abteilungen, sondern Squads oder Tribes. Und jetzt gibt es Unternehmen, die bilden Squads und Tribes und denken, sie sind auch so erfolgreich wie Spotify. Na guten Morgen, das funktioniert nicht.

Und wie funktioniert es dann?
Zunächst: Es ist ein Irrtum zu glauben, die Praktik sei entscheidend. Das Mindset ist es. Was Unternehmen wie Spotify oder Toyota ausmacht, ist nicht das, was sie tun. Was sie ausmacht, ist eine Kultur, in der sie herausfinden können, was sie brauchen, um besser zu werden. Das ist ein Unterschied.

Also muss ich die Kultur ändern …?
Ja genau, und wie wir wissen: Kultur ist breit, Kultur ist tief und Kultur ist überhaupt nicht fassbar. Ich besitze kein Patentrezept, habe aber gerade in großen Unternehmen gute Erfahrungen mit dem evolutionären Ansatz gemacht. Ein revolutionäres Vorgehen hingegen funktioniert ziemlich gut, wenn der Karren im Dreck steckt und sich was bewegen muss.

Gleich, ob evolutionär oder revolutionär, man muss starten. Wie macht man das am besten?
Indem man sich Gedanken macht, mit anderen diskutiert und Klarheit über die gewünschten Ziele bekommt. Wenn mich jemand anruft und sagt, er will Kanban machen, frage ich zunächst nach dem Grund. Denn Kanban ist ein Mittel zum Zweck und nicht das Ziel. Kanban oder andere agile Methoden sind ja schon eine Lösung. Es geht aber zunächst darum, Probleme zu klären. Sie stehen im Zentrum und nicht Kanban. Ein anderes häufig auftretendes Missverständnis ist der Glaube, Kanban soll die Teamarbeit verbessern.

Ach, darum geht es gar nicht?
Kanban ist keine Teammethode. Als Praktik funktioniert sie sehr wohl in Teams, sie soll aber über Teams hinweg laufen. Es bringt aber nichts, wenn sich die Performance eines Teams verbessert. Null. Denn das Ziel lautet, den Wert zum Kunden zu optimieren. Zum Beispiel eine bessere Dienstleistung zu bringen. Man muss sich einfach fragen: Kann eine Team den Service zum Kunden verbessern? In vielen Fällen lautet die Antwort, sofern sie ehrlich ist, nein. Gerade in großen Unternehmen sind es nicht ein, sondern eher zwölf oder mehr Teams, die an einem Ergebnis arbeiten. Und schließlich will keiner die Einzelglieder eines Systems optimieren, sondern das gesamte System. Mit anderen Worten, wir brauchen nicht nur agile Teams, sondern agile Interaktionen zwischen den Teams.

Womit wir immer noch am Anfang stehen. Ein Team allein soll es nicht richten, was also empfehlen Sie, wenn jemand mit Kanban arbeiten möchte?
Schon die Entscheidung, dass Kanban gemacht wird, würde ich auf mehrere Schultern verteilen. Dann habe ich den ersten Schulterschluss. Wer Kanban einführen möchte, soll sich Verbündete aus anderen Teams suchen. Und aus anderen Hierarchieebenen. Denn es ist weder eine gute Idee, Entscheidungen allein vom Management treffen zu lassen, noch wenn nur die Mitarbeiter entscheiden. Gleiches gilt für die Cross-Funktionalität, wenn ich die Einführung über Teams hinweg machen will. Für IT-Organisationen heißt das: Nicht nur die Entwickler, sondern auch die Business Analysten, oder der Support sollten bei den Entscheidungen vertreten sein.

Angenommen, dieser Schulterschluss ist geschafft. Eines der Prinzipien von Kanban lautet: Start where you are. Was heißt das konkret?
Dahinter steht erst einmal, dass prinzipiell keine Rollen oder Prozesse oder Jobtitel geändert werden. Wo sich das System befindet, ist den Leuten meistens klar. Zum Beispiel bei der Frage nach der Verantwortung: Es gibt ja in der Regel einen Projektmanager oder Gruppenleiter. Die sind einfach da – und sie bleiben auch.

Wenn es hingegen um Prozesse geht, ist oft nur viel vermeintliche Klarheit da. Hier helfen Workshops, damit die Leute erkennen, wie ihre Arbeit und die Prozesse im Unternehmen funktionieren. Die Leute finden also ein gemeinsames Verständnis. Kanban ist ein Mittel zum Zweck, um Arbeit sichtbar zu machen, zu steuern und zu verbessern – und zwar nicht in Form eines Prozessdokuments, das in irgendeiner Schublade verstaubt.

Die gelebte Arbeitsweise soll explizit gemacht werden. Das ist mit “start where you are” gemeint.

Die Kanban-Tafel ist also die Visualisierung der Arbeit?
Ja. Das Board zeigt den gelebten Prozess. Die Sichtbarkeit ist aber nur ein Mittel zum Zweck. Ziel ist es, mit Hilfe der Sichtbarkeit, die Arbeitsabläufe zu verbessern und optimal zu managen.

Wir machen also einen Workshop, einigen uns auf die tatsächlichen Prozesse und Aufgaben und bringen sie an die Wand. Fertig?
Das wäre schön, aber so einfach ist es nicht. Das entwickelte Kanban-System ist immer der letzte Stand des Irrtums, auf dem man sich befindet. Dann kommt die Realiät und die weiß immer alles besser als wir. Wichtig ist, sich dessen bewusst zu sein und von Anfang an die Angst zu nehmen, etwas falsch zu machen. Finden wir uns mit dem Ausgedachten nicht oder nicht vollständig in der Realität wieder, dann ändern wir halt das System. So what? Wir verändern das Limit von WIP, nennen den Prozessschritt um, nennen die Prozesse anders, fügen Spalten ins Board ein und so weiter. Das ist genau das lebende Moment agiler Methoden und das muss von Anfang an klar sein.

Aber ist dann nicht endlich mal Ruhe – der Mensch mag doch nicht jeden Tag aufs Neue überlegen und dauernd was verändern?
Ruhe ist, wenn man stirbt. Ernsthaft: Es hört nie auf. Alles ändert sich jeden Tag und zwar für immer. Ich verstehe die Sehnsucht nach Stabilität, auch wenn ich gar nicht so genau weiß, wo die herkommt, aber nichts ist stabil! Wir müssen akzeptieren, dass das auch in der Arbeitswelt gilt. Es gibt eine Stelle bei „Alice im Wunderland“. Da sagt der Hase: „Hier muss man aber sehr schnell laufen, damit man an der Stelle bleibt“. Damit beschreibt er genau die Realität, in der wir uns befinden.