Deine Muda (ist gar keine)

Bild: Wikimedia Commons - Public Domain

In den seltensten Fällen ist "Agilität" die erste Methode die meine Kunden bei sich eingeführt haben¹. Meistens gab es bereits vorher Transitionsversuche, und einer der mir häufig begegnet ist der Richtung Lean Management. In den meisten Fällen ist davon nicht mehr viel übrig, sonst müsste man ja keinen neuen Versuch unternehmen (meine These: wenn Lean Management wirklich funktioniert ist Agilität bereits enthalten, zumindest wenn wir von der IT reden). Wenn überhaupt etwas geblieben ist, ist es meistens ein eher untergeordneter Aspekt, das Vermeiden von Verschwendung (warum das untergeordnet ist kann man hier nachlesen). Im Regelfall wird aber nicht einmal dieser Grundsatz richtig eingesetzt - "das ist Verschwendung" ist eher ein Totschlagargument gegen alles was man nicht versteht.

In der Initiierungsphase von Scrum- oder Kanban-Implementationen sitzen aufgrunddessen oft Stakeholder mit am Tisch für die erstmal alles Neue dem Verdacht unterliegt Verschwendung zu sein². Plannings alle zwei Wochen? Verschwendung! Retrospektiven? Verschwendung! Backlog Refinements? Verschwendung! Reviews? Verschwendung! Und so weiter. Schließlich wird in dieser Zeit ja nichts produziert. Die Ironie der Geschichte: in anderen Kontexten könnten sie sogar recht haben, beispielsweise bei der Produktion von seriell gefertigter Hardware, oder beim Betrieb eines Callcenters. Dort wo Software entwickelt wird ist es jedoch grundlegend anders.

Anders als im Fall der beiden gerade genannten Beispiele besteht Software-Entwicklung nicht aus der Wiederholung immer gleicher Arbeitsschritte, die so effizient gestaltet sind, dass man von ihnen nicht abweichen sollte. Die kann es nur dort geben wo ein standardisiertes Produkt in hoher Stückzahl auf standardisierte Weise erstellt wird. Bei Software wäre eben das die Verschwendung - warum sollte man den Erstellungsprozess permanent wiederholen, wenn es doch ausreicht den Code einfach mit Copy & Paste zu duplizieren? Dementsprechend macht das auch niemand. Was in Software-Projekten erstellt wird sind Prototypen: noch nie zuvor hat jemand für dieses Problem und mit dieser Technologie eine Lösung gebaut. Bestenfalls gibt es ähnliche Probleme, deren Lösungen man "nur noch" anpassen muss - auch das ist dann aber wieder prototypisch.

Aber heisst das nicht, dass es Lean Management in der IT gar nicht geben kann? Keineswegs! Es sieht hier nur anders aus. Da im Entwicklungsprozess permanent und an allen Enden neue, bis dahin noch nicht voraussagbare Probleme auftauchen benötigt man permanente Analyse- und Lösungs-Prozesse. Diese durch verschiedene Hierarchie- oder Eskalations-Ebenen zu schicken würde zu Overhead führen: entweder wären die oben sitzenden Entscheider permenent überlastet oder es würden so viele von ihnen benötigt, dass sie sich koordinieren müssten, mit Bürokratie als Folge. Das kann also nicht der Weg sein.

Lean in diesem Kontext kann nur bedeuten: permanent auftauchende neuartige und einzigartige Probleme müssen möglichst weit unten in der Hierarchie gefunden, analysiert und behoben werden, und zwar mit möglichst individuellen Lösungen. Das ist dann aber nichts Anderes als regelmässiges inspect & adapt in Form von Plannings, Retrospektiven, Refinements und Reviews. Mit anderen Worten: in der IT ist Lean von Agil nicht zu trennen. Siehe oben.

Bleibt nur noch eine Frage: was soll die Überschrift dieses Artikels? Die ist ist ein Wortspiel. Sorry, aber manchmal muss das sein.


¹Die Diskussion ob Agile eine Methode ich spare ich mir an dieser Stelle
²Ja, mir sind tatsächlich Leute begegnet, die Lean Management und Kanban für unvereinbar gehalten haben