Scrumbug, Humban und Klarsicht-Methoden - It’s not the spice, it’s the cooking itself
Inhaltsverzeichnis

Irrtümer in Kanban, die vermeidbar sind

Irrtum 1: Doch nicht wagen? Finger weg, wenn das Management mit Kanban, Lean, Pull, Push, etc. unschlüssig ist …

  • Kanban soll in einem treibenden Team zunächst klein und lokal eingeführt werden. Aber das Team hört, dies ginge nicht, wenn angrenzende, involvierte Bereiche nicht mitmachen …

Bei agilen Methodiken kann das stimmen, gerade bei dem gern praktizierem „Scrum von unten“ kann es nicht funktionieren. Für Kanban ist das streng logisch gesehen falsch, weil Kanban schon bei kleinen Teams Abläufe, Workflows etc. optimiert – ohne dass die ganze Firma aktiv involviert ist. Ganz deutlich: Kanban ist eine Change-Management Tool und startet beim Status Quo. Sie müssen gleich zum Start weder Prozesse ändern, Methoden austauschen oder Workflows ändern. Die kontinuierliche Verbesserung (KVP)  startet im hier und jetzt, also dem IST-Zustand. Andere agile Methodiken grenzen sich da ab, sie benötigen einen „Big Bang“ bei der Implementierung. Alle involvierten Abteilungen oder Bereiche müssen da mit. Und genau dafür ist in der Regel eine Management-Entscheidung erforderlich. Das heisst konkret: Kanban als „U-Boot“ hinterrücks einführen ist keine gute Idee. Natürlich muss man sich „Rückendeckung“ aus dem Management holen, informieren, was eine Kanban-Einführung bedeutet, auch für benachbarte Bereiche. Aber: Ist eine aktive Unterstützung gegeben oder ist der ‘Linie’ „egal“, ob man Kanban einführt, kann man dies auch in angrenzenden Bereichen gut realisieren.

Oft wird dieser Einwand in den Ring geworfen: Niemals wird unser Management akzeptieren, dass Mitarbeiter nichts zu tun haben oder schlimmer noch, nur „herumsitzen“. Das ist die Hürde – denn dies kann, gerade zu Beginn, durch das Pull statt Push Prinzip in Kanban geschehen. Wird jetzt Micromanagement betrieben, wird Kanban im Ansatz verwässert, ansonsten sollte eher auf Durchlaufzeiten und Output geachtet werden. Gerade das hier geschilderte nur „herumsitzen“ ist ein gutes Indiz für eine notwendige Optimierung –  Und diese werden sich in der Regel mit Kanban schnell aufzeigen. Also: proaktiv informieren, Push statt Pull erläutern und dazu immer wieder (gerade dem Management) Updates geben.

Irrtum 2: Ohne komplizierte wissenschaftliche Methoden kann Kanban nichts optimieren …

  • Teams sind schnell frustriert – Die Bottlenecks, also die Verluste, werden gezeigt, aber nicht gelöst. Um sie zu lösen, muss man komplizierte Methoden anwenden, siehe z.B. Toyota. Das verbietet der hektischen Alltag. Wird hier nicht mit „Kanonen auf Spatzen geschossen“?

Nun können Sie mit mit Kanban recht einfach Bottlenecks in knapper Zeit visualisieren – genau dafür ist u.a. das Board da. Vielleicht waren sie bekannt und einfach ausblenden ist schön – einfach – oder niemand wollte diese wirklich sehen. Oder sie waren wirklich bisher weder sichtbar noch bekannt. Alleine diese Visualisierung ist oft ein großer Schritt zur gewünschten Lösung, da die „Flaschenhälse“ nicht mehr zu ignorieren sind – man kann / muß nun beginnen, sie zu beseitigen. Wer jetzt noch „weg sieht …“

Verwendet man Kanban etwas länger, lassen sich – erst halb-, dann mehr oder weniger automatisch – die realen Laufzeiten und Liegezeiten von Aufgaben mitteln und darstellen. Eine wertvolle Information für die Richtung, „wo es wirklich hakt“ („Woran liegt es, dass diese Art von Aufgaben so lange in Stufe 4 warten, bis sie weiter verarbeitet werden können?“). Dies sind einfache, aber große Schritte nach vorne. An dieser Stelle müssen, bitte, wenn möglich wertfrei, die richtigen Fragen gestellt werden, um an den Antworten zielgerichtet zu arbeiten. Die Vorschläge und Ideen kommen oft und alleine durch die Visualisierung. Die Gefahr ist, dass das, was Sie sehen werden, Ihnen nicht immer gefällt – aber wo sonst wollen Sie anfangen – bei den Dingen, die schon optimal laufen und die Ihnen gefallen? Das ist „kuscheln“, nicht Kanban und irgendwie Unsinn. Es stimmt, dass Kanban aus der Automotive-Industrie weiter entwickelt wurde und hier kleine Changes große finanzielle Auswirkungen haben. Für Kanban in der IT werden kaum wissenschaftliche, umfassenden Methoden benötigt, hier reichen schon die „Basics“ aus, um sich in den KVP zu begeben. Wenn man sich denn überhaupt verbessern möchte.

Denn man muss sich klar sein: wenn man Kanban einführt, dann führt dies zu Ergebnissen. Wenn man dann nichts mit diesen Ergebnissen anfängt, sollte man sich schon fragen, warum man dies überhaupt gemacht hat.

Irrtum 3: Kanban für IT ist (nur) ein Modell für die Entwicklung von Software

  • Es ist wie Scrum, ein Modell – eine Art Scrum light. Bei Kanban fängt man zwar im Ist-Zustand an, es ist aber im Grunde nach eine Methodik für die Software- Entwicklung.

Ein weiterer Irrtum, schon ein Klassiker, weil Kanban keine Methodik ist, siehe Irrtum 2. David Anderson entwickelte erstmalig Kanban für IT in der Softwareentwicklung. Es ist aber keine Methodik, auch wenn die deutsche Wikipedia es ein Vorgehensmodell nennt. Der englischsprachige Eintrag zu Kanban für IT ist hier präziser. Hier steht, das Kanban für „process management and improvement“ verwendet wird und auch dieser Eintrag vermischt Kanban hauptsächlich in Kontext für die Entwicklung von Software. Eindeutig ist: „Process Management“, also bestehende Prozesse und „improvement“, also KVP. Und hier ist mit Management fast reine Steuerung gemeint.

Kanban wird, vermehrt auch öfter, in anderen Bereichen in der IT eingesetzt. Heißt (zunächst): Kanban will für sich alleine gestellt kein Vorgehensmodell wie Scrum, Wasserfall oder andere Modelle sein. Das bedeutet ergänzend, dass Sie Kanban parallel ZU diesen anderen Methodiken (oder Vorgehensmodellen) einsetzen können. Kanban lässt sich sehr gut mit agilen Modellen kombinieren – es ist aber kein Muss. Kanban passt immer dann gut und besonders zu Bereichen, die keine Software entwickeln, aber ein hohes Aufkommen an Tasks oder kleinteiligen Aufgaben haben. Und, um diesen Irrtum mal sehr konkret zu entkräften: Wo kommt den Kanban genau her? Aus der Logistik – sehr bodenständig und nicht für Software.

Irrtum 4: Kanban verhindert Zusammenarbeit von Gruppen

  • Durch Scrum wurde Agil erlebbarer (feiner, kleiner Prozess …), man tauschte sich rege aus, saß in Meetings zusammen – und dann: Das Kanban Board. Weniger Meetings – statt dessen schaut jeder auf das Board mit seinen Karten und wo die sind – und trollt sich wieder an den Rechner.

Laut David Anderson, (Begründer) der in seinen Seminaren davon berichtet, ist das einer der am weitesten verbreiteten Irrtümer von Kanban (also dem Verhalten Kanban gegenüber). Merkwürdig, ist doch der Unterschied, dass Scrum das Scrum-Board nutzt, um den Fortschritt der Tasks (aller derer, die in einem Sprint sind) WÄHREND eines Sprints visualisiert. Auf dem Kanban Board wird der Fortschritt von Tasks VON ganzen TEAMS visualisiert (vereinfacht: in Scrum geht es um die Aufgaben einzelner Personen, in Kanban um die Performance aller Beteiligten im Team). Ein Kanban Board ist somit nicht an eine feste Zeit gebunden – es zeigt den gleichmäßigen Durchlauf. Dagegen ist beim Scrum Board dieses genau nach dem abgelaufenen Sprint beendet. Ein neues Spiel beginnt. (Randbemerkung: Eine erhebliche Unterscheidung ist: In Scrum kann das Backlog beliebig lang werden, das Sprint Backlog (bedingt anhand der Kapa(zität) schon recht lang, Ein Kanban-Board ist auf seine physikalischen Dimensionen begrenzt.)

Es gibt keinen sinnvollen Grund, warum die Kommunikation innerhalb von Arbeitsgruppen, Teams etc. stoppen soll. Eher im Gegenteil: Probleme aus Sprints gehen nicht vergessen, sondern werden weiter verfolgt wie bei Kanban, das sehr schön die Bottlenecks im Workflow visualisiert. Diese Darstellung regt normalerweise den Austausch zwischen den Teams an und stärkt (als Wunschziel) die Zusammenarbeit.

Falls dies allerdings nicht geschieht, läuft in der Kommunikation des Teams etwas verkehrt. Über Kommunikation (oder Nicht-Kommunikation) in Teams wird und wurde viel geschrieben. Klappt der Austausch im Team nicht, liegen die Probleme meist tiefer (’siehe z.B. 5 Dysfunctions of Teambuilding‚ – ist zu empfehlen). Kanban „verhindert“ die Zusammenarbeit von Gruppen also nicht – sondern verstärkt sie. Eine Krise im Team sollte man aber nicht versuchen, mit Kanban (alleine) zu lösen.

Irrtum 5: Kanban ist nur ein Visualisierungs-Tool (daher mögen Mitarbeiter Kanban nicht)

  • Kanban wird ja nur benutzt, damit Chefs und Vorgesetzte jederzeit wissen, woran wir arbeiten. Unsere Probleme löst es aber nicht.

Kanban wird gerne als reines Visualisierungs-Tool bezeichnet, insbesondere von agilen Befürwortern. Warum? Es wird unreflektiert nicht weitergedacht – der KVP findet nicht statt. Somit brauche ich auch kein Visualisierungs-Tool. Wiederholung: JA, Kanban visualisiert den Durchfluss, unter anderem (auch gerade diese) die Bottlenecks. Entweder von Teams – oder aber eben auch von einzelnen Teammitgliedern, wenn das Kanban-Board entsprechend „zugeschnittten ist“. Es schafft dann eine Transparenz, die (Linien-) Vorgesetzte gerne nutzen, um kritische Fragen zu stellen. Im Unternehmensdeutsch sollen so die sogenannten Low-Performer „aufgedeckt“ werden. Im Sinne von „Team“ und KVP, vordergründig (sozial) ist das nicht gut. Ist das das erkannte Motiv dahinter, wird kaum ein Mitarbeiter die Einführung begeistert fordern und fördern. Es kommt zu Ablehnung.

Gerade aus Linien-Orga können die Ergebnisse auf dem Kanban-Board Vorgesetzte zum Mikromanagement treiben („Warum haben Sie vorgestern nur 2 Aufgaben bearbeitet?! Hätten Sie sich nicht noch weitere Aufgaben ziehen können?!?“). Ein offensichtlicher Fall, dass hier Themen falsch geschätzt wurden. In jedem Fall sollte Kanban nicht dazu missbraucht werden. Stoppt man nach der Visualisierung, um ins „Fingerpointing“ abzudriften, ist die Verweigerung und auch ein Scheitern vorgezeichnet. Allerdings wird dieses Szenario auch gerne verwendet, um Kanban „anzuschwärzen“. Die Einführung von Kanban erfordert einen gewissen Aufwand und die Unterstützung aller Beteiligten. Ein Reporting für die Mitarbeiter ist meist schneller und effektiver, will man minutengenau wissen, was jeder so tut. Das halte ich allerdings oft für vorgeschoben. Wie so manch andere Ablehnungen, die auf Irrtümern beruhen. Und ein Irrtum hat seine Wurzeln oft im WYSIATI – siehe dort.


©2019 Kopitzke ® Pro | Impressum | Datenschutzerklärung

Log in with your credentials

Forgot your details?

Send this to a friend