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

Agile Toolbox
Scrum
bgloger-redakteur
November 7, 2011

Table of content

Diesen Beitrag teilen

Das könnte auch interessant sein:

Scrum ist wie Klavierspielen – Warum du es nur durchs Tun wirklich lernst
BG

Scrum ist wie Klavierspielen – Warum du es nur durchs Tun wirklich lernst

Wer die Zukunft voraussagen will, muss sie gestalten
BG

Wer die Zukunft voraussagen will, muss sie gestalten

Die etwas andere agile Bücherliste.
BG

Die etwas andere agile Bücherliste.

Agile Transformation: Schluss mit dem Theoriedschungel – Fang endlich an!
BG

Agile Transformation: Schluss mit dem Theoriedschungel – Fang endlich an!

Scrum organisiert am Produkt entlang
BG

Scrum organisiert am Produkt entlang

Trainings verändern - oder sie sind wertlos!
BG

Trainings verändern - oder sie sind wertlos!

Zertifizierung – Das ist hier die Frage
BG

Zertifizierung – Das ist hier die Frage

Die größten Missverständnisse über Scrum – und warum sie gefährlich sind
BG

Die größten Missverständnisse über Scrum – und warum sie gefährlich sind

Organisationsentwicklung am Produkt entlang
BG

Organisationsentwicklung am Produkt entlang

Scrum im Krankenhaus: Eine Revolution in der Gesundheitsversorgung
BG

Scrum im Krankenhaus: Eine Revolution in der Gesundheitsversorgung

Speed kills – oder rettet?
BG

Speed kills – oder rettet?

Weniger ist mehr – der Upstream ist zu managen
BG

Weniger ist mehr – der Upstream ist zu managen