Warum Kanban für Softwareentwicklung Quatsch ist

1. In der Produktionsindustrie handelt es sich zwar um variantenreiche aber dennoch hochstandardisierte Produkte, bspw. werden in einer Produktion nur Pkw gefertigt. Die einzelnen Teilaufgaben sind hochgradig reproduktiv und vorgeplant. Die Softwareentwicklung ist gekennzeichnet durch einen hohen Anteil kreativer und wenig planbarer Tätigkeiten. Die Einzelaufgaben sind eher Unikate.
2. In der Produktionsindustrie stehen die Anforderungen an eine Produktinstanz fast immer zu Beginn der Produktion fest. Bspw. werden die Eigenschaften eines zu produzierenden Pkws bei der Bestellung im Autohaus festgelegt; sie werden während des Produktionslaufes nicht mehr geändert. Zumindest in der agilen Softwareentwicklung bekommt der Kunde die Möglichkeit und nutzt diese auch, Anforderungen wieder zu ändern.
3. In Produktionsprozessen werden physische Gegenstände (räumliche Ausdehnung, Masse, Gewicht) zwischen den Produktionsschritten ausgetauscht bzw. weitergereicht. Die Frage der Pufferung bzw. Lager hat hier eine betriebswirtschaftlich hohe Relevanz. Einzelteile einer Software, d.h. ihre Konfigurationseinheiten und ihr Code, existieren nur elektronisch. Kopien und Verschiebungen dieser Einheiten haben betriebswirtschaftlich eine üblicherweise stark vernachlässigte Relevanz (Stromkosten, Plattenplatz etc.). Für den Bearbeiter eines SW-Arbeitsschrittes ist praktisch auch kaum zu unterscheiden, ob ein Eingangspuffer (z.B. Aufgabenliste) tatsächlich nur eine bestimmte Menge von Elementen enthält oder ob dies lediglich eine Darstellung (Filterung) ist.
4. Die Einzelgegenstände sind in Produktionsprozessen oftmals austauschbar (bspw. liegen 3 gleiche Blechwinkel in der Materialkiste). In der Softwareentwicklung wäre dies ein Merkmal für ineffiziente Programmierung, die durch Konzepte wie Frameworks, Patterns, Vererbung o.ä. üblicherweise minimiert wird.
5. Kanban ist gedacht für Fließfertigung mit strenger Taktung. Das trifft für Softwareentwicklung-Prozesse kaum zu.
6. Und da Software oft mit Hilfe von Projekten entwickelt wird: Bereits die Definition von „Projekt“ sträubt sich gegen die von Takeda genannten essentiellen Voraussetzungen für Kanban.

Zu beachten ist lediglich, dass die Größe des Analyselagers (d.h. die Menge der Anforderungs- und Analyseartefakte) eher klein bleibt, da sonst eine zu hohe Menge trügerische Sicherheit produziert und schnelle Rückkopplungen verhindert würden. Das ist aber einfach die unveränderte und von Kanban völlig losgelöste Motivation, anstelle eines wasserfallgetriebenen Vorgehens agil vorzugehen, d.h. den Zeitraum vom Erkennen einer Anforderung bis zum Nachweis der korrekten Auslieferbarkeit möglichst kurz zu halten.

Hingegen scheint der Critical-Chain-Ansatz mit gezielten lokalen Ineffizienzen die Dauer eines Projektes verkürzen können (wie im APM-Buch für den Staffelholzträger beschrieben bzw. von Elias Goldratt in „Die kritische Kette“, vgl. http://www.oose.de/detail/critical_chain_projektmanagement_2007_11.html).

Bernd Oestereich