Offener Abend zu Kanban – 48. Limited WIP Society CGN

Beim 48. Treffen der Limited WIP Society Cologne haben wir in einer sehr gelungenen Kombination aus Lean Coffee und Fish-Bowl die folgenden sechs Themen jeweils zwischen 10 und 20 Minuten intensiv diskutiert:

  • Kommunikation im Kanban Umfeld
  • Kanban auf CxO Ebene etablieren
  • Kanban und Ticket-Systeme
  • Woran scheitern Kanban-Initiativen
  • Agiles Releasemanagement
  • Portfolio-Management mit Kanban

Im Folgenden geben wir exemplarisch zu drei der sechs Themen die Erkenntnisse aus unserer Diskussion in der Fish-Bowl wieder.

Kommunikation im Kanban Umfeld

Neben der Kanbanmethode mit ihren Praktiken und Prinzipien sind für eine erfolgreiche Einführung und Verwendung von Kanban auch das richtige Mindset und eine gute Kommunikation wichtig.

In größeren Teams erfordert dies Werkzeuge für die Moderation von größeren Gruppen. Insbesondere müssen dabei auch Meinungen ausgehandelt und Entscheidungen getroffen werden. Es gibt adäquate Werkzeuge und Methoden. Sie sind aber häufig unbekannt und werden direkt durch die Kanbanmethode auch nicht vorgegeben.

Die Kommunikation im Team erfolgt häufig über viele Kanäle (Chat, Mail, Telefon, …). Regeln und Nutzungshinweise erleichtern und strukturieren die Kommunikation.

Neben diesen eher technisch oder methodischen Unterstützung für gute Kommunikation sollte auch nicht vernachlässigt werden eine Basis im Sinne eines gemeinsamen Verständnisses zu schaffen. Hierzu können z. B. spezielle Events neben dem Tagesgeschäft dienen, die ein Kennenlernen der Beteiligten und einen Austausch ermöglichen.

Kanban auf CxO Ebene etablieren

Für die Einführung von Kanban sollte auch das Topmanagement in einer Firma einbezogen werden damit es die Initiative unterstützt. Wie kann Kanban den CxOs einer Firma nahe gebracht werden, wenn sie nicht direkt in den Kanbanteams mitwirken.

Eine Chance kann das Einführen von kleinen Kanbanexperimenten, wie z. B. Personalkanban oder anderer Protokanbanvarianten, bieten, um die Arbeit einen CxOs oder der CxOs untereinander zu visualisieren und zu strukturieren. Vorliegende Organisationsdefizite können so behoben werden und den CxOs ein direkter Nutzen vermittelt werden.

Interessant dürften für die CxO Ebene auch die auf Teamebene erhobenen Kanbanmetriken sein. Gelingt es diese Metriken zu erheben und den CxOs regelmäßig darzustellen ist dies ein großer Schritt in Richtung der Einbindung der CxOs.

Ein weiterer Ansatz kann die Verdeutlichung der Wirksamkeit des Pull-Prinzips zum Beispiel über Gedankenexperimente sein. Aber Achtung: Pull setzt dann bereits ein gewisses Mindset voraus, dass sich vielleicht von der bisherigen Kultur einer Aufgabenzuweisung von Oben nach Unten unterscheidet.

Woran scheitern Kanban-Initiativen

Es wird häufig nur von erfolgreichen Kanbaninitiativen berichtet. Es wird bestimmt aber auch viele Misserfolge geben. Woran scheitern Kanbaninitiativen?

Kanban erfordert ein hohes Maß an Disziplin. Prozesse müssen eingehalten werden. Regeln müssen befolgt werden. WIP Limits müssen beachtet werden. Eine Fish-Bowl, wie wir sie heute durchgeführt haben, funktioniert, weil sich alle an die Regeln halten. Halten sich zu viele, z. B. weil sie sich dies aufgrund ihrer Position im Unternehmen erlauben können, nicht an die Regeln, funktioniert das System nicht mehr. Vorgesetzte und Manager kommen ggf. mit dem Pull-Prinzip nicht klar, da sie gewohnt sind Aufgaben zu verteilen. Insbesondere der Schritt WIP zu limitieren erfordert eine sehr hohe Disziplin, da schnell eine Ausnahme gemacht wird, um doch noch etwas für einen wichtigen Stakeholder zu tun.

Ein weitere Ursache für das Scheitern kann in kulturellen Problemen liegen. Fehlendes Vertrauen oder nicht vorhandene oder wenig ausgeprägte Fehlerkultur führen zur Angst vor Transparenz. Man möchte der Realität, die das Kanbanboard abbildet,  nicht ins Auge sehen. Sichtbarmachen des Status Quos kann ggf. einer Revolution gleichkommen. Somit sind Kanbanboards häufig sehr disruptiv. Im Projektkontext wird häufig sehr politisch berichtet. Dies beißt sich aber mit dem Ansatz des „Start with what you do now“ und der Visualisierung.

Ein sehr grundsätzliches Problem kann entstehen, wenn die Einführung des Kanbansystems für einen nicht wirklich wichtigen Prozess/Service erfolgt. In dem Fall fehlt die Dringlichkeit für die notwendigen Änderungen und bei kleineren Problemen verfällt man wieder in alte Verhaltensmuster.

Die fehlende Einbindung in „echtes Changemangement“ und mangelndes Methodenwissen stellen zwei weitere mögliche Ursachen für das Scheitern einer Kanbaninitiative dar.

Alles letzter Punkt wurde noch festgestellt, dass Kanban keine Allzweckwaffe ist. Wird Kanban im falschen Kontext angewendet, kann man nur scheitern. Kanban wird in dem Zusammenhang auch fälschlicher Weise manchmal als Prozess und nicht als Methode zur Prozessverbesserung verstanden.

Zu den drei weiteren Themen hier nur kurz in Stichpunkten – und insbesondere als Gedankenstütze für diejenigen, die vor Ort waren – die diskutierten Aspekte des Abends.

Kanban und Ticket-Systeme

  • Funktioniert manchmal: Ticketsystem wird überführt in physische Karten
  • Multi-Tier Kanban
  • Kanban als Loadbalancer an den Übergängen
  • Vorteil von Trello: Vereinbarungen müssen im Team getroffen werden
  • Ähnliches Verfahren:
    • Skalierung „von oben nach unten“
    • Medienbrüche an natürlichen Grenzen helfen sogar dabei die anstehenden Prozessentscheidungen explizit zu machen.

Agiles Releasemanagement

  • Gibt es das Überhaupt?
  • Kanban vs. Drum-Buffer-Rope
  • Im Prinzip ja …
    • Was ist ein Release?
    • Agile Prinzipien – z.B. grober Einführungstermin
    • Continuous Delivery => dann wird Release zu Anschalten von Features
  • Geht das im Kontrollierten Umfeld?
  • Stacey-Matrix
    • Man beachte, dass agile Methoden insbesondere im komplexen Umfeld zuhause sind.
    • Für komplizierte Probleme sind andere Methoden eventuell sinnvoller
    • Im Scrum Umfeld: Möglichst viele Feedback-Mechanismen einbauen
  • Agil heißt nicht nur Wochen – man beachte, woher man kommt, und welche Zeiten üblich sind. z.B. Autositze in einem halben Jahr zu bauen kann revolutionär schnell sein.

Portfolio-Management mit Kanban

  • Ja, sollte man machen
    • Visualisierung fehlt
    • Projektboard macht z.B. Vorbereitung sichtbar
  • Interconnected Kanban Systems
  • z.B. Epic-Board
    • 30 Leute Runde
    • wöchentliche Fortentwicklung des boards
    • Straff durchmoderiert
  • Komplexität begrenzen
  • Sogar Unbedingt über Kapazitäten reden, wenn „PO“s das Board definieren.
  • Engpässe ausmodellieren und transparent machen
  • Nach dem Management des Flows kommt „Start with why“
Advertisements

Über Harald Schlüter

codecentric AG
Dieser Beitrag wurde unter Treffen veröffentlicht. Setze ein Lesezeichen auf den Permalink.

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s