Agile Softwareentwicklung ist in aller Munde. Wenn man jemanden fragt, welche agile Methoden er kenne, so würde er sofort Scrum nennen. [http://www.heise.de/developer/meldung/Studie-Agile-Softwareentwicklung-ist-Mainstream-912207.html Scrum ist die weitverbreiteste agile Methode]. Auch Kanban wird vermehrt als agile Methode genannt[http://www.amazon.de/Agile-Projekte-Kanban-Unternehmen-durchf%C3%BChren/dp/3898647528]. Wie funktioniert Kanban eigentlich?
++ Das Wort
"Kanban" kommt aus dem japanischen und [http://jisho.org/words?jap=kanban&eng=&dict=edict bedeutet übersetzt etwa "Signalkarten"]. Es ist im Sinne von anzeigen, signalisieren zu verstehen.
++ Historisches
Kiichiro Toyoda, der Gründer von Toyota, hatte die Idee der Just-in-Time-Produktion. Es wurde bekannt als das Toyota Production System (TPS). Die erklärten Ziele waren Eliminierung von "Abfall" (muda), "Überlastung" (muri) und "Inkonsistenzen" (mura), und leitete daraus weitere Prinzipien ab. Wegen des Prinzips der stetigen Verbesserung (Kaizen) wurden regelmäßig, kurze Meetings institutionalisiert, um darüber zu sprechen, wie man diese Ziele besser erreichen kann.
Im Pull-Prinzip produzierten die Produktionsstraßen fortan nicht mehr soviel wie es Ressourcen gab, sondern nur soviel, wie Autos bestellt wurden. Man signalisierte mit Karten an der Entnahmestelle, dass die dort entnommene Ressource, z.B. eine Tür, nachproduziert werden musste. Die Karte setzte derjenige ein, der die Tür benötigte, um sie einzubauen. Hier kommt also Kanban zum tragen. Insgesamt wurde die Produktion so besser auf den tatsächlichen Kunden-Bedarf eingestellt.
Jeder Autohersteller setzt die von Toyota entwickelten Methoden heutzutage, in der ein oder anderen Form, ein. Aus offensichtlichen Gründen nennen sie das System aber nicht "Toyota Production System", sondern "Lean Production".
Später adaptierte man die Vorgehensweise der Signalkarten zur Produktionssteuerung auf die Informationstechnologie, worin der Begriff "Kanban" nun weitläufig bekannt ist.
++ Kanban in der IT
Es geht nicht mehr um Karrosserien oder Türen von Autos, sondern um (meistens) Software. Dennoch, Kanban eignet sich für jede Art von Produkt.
In der IT hat es sich durchgesetzt, ein Whiteboard zu benutzen, auf dem man die Karten, welche die zu erledigende Arbeit darstellen, gut sichtbar anheftet. Spricht man von "Kanban", so assoziiert man heute nicht nur die Karten selbst damit, sondern auch die Visualisierungsform, dem Whiteboard.
Auf den Karten ist die zu erledigende Arbeit beschrieben. Jeder Bearbeiter kann nur an einer Karte gleichzeitig arbeiten. Eine Karte kann aber mehrere Bearbeiter haben. Die Spalten sind nach dem Status benannt, in denen sich eine Arbeit befinden kann. Sie besitzen sogenannte Work-In-Progress-Limits (WIP-Limits). Jede WIP-Spalte besitzt zusätzlich noch eine "erledigt"-Ablage.
Kanban ist flow-zentrisch
Das bedeutet insbesondere, dass durch die WIP-Limits das Pull-Prinzip durchgesetzt wird, denn, wenn eine Spalte mit Arbeitskarten aufgefüllt ist, so darf keine weitere Karte hinein. Völlig automatisch ist man also gezwungen entweder dabei zu helfen, Karten schneller zu bearbeiten, oder eine Karte aus einer "erledigt"-Ablage in die nächste WIP-Spalte zu bewegen und weiter zu bearbeiten, damit die Spalte (der Arbeitsstatus) wieder Platz für eine neue Karte hat.
Verbesserung als Institution
In täglichen, zeitlich kurzen, Stand-Up-Meetings (15-30 Minuten, engl. Daily Stand-Up) werden die Karten im Flow, also die Arbeit und der Arbeitsablauf, besprochen. Wegen des Pull-Prinzips ist es auch sinnvoll, die Arbeit von hinten nach vorne zu besprechen. Außerdem kann es Abhängigkeiten zwischen den Arbeiten geben. Weitere [http://martinfowler.com/articles/itsNotJustStandingUp.html gute Vorgehensweisen für das Stand-Up-Meeting sind hier zu finden]. Das Stand-Up-Meeting dient also schon der Verbesserung.
Wie weitere Verbesserungen eingebracht werden ist nicht weiter geregelt. Hierüber muss man sich immer mit dem Team einigen. Das Team bestimmt, wo es Feedback-Schleifen einbaut. Ein gutes Mittel dazu ist ein Verbesserungs-Board (engl. Improvement-Board) auf dem man jederzeit Vorschläge und Wünsche aufschreiben kann. In einem Meeting, bspw. wöchentlich am Ende der Woche abgehalten, wäre das Verbesserungs-Board zu besprechen.
Einführung
Bemerkenswert ist, dass man die derzeitige Realität der Arbeit visualisiert und transparent macht - und dabei erst einmal keine Prozesse ändert. Erst das Visualisieren führt zur tatsächlichen Erkenntnis der Arbeitsrealität. Nun können Verbesserungsvorschläge besprochen werden und die Verbesserung kann nun überhaupt erst stattfinden. Führt man Kanban im (Software-)Unternehmen ein, so muss man also gar keine Eingriffe in die Prozesse tätigen, sondern erst einmal nur die Arbeitsrealität abbilden und transparent machen. Wie man Kanban gut einführen kann verdeutlicht dieser [http://www.heise.de/developer/artikel/Kanban-richtig-einfuehren-1344554.html Artikel des Heise-Verlags].
Agil
Ob Kanban "agil" ist, ist [http://www.storz.net/blog/postings/ist-kanban-agile/ ein wenig differenzierter zu beantworten]. Im Großen und Ganzen ist Kanban zuersteinmal nicht "agil", sondern "lean". Das agile Handeln kommt mit der Zeit jedoch völlig automatisch. Denn agil bedeutet, sich auf Veränderungen schnell einstellen zu können und gerade Kanban fokussiert sich darauf.
Weitere Quellen
[http://www.heise.de/developer/artikel/Kanban-in-der-IT-Eine-Kultur-der-kontinuierlichen-Verbesserung-schaffen-1758331.html Kanban in der IT - Heise Verlag]
Andere Kommentare