Drücken Sie Enter, um das Ergebnis zu sehen oder Esc um abzubrechen.

Mit Kanban kann man alles machen – auch vieles falsch

Letztens besuchten wir beim Treffen einer User Group eine Media- und Software-Agentur, die uns ihre Nutzung von agilen Methoden zeigte. Nicht überraschend war die Geschichte, die wir schon oft gehört haben: Ein großes Projekt mit großem Team, langer Laufzeit und mehreren beteiligten Firmen war in Probleme geraten. Man entscheidet sich für Scrum und alles wird besser. Die Transparenz steigt, die Erwartungshaltung wird angepasst, die Teams gewinnen an Produktivität und das Projekt fängt an zu liefern. Eine schöne Erfolgsgeschichte, wie wir sie uns wünschen.

Spannend war dann, wie man mit kleineren Projekten umging, die nur ein bis zwei Personen über eine kurze Laufzeit benötigen. Diese Projekte wurden mit einem riesigen Kanban Board verwaltet. Sehr beeindruckend. Darüber in großen Lettern die Regeln für das Board, die WIP in (einigen) Spalten markiert, Magnete zum Fixieren der Tasks mit Fotos der Mitarbeiter, die sich den Task genommen hatten und Auswertungen basierend auf den Durchläufen der Tasks. Ich bin sicher, dass diese Form für die Mitarbeiter eine richtig gute Visualisierung der Planung ist und sie durch das Pull-Prinzip ein gutes Maß an Selbstbestimmung und damit Motivation bekommen.

Unsere Diskussion vor dem Board hat aber auch deutlich gezeigt, dass Kanban als Methode keine Vorgaben macht, die der Organisation helfen, agiler zu werden. Auch ein straffer Wasserfallprozess kann super mit einem Kanban Board modelliert werden! Nur wer die Werte von agiler Softwareentwicklung wirklich gut versteht und leben will, wird die Chance haben, mit Kanban diese umzusetzen. Die Organisation muss sich ihre agilen Methoden selbst definieren und dann ein passendes Kanban Board gestalten und die entsprechenden Regeln definieren.

Dazu fällt mir ShuHaRi ein, ein Konzept aus den japanischen Kampfsportarten, das drei Stufen des Lernens beschreibt:

Shu (Gehorche) – folge den Regeln exakt, dann wirst du lernen, es richtig zu machen.
Ha (Weiche ab) – Passe die Regeln an, um deine Arbeit zu verbessern, du weißt ja mittlerweile, worauf es ankommt.
Ri (Verlasse) – Regeln? Was für Regeln? Ich kenne die Werte, lebe danach und mache meine eigenen Regeln.

Eine Organisation, die sich in ihrer agilen Entwicklung auf dem Shu und auch Ha Level befindet, wird durch den Einsatz von Kanban nicht automatisch zu einer Verbesserung der Agilität finden, denn ich muss ja eigentlich meine Regeln selbst machen und das kann man erst mit viel Erfahrung auf dem Ri Level.

Wenn ich aber bei Ri bin, kann ich sicher ein Kanban Board mit Regeln bauen, das mir hilft, meine eigene agile Organisation und deren selbst definierte Abläufe super zu visualisieren.

Christof Braun, Scrum Consultant

  • bgloger

    KANBAN Boards sind schon eine coole Sache. Vor allem auf Unternehmslevel kann man damit ne Menge offensichtlich machen.

  • Ich vermute mal, dass ein Missverständnis darüber vorliegt, was Kanban ist. Kanban ist _KEINE_ agile Entwicklungsmethode und auch _KEIN_ Projektmanagement Framework. Mit Kanban wird evolutionäres Veränderungsmanagement betrieben. Es baut darauf auf, was bereits vorhanden ist und mit den definierten Praktiken wird das Vorhandene sukzessive verbessert. Wenn man ein Unternehmen verbessern will, kann man es natürlich auf das Shu-Level zurücksetzen und sagen, „alles was ihr bisher gemacht habt war nicht gut und deswegen machen wir ab morgen alles anders“. Kanban geht davon aus, dass in einem Unternehmen nicht alles schlecht ist und baut somit auf dem vorhandenen Shu-, Ha- oder Ri-Level des Unternehmens auf – je nachdem, wo es sich befindet. Kanban geht also nicht damit an den Start, eine völlig neue, agile Softwareentwicklung zu etablieren. Kanban ermöglicht es einem Unternehmen, gezielte, individuelle Verbesserungen durchzuführen, die für den speziellen Kontext geeignet sind, damit das Unternehmen erfolgreich wird bzw. bleibt. In den meisten Fällen führt dieser Weg zum Erfolg zur Agilität. Und ja, Nachdenken über die eigene Situation bzw. Regeln ist ausdrücklich erwünscht – Kanban hilft dabei.

    • bgloger

      Das es keine agile Entwicklungsmethode ist, dass es keine Projektmanagement Methode ist … stimmt, dass es eine „evolutionäre“ Methode ist … darüber mag ich jetzt hier nicht streiten. Aber meiner Meinung ist das Unsinn. Wieso – aber viele Kanban-Denker immer sagen, dass andere Mindsets sagen würden: „….alles, was bisher gemacht …“ wurde war nicht gut … finde ich insofern nicht sinnvoll, als das meiner Meinung nach nicht so ist — Im Gegensatz zu KANBAN versuchen andere Mindset allerdings Lösungen für die Probleme durch  Best-Practices anzubieten. Damit Übernehmen dies Akteure dieser Ideen Verantwortung für ihre Kunden. Sie setzen sich damit auch der Kritik aus und sind couragiert. „Kanban ermöglicht …“ — hm, Kanban ermöglicht gar nichts. Menschen, die Tools und Erkenntnisse aus den in Kanban zusammen getragenen wissenschaftlichen Erkenntnissen nutzen ermöglichen etwas. Kanban selbst ist kein Akteur, so wenig wie Scrum oder Projektmanagement. Kanban und Scrum sind zwei Seiten der exakt gleichen Medallie: Empirisch Prozesse zu verändern und Menschen ihre Arbeitsbedingungen zu verbessern.

      • Ja, Kanban als solches ermöglicht/macht gleich wenig wie Scrum und fast alles andere auch auf diesem Planeten. Gleich wie „… andere Mindsets …“ auch _KEINE_ „… Lösungen für die Probleme durch Best-Practices anbieten“. Auch hier machen es Akteure bzw. Vertreter des Mindsets und nicht das Mindset. 

        Ich verstehe leider nicht, warum nur Vertreter von Best Practices Probleme lösen und Verantwortung für Kunden übernehmen. Ob jemand Verantwortung übernimmt oder nicht, ist imho völlig losgelöst von Kanban oder Scrum. Das ist eine Charaktereigenschaft der Akteure. Man kann auch Verantwortung übernehmen, wenn man keine bestehende Best Practice übernimmt und eine individuelle, maßgeschneiderte Lösung für Unternehmen anbietet. Wahrscheinlich muss man damit sogar mehr Verantwortung übernehmen, da das Argument „ihr macht es eben falsch“ nicht funktioniert.

        Ich bin auch der Meinung, dass Kanban und Scrum es u.a. zum Ziel haben, die Arbeitsbedingungen von Menschen zu verbessern. Und es gibt noch etliche andere Ansätze, die auch dieses Ziel verfolgen. Der Unterschied liegt darin „was gemacht wird“ und „wie es gemacht wird“. Welchen Ansatz ein Unternehmen verfolgt bzw. verfolgen will ist stark kontextabhängig.

  • Hmm … Ich sehe Unternehmen, die die Scrum Pille schlucken und damit Kopfschmerzen in Magenschmerzen umwandeln. Ich sehe Unternehmen, die Kanban wie Bachblüten schlucken ohne sich weiterzuentwickeln. Und dann sehe ich noch Unternehmen, in denen Menschen und Teams Verantwortung für die eigene „Gesundheit“ übernehmen. Das ist alles was zählt. 

    Scrum und Kanban sind für diese Menschen wunderbare Ideenspenden. Diesen Menschen ist es egal welche „Marke“ drauf steht, und sie sind offen für Neues.  Um es mit den Worten von Sven Regener (?) zu sagen .. Auf jeden Eimer passt ein Gesicht :-)

    • Meine Erfahrung ist es auch, dass die „Marke“ den meisten Menschen egal ist – nicht allen, aber definitiv den meisten. Es geht darum, Probleme zu lösen und das kann man auf verschiedene Arten mit unterschiedlichen Auswirkungen auf das Unternehmen machen.

  • Markus Oberndoerfer

    Ein weiteres japanisches Prinzip ist das Shin Gi Waza, die Harmonie von Körper, Geist und Technik. Das Werkzeug allein macht noch keine Lösung, wie auch ein gutes Schwert keinen guten Schwertkämpfer macht. Ich denke, das ist die Crux bei der Übernahme von Management-Konzepten, wenn man denkt, es würde sich hier um eine Art Plugin handeln, das alle Probleme lösen kann. Ich hatte mal mit einem Unternehmen zu tun, das Kanban deswegen ablehnte, weil es ihnen zu transparent war. 

    • Ja, dass ist ein guter Punkt.  Wir kenne ja alle das Agile Manifest und seinen ersten Punkt: Individuals and Interactions over Processes and Tools.
      Ich denke, wiedermal ist es der Sinn, die Werte, die hinter den jeweiligen Werkzeugen oder Prozessen stecken, die innerhalb der Organisationen verstanden werden müssen, damit man den vollen Wert daraus schöpfen kann.  Das ist aber meist der schwierigste Teil und dauert auch lange.  Und daher postuliere ich eben, dass man besonders zum Anfang besser mit einem Rahmenwerk beginnt, dass klare Ansagen macht und einiges fest definiert um die agilen Werte auch wirklich zu leben.  Je mehr Spielraum ich habe, desto größer das Risiko, dass ich das Werkzeug, den Prozess nicht so verwende, wie es eigentlich gedacht ist und wie es den Werten entspricht.  Deshalb ziehe ich für agile Anfänger Scrum Kanban vor.