Leitfaden zum Aufsetzen eines Kanban

E-T-A setzt seit Jahren Lean in der Produktion ein – und erweitert ihr Können um Agilität. Im Rahmen unserer gemeinsamen Arbeit bei der agilen Transformation treffen sich E-T-A und wibas Kollegen, um gemeinsam an der Etablierung agiler Techniken und agilen Denkens zu arbeiten. Gestern saßen Stefanie und Katja von E-T-A mit drei wibas Kollegen Rafael, Daniel und Malte zusammen. Unsere Fragestellung war: „Wie setzen wir Arbeit mit dem Kanban Framework in einem Team auf?“ Dafür haben wir einen Coach-Leitfaden entwickelt, den wir hier mit euch teilen. Der Leitfaden basiert auf STATIK: System Thinking Approach to Introducing Kanban.

Die Aufgabe: mehr als ein Board

Als wir die Zielsetzung vom Workshop formulieren (wie man das als guter Moderator so macht) erkennen wir schnell, dass es nicht einfach nur um ein Board mit Karten geht, sondern um das Umsetzen vom Kanban Framework.

Warum ist Kanban mehr als ein ­- mit bunten Zettelchen beklebtes – Board? Weil Kanban Prinzipien, Rollen und Meetings definiert, die Kanban erst zu der nützlichen Methode machen. Das Folgende ist also eine Anleitung, wie ihr mit dem Kanban Framework in einem Team beginnen könnt.

Im Sinne der Prinzipien „Evolutionäre Veränderungen“ und „Beginne mit dem, was das Team gerade tut“ geht es bei unserem Workshop nicht darum, Kanban in seiner vollen Schönheit umzusetzen, sondern zu beginnen. Es kann also sein, dass wir manche Dinge vom Kanban Framework am Anfang weglassen (ein „Proto-Kanban“).

Wer kommt?

Zum Workshop laden wir das Team, das die Arbeit macht, ein. Wir kommen als Flow Master, d.h. als als ein Agility Coach der Kanban und Facilitation kann. Als Flow Master unterstützen wir moderativ und bringen Techniken wie z.B. die Boardgestaltung ein. Oder kurz: Wir als Flow Master moderieren, das Team gestaltet sein Kanban.

Die Schritte im Workshop

Unsere grundsätzliche Idee vom Workshop ist: Zuerst versteht das Team den Wertstrom mit seinen Regeln und Grenzen. Dann visualisiert das Team diesen durch ein Board. Schließlich etabliert es die Rollen und Ereignisse. Susanne, Agile Coach bei E-T-A, weiß warum: „Wenn der Agile Coach das Board selbst entwickelt oder gar pflegt, dann arbeitet das Team damit nicht.“ Wir Coaches nicken. „Klar, ist ja dann dein Board – und nicht das vom Team.“

Hier sind die Schritte unseres Moderationsplans:

1. Wir fragen die Workshopteilnehmer nach Ihrer Erfahrung mit Kanban. Die Abfrage hilft uns als Moderatoren zu verstehen, wie viele Erklärungen wir unterwegs einbauen müssen. Unser Motto ist: Erklärungen dann, wenn sie benötigt werden. Damit sparen wir uns eine große Kanban-Erklärung am Anfang.
2. Wir lassen das Team den Wert beschreiben, den Sie durch ihre Arbeit dem Kunden liefern. Dieses Verständnis ist wichtig, damit wir den Prozess auf diesen Nutzen ausausrichten können.
3. Wir lassen das Team typische Kundenanfragen So verstehen wir die Wünsche der Kunden besser. Außerdem haben wir ein paar Beispiele, um in einem späteren Schritt (siehe Punkt 9) das Kanban ausprobieren zu können.
4. Das Team macht eine kurze und knackige Bestandsaufnahme von seiner Arbeit mit den beiden Fragen: Was läuft gut? Wo sieht das Team Verbesserungsbedarf? Das gibt allen ein Gefühl dafür „wo wir beginnen“.
5. Wir lassen das Team den Ablauf vom Arbeitsfluss Hierfür geht das Team Arbeitsschritt für Arbeitsschritt durch und modelliert den Ablauf. Dafür nutzen wir Karten, bei denen jede Karte für einen Arbeitsschritt steht. So entsteht der Arbeitsfluss dynamisch, und er kann einfach erweitert und umgebaut werden.
   Wir unterstützen als Coaches das Team mit Fragen, wie z.B.:

• • Was sind das für Schritte die Ihr als Arbeit macht?
  • Was ist das Ergebnis vom Schritt?
  • Wo kommt die Arbeit her?
  • Was ist das für Arbeit?
  • Was macht einen guten Ablauf aus?
  • Wie passiert bei euch Umsetzung von Arbeit?
  • Wie wählt ihr Arbeit aus?

6. Auf Basis des obigen Arbeitsablaufs erstellt das Team sein erstes Board. Hierfür klären wir zuerst die Frage, ob der Arbeitsfluss immer der gleiche ist, oder ob die Aufgaben ganz unterschiedlich sind. Bei immer gleichen Tätigkeiten wird jeder Arbeitsschritt als eine Spalte im Kanban dargestellt (jede Spalte hat die Unter-Spalten „in Arbeit“ und „fertig“). Bei sehr unterschiedlichen Tätigkeiten arbeiten wir mit einer individuellen Zerlegung der Arbeitsaufträge in Aufgaben.
7. Wir lassen das Team die Grenzen paralleler Arbeit bestimmen – das sind die sogenannten „Work-in-Progress-Limits“ bzw. „WIP-Limits“. Wenn wir Aufgaben, an denen wir arbeiten, auf eine festgelegte Anzahl begrenzen, d.h. die Menge paralleler Arbeit limitieren, eliminieren wir Wartezeiten und verkürzen die Durchlaufzeit von Arbeit. Wir werden effizienter. Wichtig ist für gute WIP-Limits, dass das Team mit initialen Grenzen beginnt, Durchlaufzeiten in der weiteren Arbeit beobachtet, und dann die WIP-Limits so anpasst, dass die Arbeit nicht an irgendeiner Stelle staut.
8. Wir lassen das Team seine Regeln im Ablauf von Arbeit formulieren. Dazu fragen wir:
   1. Was bedeutet es, wenn ein Schritt fertig ist? Gibt es dazu Kriterien? Das ist dann so etwas wie eine „Definition von Fertig“ für die jeweiligen Fertig Spalten (oder ggf. nur für die letzte „Fertig“ Spalte).
   2. Wir fragen das Team, wie es seine Arbeit aus der Warteschlange (der ersten Spalte im Kanban) auswählt. Gibt es hierfür Regeln? Wie ist die Warteschlange geordnet? Das Ergebnis an dieser Stelle sind häufig Regeln zur Ordnung bzw. Priorisierung der Arbeitsaufträge.
   3. Gibt es andere Regeln, die bei der Arbeit wichtig sind?
   4. Diese Regeln schreibt das Team auf große PosIts (wir nehmen häufig A5) und hängt sie über dem Board auf. Regeln zur Definition von „Fertig“ sind z.B. über der jeweiligen „Fertig“ Spalte sinnvoll.
9. Wir testen das Kanban Board mit typischen Anfragen aus Schritt drei. Das heißt: wir lassen eine Anfrage durchlaufen und simulieren die Arbeit dazu. Ggf. passen wir das Board noch an.
10. Wenn wir Zeit haben könnten wir an dieser Stelle eine Simulation von Kanban einbauen, damit die Teilnehmer erfahren, wie Kanban funktioniert. Wir nehmen dafür z.B. das Okaloha Flow Game oder das TWIG-Game. Eine solche Simulation hilft, dem Kanban einen Verständnis-Unterbau zu schaffen, der sonst einige Zyklen im echten Leben benötigen würde.
11. Wir klären mit dem Team die Rollen des Kanban-Frameworks (Flow Master und Service Request Manager/Product Owner) und wir legen fest, wer diese Aufgaben übernimmt. Zumindest für die nächste Zeit.
12. Wir klären mit dem Team, was die Kadenzen der Rückkopplungsschleifen sind. Mit „Kadenz“ ist gemeint: wie häufig machen wir welches Meeting. Besonders wichtig finden wir das Kanban Meeting („Standup“) und das Service Delivery Review. Eigentlich sind auch das Replenishment Meeting und das Delivery Planungsmeeting wichtig, aber das können wir auch ggf. in einem späteren Schritt einführen. Bei allen Meetings legen wir fest, wann und wie häufig es stattfindet (und natürlich: wer kommt und wie lange es dauert).
13. Das Team füllt das Board mit dem derzeitigen Arbeitsstatus.
14. Wir fragen, was das Team noch braucht, um anfangen zu können.

Diese Agenda selbst haben wir *natürlich* auf einem Kanban Board. Zum einen, weil wir Kanban vorleben wollen, aber auch weil sich die Agenda während des Tages ändert und wir so gut reagieren können.

Für einen solchen Workshop brauchen wir mindestens vier Stunden – ein ganzer Tag wäre besser.

Gelogen. Das war gar keine Anleitung.

Wir haben kurz umrissen, wie man Kanban mit einem Team aufsetzen kann. Das ist natürlich nur ein kleiner Teil der Wahrheit. Im Detail behandeln wir das Aufsetzen von Kanban in unserer offiziellen Schulung KMP I. Dort erfahrt ihr den genauen Prozess von Kanban, die Prinzipien im Detail, Facilitations-Techniken und Board-Gestaltungsvarianten.

Autorenteam

Das Autorenteam: Stefanie Stampfer und Katja Kiel von E-T-A mit den drei wibas Kollegen Rafael Kasprzak, Daniel Schauperl und Malte Foegen. Wenn ihr noch Fragen habt, stellt sie hier im Blog – wir antworten gerne. Oder ruft uns an: 06151 – 50 33 49 0.