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

Fakten und Irrtümer in Kanban

(Un-) bewusst gestreut: Kanban in der IT

Generell habe ich wahrgenommen, dass auch bei Kanban der Wunschglaube angeheftet wird, dass eine Einführung schnell und direkt sichtbar Verbesserungen bringt. Bleiben wir bei 6 einfachen Fakten – diese sollten schon die ersten Irritationen beseitigen:

  • Kanban ist NUR eine Methode zur Produktionssteuerung – und Toyota hat es nicht erfunden. Es war der Handel, speziell der Einzelhandel mit seinen Supermarktketten.
  • Ziel ist, die Wertschöpfungskette auf jeder Produktionsstufe einer mehrstufigen Integrationskette kostenoptimal zu steuern. NICHT auslastungsmaximiert. Das kommt hinterher.
  • Die Auslastung der beteiligten Ressourcen zu 100% ist ein Management Wunschdenken und ein erworbener Trugschluss! Bleiben wir gleich bein einem Motor – am besten ihren: Sie jagen das Triebwerk permanet, über eine längere Zeit auf 7500 Umdrehungen. Sie wissen instiktiv, das ist nicht gut – und dann geht der Motor wegen Überlastung kaputt. Wer zahlt? … Jeder operative Raum eines Beteiligten (Zeit, Kraft -psychisch, -physisch) wird komplett aufgebraucht. Die (gewünschte) Chance des KVP, der zwingend auf lernen aufbaut, wird abgewürgt, weil keine Zeit zur (mentalen) Erholung vorhanden ist.
  • Kanban legt Wert auf einen kontinuierlichen Durchfluss der Dinge bei Reduzierungen der beteiligten Dinge, ebenso auf die Möglichkeit, Schwachstellen in diesem Durchfluss zu erkennen. Nochmal Modell Motor: Schön auf 2500 Umdrehungen, keine heftigen Abweichungen und Sie fahren mit einem ‚dankbaren‘ Motor mehrmals um die Welt. Wäre doch schön, oder?
  • Kanban ist kein Projekt! Es ist die einfache Idee, eine Menge an parallerer Arbeit (Work in Progress) zu begrenzen, diese Menge (und nicht die Inhalte) zu visualisieren (das Board z.B. mit Haft-Notizen) und nur dann mit neuer Arbeit zu beginnen, wenn die vorherigen erledigt sind. Das „Wann“ regelt ein einfaches Signalsystem.
  • Gerade weil Menschen, (die jeder für sich als Individuum) Widerstände bei der Einführung aufbauen (können), ist es sehr ratsam, die Einführung evolutionär und nicht revolutionär zu gestalten. Die Einführung findet stets auf Basis eines validen „Status Quo“ statt, weil Sie nichts verbessern können, wenn Sie keinen Startpunkt, ab dem es los geht, haben (Also die Referenz als Bezugspunkt).

Kanban funktioniert nicht mit „verteilten Teams“

„Ich (als Projektleiter oder Team-Lead) habe Developer und andere Leute in Polen, Deutschland, Indien und Kapstadt. Wie soll ich das mit Kanban hinbekommen? Das Board, wo alle drauf sehen sollen – das geht doch gar nicht. Oder das morgendliche Daily – kann doch nicht funktionieren, oder?“ Doch, es kann – mit Einfallsreichtum und Disziplin, das haben uns die Asiaten bereits vorgemacht.

Nicht kompliziert, nur etwas stringent aufwändiger. Zunächst schreibt Kanban (Scrum auch) nicht vor, zu welcher Zeit Dailys, ob morgens oder Nachmittags stattfinden sollen. Wichtig ist, dass alle den Sinn des Dailys verstanden haben und es somit wollen. Somit ist die erste Hürde genommen, die 2. Hürde ist die Technik, die genutzt werden kann: Ge-sharte Bildschirme, Video-Calls, dabei ein elektronisches Board (z.B. Trello), Gruppenchat (mit Internet-Video) und einen Gesprächsleiter (gerne rollierend …).

Also: Einigen ist die Devise. ‚Funktioniert nicht‘ ist eine vorgeschobene Angst mit Kontrollverlust. Bei „Follow-the-sun“ -Entwicklungen empfiehlt sich, zwei Daily’s zu planen (die kürzer sein können). Alles nicht kompliziert, nur etwas ‚nachhaltig stringenter‚ …

Es darf auch nur ein Kanban Board pro Team geben – nicht eins per Standort. Cloud-Lösungen machen es möglich. Großformat-Monitore (oder mobile Wände) gibt es für kleines Geld, also warum nicht mit einer preiswerten Webcam ein regelmäßiges Update (z.B. jede Stunde) allen zur Verfügung stellen? Am Standort des Boards wird dann ein Boardverantwortlicher ausgesucht, der die Änderungen pflegt. „Think big, act small“ erhält somit eine interessante Ausrichtung.

Pull anstatt Push, was soll das bringen?

„Wenn ich etwas erledigt habe, gebe ich es an den nächsten weiter. Was bringt das wenn ich es nicht abgeben kann, weil der nächste noch voll beschäftigt ist? Z. B. Die UX-Designer werden nicht fertig und die Coder sitzen gelangweilt rum. Durch unsere Limitierungen („Work in Progress“) kann das Team keine neue Arbeit anfassen. Und jetzt ist das alles auch noch sichtbar auf meinem Board! Das wollen die nicht – und die Kollegen fangen (unreflektiert) trotzdem mit neuen Aufgaben an…“.

Ja, das ist so und kommt vor. Gerade zu Beginn ist das nicht unüblich – das Team murrt – weil Arbeiten nicht abgeholt werden. Hier verbirgt sich die Schwäche, dass das Team (mehrere) sich noch nicht als Team sieht und denkt, sondern jeder einzelne seine Befindlichkeiten höher bewertet. Das wichtiges Ziel von Kanban, der Kern, nochmals verdeutlicht: Der optimale Durchfluss (Flow) von Tasks (Aufgaben). Flow bedeutet, dass die Aufgaben gleichmäßig durch das System fließen sollen, ohne lange Wartezeiten oder Blockaden (sogenannte „Liegezeiten“). Alles, was den Flow behindert, sollte kritisch unter die Lupe genommen werden. Dafür ist (u.a.) das Board da, um diesen Flow (oder etwaige Störungen) zu zeigen.

Was ist nun der Unterschied zu vorher? Kanban startet mit „Start here with what you are doing“ –  das ist die aktuelle Realität. An dieser Stelle sollte noch nichts verändert worden sein! Denn nur so wird sichtbar, was sichtbar werden SOLL. Kanban postuliert nicht, dass das allen gefallen wird … Oder konkret gesagt: Es geht nicht um das schicke Board, es geht darum, was hier zu sehen ist. Und wenn etwas sichtbar ist, kann es verbessert werden. So ist das Prinzip.

Dies hat dann positive Aspekte: Durch die Sichtbarkeit der Bottlenecks werden die Schwachstellen möglichst objektiv auf den Punkt gebracht und Sie können sich auf machen, diese zu beheben. Erst die Probleme analysieren (also die Ursache), wie sie entstehen (dafür gibt es wissenschaftliche Methoden), dann das punktuelle Verbessern. Ich schreibe punktuell aus gutem Grund: Gerne wird gleichzeitig an mehreren Bottlenecks gleichzeitig herum geschraubt. Die Modifikation von 2 oder mehr Störungen im Flow potenziert die neu zu erwartenden (jetzt andere, auch negative) Auswirkungen exponentiell (Gruß aus der Systemik) – das können Sie nicht mehr handhaben und die eindeutige Ursachendefinition mutiert zum „Münze werfen …“ Auch wenn das Management viele und schnelle (Ver-)änderungen fordert, bleiben Sie standhaft! Sauber definierte Bottlenecks zeigen zudem personelle oder andere Engpässe an – die sich weit oben auf der Sachebene befinden. Damit können Sie an das Management herantreten (oder im Vorfeld selbst lösen) und Lösungen einfordern. Ein gern benutzter Slogan bei Kanban ist „Stop starting, start finishing“. Das Pull-Prinzip und das WIP-Limit sind fundamentale Eigenschaften, um dies zu erreichen.


©2019 Kopitzke ® Pro | Impressum | Datenschutzerklärung

Log in with your credentials

Forgot your details?

Send this to a friend