Den Begriff Kaizen findet man immer wieder im Zusammenhang mit Scrum, meist kurz als »kontinuierlicher Verbesserungsprozess« erklärt. Wenn man das Wort in einem Meeting fallen lässt, kann man zwar ein paar Punkte im Bullshit-Bingo sammeln, meist bleibt es aber nur eine leere Worthülse. Warum ist das so? Ist Kaizen so schwierig?
Wenn man Scrum einführt, kommt man sehr schnell in eine Phase schneller und großer Veränderungen, die oft genug ebenso deutliche Verbesserungen nach sich ziehen. Nach einiger Zeit hat man jedoch einen Stand erreicht, in dem die Dinge weniger dramatische Auswirkungen haben. Viele Teams neigen dann dazu, auf dem »guten« Stand zu verharren und den Status Quo zu verwalten. Die Aufgabe des Scrum Masters wird dann die eines Beamten, der lediglich darauf achtet, dass die Zeremonien eingehalten werden. Gelegentlich spricht man dann von Kaizen, es fällt jedoch schwer, dies auch mit Leben zu füllen.
Der Grund dafür ist relativ einfach: Es liegt in der Natur des Menschen, nach großen deutlich spürbaren Verbesserungen zu streben, wenn man den Bedarf dazu spürt. So lange wir uns also nicht wirklich wohl fühlen, wollen wir die Dinge verbessern, am liebsten mit einer einzigen Maßnahme, die alles zum Besseren wendet. Daraus kann ich niemandem einen Vorwurf machen. Wir funktionieren einfach so.
Diesem Streben entspricht die Einführung von Scrum. Mit einem überschaubaren Set an neuen Regeln erzielen wir nach (meist) kurzer Zeit eine deutliche Veränderung. Dann haben wir einen Stand erreicht, mit dem wir eigentlich zufrieden sind, d.h. wir spüren keinen echten Bedarf an weiteren Verbesserungen. Folglich schläft auch das Streben danach ein. Natürlich wären wir sofort dabei, wenn uns jemand sagte, dass eine bestimmte Maßnahme erneut eine große Verbesserung mit sich brächte, aber auch das geschieht nicht. Stattdessen sind wir angehalten, stetig nach kleinen Dingen zu suchen, die wir optimieren können. Das ist sehr unbefriedigend, weil wir keine oder kaum Veränderungen spüren können. Trotzdem sollen wir damit fortfahren, weiter nach kleinen Verbesserungen zu suchen.
Jeder Scrum Master wird jetzt sofort anführen, dass die Retrospektive gerade diesem Zweck dient. Wir kommen nach jedem Sprint zusammen, um zu analysieren, was gut und was schlecht gelaufen ist, und wo wir Verbesserungen umsetzen können. Wenn wir es richtig machen, haben wir am Ende der Retro ein paar Punkte herausgearbeitet, die wir umsetzen können.
Hier begegnet uns das erste kleinere Problem: Man muss das, was man sich vorgenommen hat, auch tun, und schließlich den Effekt beobachten und bewerten. Wie oft werden am Ende der Retro unzählige mögliche Ansatzpunkte besprochen, und es ändert sich nichts, weil sich niemand zuständig fühlt, oder weil die Dinge im Sande verlaufen.
Natürlich ist hier der Scrum Master in der Pflicht, und natürlich muss sich der Scrum Master nicht immer selbst um alles kümmern. Es ist vollkommen in Ordnung, wenn ein anders Teammitglied ein Thema treibt. Ich halte es dennoch für wichtig, dass der Scrum Master den Prozess im Auge behält. Es ist seine Aufgabe, die Fortschritte zu sammeln und zu tracken. Er beginnt (oder sollte es zumindest tun) jede Retro mit einem Rückblick auf die in der letzten Retrospektive besprochen Actionables. Was hat sich seitdem getan? Wie ist der Stand der Dinge? Überspringt man diesen Punkt, verlaufen die besprochenen Veränderungen meist im Sande. Die Retro wird dann ganz schnell zu einer reinen Laberveranstaltung, in der man sich gegenseitig erzählt, wie toll man ist (was durchaus auch mal sein muss), oder in der man sich gründlich auskotzt (was auch gelegentlich sein muss, damit man danach in der gebotenen Ruhe die Dinge besprechen kann). Das ist jedoch nicht das, was wir wollen. Wir möchten eine Retrospektive, an deren Ende eine oder mehrere Maßnahmen stehen, die eine Verbesserung in unserem Vorgehen nach sich ziehen soll. Diese Maßnahmen führen wir durch und beobachten und bewerten schließlich den Effekt. Dabei ist uns vollkommen klar, dass jeder einzelne Punkt, über den wir sprechen, für sich genommen vielleicht keinen großen Effekt hat, in der Summe und über den langen Zeitraum betrachtet ergibt sich jedoch eine stetige Verbesserung.
Und genau das ist ja unser Ziel: eine stetige Verbesserung, kein einzelner großer Schritt. Wenn wir einen machen können, dann sagen wir nicht Nein, aber diese Dinge geschehen einfach nicht so oft. Irgendwann haben wir auch das Potential für die großen Schritte ausgeschöpft und müssen uns in kleineren Schritten fortbewegen. Anfänglich finden wir vielleicht noch häufiger einzelne Aktionen, die einen großen Impact haben. Wenn sich die Dinge eingespielt haben und gut funktionieren, werden die Verbesserungen immer kleiner. Gerade dann erfordert es eine große Portion Disziplin und Willen, sich die Prozesse immer wieder anzusehen, immer wieder alles zu hinterfragen und immer wieder kleine Veränderungen vorzunehmen.
Hier findet Ihr eine Übersicht von Videos zu diesem und anderen Themen
Obwohl wir das wissen, begeben wir uns dennoch immer wieder in die Falle, entweder nach dem Big Bang zu suchen, der auf einen Schlag alles besser macht, oder uns von der scheinbaren Reibungslosigkeit einlullen zu lassen. Es ist Aufgabe des Scrum Masters, diese Dinge voranzutreiben und auch immer wieder das Bewusstsein zu schärfen, dass auch eine Reihe von kleinen Schritten am Ende eine spürbare Veränderung bewirken. Kaizen oder »wir wollen immer wieder ein klein wenig besser werden« wird um Teil der Teamkultur. Wenn wir das erreicht haben, sind wir auf einem guten Weg.
Ich halte es allerdings für einen Fehler, oder besser gesagt: für ein Versäumnis, nur das Team allein zu betrachten. Wir sind als Entwicklermannschaft schlicht und ergreifend nicht allein im Unternehmen. Selbstverständlich kommen in den Retros immer mal wieder Themen auf, die auch andere Personen oder Abteilungen betreffen, aber ich denke an dieser Stelle weiter.
Wenn wir schon davon ausgehen, dass die Einführung von Scrum das gesamte Unternehmen betrifft, dann müssen wir auch davon ausgehen, dass der Gedanke einer stetigen Verbesserung und Weiterentwicklung auch das gesamte Unternehmen betreffen sollte. Selbstverständlich wird nun keiner sagen, dass das eine blöde Idee sei. Wir wollen immer besser werden. Unser Problem ist auch in diesem Falle nicht die Erkenntnis, sondern der Wille zur Umsetzung und die Notwenidgkeit der Kontinuität.
Bei Kaizen im Unternehmen verlassen wir die Grenzen von Scrum. Hier sprechen wir nicht mehr von einer Retrospektive, weil wir nicht mehr von einem Scrum-Team sprechen. Wir denken hier an Geschäftsleitung, Marketing, HR usw., die allesamt Mittel und Wege finden müssen, einen kontinuierlichen Verbesserungsprozess anzustoßen. Wir bewegen uns also in mehreren Ebenen. Zunächst einmal haben wir die einzelnen Teams, und darüber finden wir auch noch die übergeordnete Unternehmensstruktur. Die Geschäftsleitung spricht mit dem Marketing, der Entwicklung und allen anderen Abteilungen. Wenn wir alle Berührpunkte aufzeigen, ergibt sich meist ein sehr komplexes Bild, das an sich sogar schon Raum für Verbesserungen gibt.
Hier gibt es eine ganze Reihe von (mal besseren und mal schlechteren) Büchern und Publikationen zu diesem Thema, auf die ich nicht im Einzelnen eingehen möchte. Bei kurzer Recherche werden Sie viele Techniken und Möglichkeiten finden, Kaizen im Unternehmen umzusetzen. Ich möchte auf die Rolle Bezug nehmen, die der Scrum Master und das Entwicklungsteam dabei spielen können. Meiner Meinung nach können diese eine Vorreiterrolle übernehmen. Sie sollten es vielleicht sogar tun. Leisten Sie Aufklärungsarbeit, teilen Sie Ihre Erfahrungen. Andere Teams werden zwar nicht in Sprints vorgehen (zumindest in der Regel nicht), dennoch ist das Modell einer Retrospektive übertragbar. Ich habe durchaus als Scrum Master schon Retrospektiven in anderen Teams geleitet.
Diese Dinge einmalig zu machen, ist zwar eine gute Übung und kann auch durchaus interessante Ergebnisse erzielen, entspricht aber natürlich nicht dem, was wir unter Kaizen verstehen. Wir möchten einen kontinuierlichen Prozess etablieren, der immer wieder die bestehenden Abläufe und Abhängigkeiten hinterfragt. Auch dabei können wir Hilfe leisten, indem wir das Thema vorantreiben und selbstverständlich auch vorleben. Die Entwicklung kann zum Ausgangspunkt eines unternehmensweiten kontinuierlichen Verbesserungsprozesses werden. Dies erfordert jedoch Geduld und Beharrlichkeit.
