Henrik Kniberg. Vielen ist er bekannt durch seine (wirklich sehenswerten) Videos zur Spotify Engineering Culture oder zu den Auswirkungen von Work in Progress Limits auf die tägliche Arbeit. Als Autor hatte ich ihn bisher ehrlich gestanden nicht auf dem Schirm. Hier wurde ich eines Besseren belehrt und möchte meine top three learnings from Kniberg mit euch teilen.
In unseren zertifizierten Kanban Trainings verwenden wir die Microsoft XIT Studie gerne zur Veranschaulichung der Wirksamkeit und der Ausgestaltung eines Kanban Systems.
Die Studie ist informativ, empfehlenswert und kompakt, aber auch ziemlich dicht geschrieben und benötigt viel kognitive Ressourcen.
Dafür der Reward: Du verstehst danach viel über Kanban Systeme und deren Einführung. Henrik Kniberg liefert mit seinem Buch hierzu eine (aus meiner subjektiven Perspektive) wunderbare Ergänzung. Sein Buch ist in einem leichtgewichtigen Englisch gehalten und fokussiert auf die Tauglichkeit in der Praxis.
Was beide Texte gemeinsam haben: Auch bei Henrik Kniberg handelt es sich um eine Fallstudie. Der Praxisbezug ist durch die Kapitel hinweg omnipräsent und wird mit Bildern von realen Backlogs begleitet.
Also: Um was geht es?
Im Buch wird ein Projekt der schwedischen Polizei beschrieben, dessen IT-Anteile mit einem Kanban System koordiniert wurden. Der damalige Ist-Zustand oder der Punkt des Schmerzes wird im Buch wie folgt beschrieben:
„Suppose an officer catches a drunk driver. In the past, the officer would have had to capture all the information on paper, drive to the station, file a report, and then hand the case over to another investigator for further work. This would take a month or so.” (Kniberg 2011, S.3)
Das Produktziel ist ein System, welches es der schwedischen Polizei ermöglicht, alle relevanten Informationen direkt vor Ort auf dem Laptop abzurufen, zu bearbeiten und zu pflegen. So können alle angeschlossenen Behörden und Justizapparate hiermit ebenfalls weiterarbeiten.
Ein Großteil des Buches beschäftigt sich mit der Darstellung, wie das Produktziel mithilfe eines Kanban Systems umgesetzt wurde und führt dich als Leser:in an den relevantesten Punkten vorbei: Wie sah die tägliche/wöchentliche/monatliche Meetingstruktur aus? Wie sah das Kanban System aus und wie waren ihre Boards gestaltet? Wie wurden Tech Stories und übergreifende Bugs behandelt und gelöst? Wie wurden Releases geplant und ausgerollt? Wer waren die Stakehoder:innen und wie wurde getestet? Wie funktionierte kontinuierliche Verbesserung im Projekt? Wie wurden Metriken und Velocity eingesetzt?
Du merkst: Ziemlich relevante Fragen, die während eines komplexen Projektes so auftauchen.
Was hat mir an dem Buch besonders gut gefallen?
Zugegeben, ich liebe Praxisberichte und Fallstudien. Deshalb bin ich vielleicht ein bisschen gebiast (gibt es dafür ein deutsches Wort? Schreib es gerne in die Kommentare :D). Henrik Kniberg schreibt vor allem ehrlich und unprätentiös. Es ist kein geschönter Hochglanzbericht, sondern ein Praxisbuch. Das Projektteam war so geistesgegenwärtig und machte während ihrer Arbeit viele Fotos, sodass du als Leser:in zu fast allen aufgeführten Punkten reale Fotos aus dem Projektalltag sehen kannst. Auch kannst du so die getroffenen Veränderungen im Kanban System nachvollziehen.
Ich konnte als Agile Coach 3 wesentliche Punkte für meinen Alltag mitnehmen:
Aktuell begleite ich einen Kunden beim Aufbau mehrerer Kanban Systeme, welche auf einem höheren Fluglevel miteinander verbunden sind und koordiniert werden müssen. Aus dem Buch konnte ich mitnehmen, wie viel Power und Effekt in einem strukturierten Upstream stecken kann. Also wie viel Mehrwert eine koordinierte Regelung liefert wenn klar ist, wie die eigentliche Arbeit zur Bearbeitung durch einzelne Teams in das System kommt.
Learnings from Kniberg:
In einem komplexen Kanban System ist nicht nur die Reduzierung der WiP-Limits innerhalb des Downstreams relevant, sondern auch in der Limitierung der Arbeit, welche in das System gezogen wird. Hierbei kommt auch etwas zum Tragen, was mir schon in der Microsoft XIT Studie gefallen hat: Eine rudimentäre Zeichnung des Workflows schafft Transparenz und hilft Agile Coaches und vor allem arbeitenden Teams den ´Weg der Arbeit´ nachzuvollziehen.
Der zweite Goldnugget für mich als Agile Coach: Im Buch wird detailliert beschrieben, wie sich die Teams an ein gutes Gleichgewicht zwischen Tech-Stories, Bugs und Features ´heraniteriert´ wurde und welche Wirkung die eingeführten WiP-Limits (Begrenzungen) den Teams gebracht haben. Für mich als Nicht-Techi hat das viel eröffnet. Henrik Kniberg hat in seinem Buch immer wieder Dialoge zwischen zwei oder mehreren Personen abgedruckt. So konnte ich diesen Prozess und die Gedanken der Personen im Projekt nachvollziehen.
earnings from Kniberg:
Schaffe ein ausgeglichenes Verhältnis in der Bearbeitung von Features, Tech-Stories und Bugs. Hier geht es darum, eine ausgeglichene Balance zu finden. Dabei kannst auch du als Agile Coach maßgeblich helfen.
„Tech Stories are things that need to be done but that are uninteresting to the costumer, such as upgrading database, cleaning out unused code, refactoring a messy design, or catching up on test automation” (Kniberg 2011, S.39)
Im beschriebenen Projekt ist das Team folgendermaßen vorgegangen: Diese drei Kategorien bilden die verschiedenen Arbeitstypen. Alle unterliegen einer Limitierung: Next Ten Features, Next Five Tech Stories, Next Five Bugs. Diese sind committet und werden aus priorisierten Backlogs bei Bedarf nachgezogen. Das Team ist an der Priorisierung der folgenden Einträge beteiligt. So entsteht ein Pull-System, welches vergleichsweise `wenig´ Überraschungen bietet und für ein festgelegtes Intervall stabil bleibt.
Das Buch ist in zwei Teile untergliedert: 100 Seiten umfasst der ´Projektbericht´ und auf weiteren 50 Seiten werden einzelne Techniken ausgeführt und vertieft (How to reduce the Test Automation Backlog, Sizing the Backlog with Planning Poker, How to use Cause-Effect-Diagrams). Aus diesem Teil des Buches konnte ich auch etwas Feines mitnehmen: Es enthält eine detaillierte Beschreibung, wie du als Coach Cause-Effect Diagrams erstellen kannst und was diese in der Praxis des Projektes bewirkt haben. Außerdem du verstärkende Schleifen in diesen Diagrammen erkennen kannst.
Learnings from Kniberg: Ich kannte Cause-Effect Diagramme schon vor dem Buch.
Du benötigst hierfür ein großes Blatt Papier (A3 plus) und ein Team mit einem Impediment (findet man öfter in der Praxis :).
Schritt 1: Identifiziert gemeinsam das Problem („anything thats bothering you“ Kniberg 2011, S.134) und beschreibt es. Was stört euch, was beobachtet ihr?
Schritt 2: Schreibt über die Karte die Konsequenzen für die Organisation/ euer Team. Was ist der ´visible damage´ des Problems (vgl. ebd.).
Schritt 3: Schreibt unter die Karte die hypothetischen Ursprünge. Was ist eure Hypothese zur Ursache des Problems? Was noch? (Hier hilft auch die Technik der 5 Whys aus den Liberating Structures (Link)
Schritt 4: Schaut euch gemeinsam das Ergebnis an und sucht nach Beziehungsmustern und kausalen Zusammenhängen. Was hängt zusammen? Was verstärkt sich gegenseitig?
Schritt 5: Wiederholt als Team diesen Prozess ein paar Iterationen. Traut euch Sachverhalte zu vereinfachen oder auch ´auszumisten´. Was versperrt uns noch die Sicht? Wo brauchen wir Klarheit im Diagramm?
Schritt 6: Wählt eine Ursache aus und definiert Experimente, die ihr zur Lösung des Problems beitragen können. Was kann uns nachhaltig helfen? Wie und wann kontrollieren wir die Experimente und beurteilen die Wirksamkeit?
Eine reduzierte Variante dieser Methode ist auch im Retromat beschrieben: https://retromat.org/en/?id=25 Hier sind die Beispielfotos ebenfalls zu empfehlen.
Als Ergebnis kann etwas herauskommen, was ungefähr so aussieht:
Learnings from Kniberg als Agile Coach:
Über komplexe Impediments zu sprechen ist anstrengend. Eine visuelle Unterstützung durch ein Cause-Effect-Diagram (oder auch eine andere Darstellungsform) hilft dir, die Lösungsfindung zu unterstützen. Es spannt quasi den visuellen Kommunikationsrahmen auf und hilft in der Komplexität einen geteilten Fokus zu schaffen. Was bringen diese Diagramme noch? Wenn du als Team von komplexen Impediments umgeben bist, fühlt sich das gelinde gesagt ´bescheiden´ an. Im besten Fall überträgt sich die gemeinsame Aktivität der ko-kreativen Gestaltung auf den Lösungsfindungsprozess und trägt zur Überwindung der teamsubjektiven Passivität bei. Ok, das ist vielleicht ein bisschen zu ´dick´, aber daran musste ich eben denken 🙂
Mein Resumee zu den Learnings from Kniberg
Tolles Buch für alle, die in und an Kanban Systemen arbeiten. Henrik Kniberg verbindet in seiner Publikation die Essentials von Kanban mit anschaulichen Beispielen aus einem realen Projekt. Das Schöne für mich dabei: Das Produkt/ der Dienst des Projekts ist verständlich und gibt den Rahmen, um die Wirkung von Kanban als Leser:in nachzuvollziehen. Also in kurz: Wer für nen schmalen Tahler viel Wissen über Kanban in größeren Projekten bekommen will, ist mit dem Buch bestens bedient.
Lust auf mehr Kanban und Menschen für Austausch, und ein gemeinsames Denken, wie das bei dir in der Organisation funktionieren könnte? Dann schau doch mal bei unseren Angeboten im Bereich Kanban vorbei!
Quellen:
Kniberg, Henrik (2011): Lean from the Trenches. Managing Large-Scale Projects with Kanban. The Pragmatic Programmers. Texas (USA).
Anderson, David; Dumitriu, Dragos (2005): From Worst to Best in 9 Months: Implementing a Drum-Buffer-Rope Solution in Microsoft´s IT Department. http://images.itrevolution.com/images/kanbans/From_Worst_to_Best_in_9_Months_Final_1_3-aw.pdf (letzter Abruf: 11.05.22)
