Lean Thinking für vielbeschäftigte Entwickler: die endgültige Fassung, jetzt auch gedruckt

Version 3.0 von "Lean Thinking per sviluppatori software impegnati" schreibt die Kapitel 1 bis 6 nach Leserfeedback neu und zieht agentische KI durch den gesamten Text, nicht nur durch das Kapitel, das ihr gewidmet ist. Und es gibt jetzt die gedruckte Ausgabe, 6x9 Zoll (15,24 x 22,86 cm), 316 Seiten. Das Buch ist auf Italienisch geschrieben; eine englische Ausgabe kommt noch in diesem Jahr.

Lean stammt aus der Fabrik. Software ist keine Fabrik. Von diesem Satz aus ist das Buch gestartet, und er ist der Grund, warum die meisten Lean-Bücher für Entwickler in der Schublade landen: Sie übertragen Rezepte aus der Fertigung auf ein Handwerk, dessen Rohstoff mehrdeutige Anforderungen sind und keine genormten Schrauben.

Heute erscheint die Fassung, die ich für endgültig halte, und mit ihr die gedruckte Ausgabe. Papier war von Anfang an geplant, aber ein Buch geht in den Druck, wenn es fertig ist, und nicht, während man noch daran schreibt. Jetzt ist es fertig, also gibt es es auf Amazon auch gedruckt.

Was ich in den Teams gesehen habe, denen ich Lean beigebracht habe

Das Buch kommt von dort, nicht aus einer Leseliste. Ich mache Beratung und Training zu diesen Prinzipien in echten Unternehmen, und die Geschwindigkeit, mit der ein Team aufblüht, sobald es aufhört, gegen den eigenen Prozess zu kämpfen, überrascht mich immer noch. Leute, die im ersten Meeting den Mund nicht aufgemacht haben, halten dich zwei Monate später im Flur an, um dir zu sagen, wie das Board geändert gehört.

Dann kommt der unangenehme Teil. Sobald der Arbeitsfluss für alle sichtbar wird, stellt sich fast immer heraus, dass der Engpass nicht das Team war. Es waren die jeden Montag neu geschriebenen Prioritäten, die Freigaben, die tagelang auf irgendeinem Schreibtisch lagen, die Arbeit, die dreimal begonnen und nie beendet wurde. Sehr oft hat es das Management zuerst gemerkt und zugegeben, dass das Problem, das behoben werden musste, sein eigenes war. Ab da hat sich wirklich etwas bewegt.

Software House Nightmares

Eine der Analogien, die ich am liebsten benutze, hat mir das Fernsehen geschenkt. Falls du “Kitchen Nightmares” nie gesehen hast, der Ablauf ist immer derselbe: Ein Restaurant steht kurz vor dem Aus, der Koch verbringt ein paar Tage dort, schaut sich an, wie im Service tatsächlich gearbeitet wird, krempelt den Laden um und hinterlässt eine Küche, die funktioniert. Von Produktion oder Prozessen spricht dabei nie jemand, und trotzdem ist fast alles, was der Koch anordnet, Lean: Er kürzt eine Karte mit achtzig Gerichten auf zehn gut gemachte, räumt Kühlhäuser leer, in denen vor Monaten gekaufte Ware liegt, bringt die Küche in Ordnung, weil man unnötige Wege mit blossem Auge sieht, beobachtet den Service live statt sich die Versionen der Beteiligten anzuhören, und gibt einer resignierten Brigade zum Schluss ihre Würde zurück. Weniger Varianz, Bestände, Bewegungsverschwendung, selbst hingehen und schauen, Respekt vor den Menschen. Das sind dieselben Kapitel.

Man könnte “Software House Nightmares” drehen, ohne eine Zeile der Methode zu ändern. Was sich ändert, ist das Artefakt: Aus dem Gericht wird ein Release, aus dem Kühlhaus ein Backlog mit vierhundert Tickets, die nie jemand öffnen wird, aus dem Samstagabendservice das Freitags-Deployment. Die Prinzipien bleiben, wo sie sind.

Das liegt daran, dass es Prinzipien sind und keine Regeln, und dieser Unterschied entgeht uns in unserem Beruf permanent. Ein Prinzip übersteht den Kontextwechsel: “Mach liegengebliebene Arbeit sichtbar” gilt in einer Küche, in einer Werkshalle und in einem Repository. Eine Regel nicht. Eine Regel muss bei jedem Kontextwechsel neu geschrieben werden, weil sie auf den vorherigen geeicht war. Und wir in der Softwareentwicklung sind hervorragend darin, Regeln zu schreiben, samt ihrer Zahlen: zweiwöchige Sprints, 80% Coverage, WIP-Limit fünf, vier Meetings pro Woche. Dann wechselt das Team, wechselt das Produkt, und die Regel gilt aus Trägheit weiter, während sich an das Prinzip, aus dem sie entstanden ist, niemand mehr erinnert.

Deshalb erklärt das Buch jedes Prinzip in seinem ursprünglichen Kontext, dem von Toyota, und erfindet es dann für Software neu, statt es umzufüllen. Wer das Prinzip verstanden hat, schreibt sich die Regel bei jedem Kontextwechsel selbst neu, und mehr braucht es eigentlich nicht.

“Kitchen Nightmares” begann als “Ramsay’s Kitchen Nightmares”, ein Format, das Optomen Television für Channel 4 entwickelt und produziert hat und das All3Media International international vertreibt; Gordon Ramsay moderiert die britische und die US-Ausgabe. In mehreren Ländern gibt es lokale Adaptionen, im deutschsprachigen Raum lief vor allem die synchronisierte Fassung mit Ramsay. Titel, Formate und Marken gehören den jeweiligen Inhabern: Ich zitiere sie hier ausschliesslich als Analogie, ohne jede Verbindung zur Sendung oder zu ihren Produzenten.

Was im Buch steht

Die Kapitel 1 bis 6 habe ich nach dem Feedback der Leser neu geschrieben: die Gedankengänge dialogischer, die Szenarien aus dem echten Arbeitstag von Entwicklern statt vom Fliessband.

Die Zahlen sind zum Nachrechnen da. Little’s Law in der Form, die wirklich hilft, Lead Time = WIP / Throughput, und eine Work-in-Progress-Tabelle auf offengelegten Annahmen, ein Team aus fünf Personen und Aufgaben von acht Personentagen, damit du Zeile für Zeile prüfen kannst, was passiert, wenn aus drei parallelen Arbeiten eine wird. Alle Zitate gehen auf die Primärquelle zurück, und manche halten Überraschungen bereit: Das Wort “Lean” haben nicht Womack und Jones 1990 geprägt, es stammt von John Krafcik, aus einem Artikel von 1988, der aus seiner Forschung am MIT entstanden ist.

Dazu kommen die Seiten, die ich selbst als Erstes benutze: das abschliessende Cheat Sheet, die Tabelle der 7+1 Muda mit der Spalte konkreter Beispiele, die Checkliste für die Lean Code Review.

Genau dafür sind die vierundzwanzig Diagramme da, um in einer Abbildung zu zeigen, wofür der Fliesstext zwei Seiten braucht. Zum Beispiel die drei Säulen, auf denen alles andere steht.

Agentische KI bleibt nicht in einem Kapitel

Als ich zu schreiben anfing, haben KI-Assistenten Codezeilen vervollständigt. Heute öffnen sie Pull Requests.

Ein eigenes Kapitel gibt es, aber die KI dort einzusperren wäre bequem und falsch gewesen. Agenten verschieben die Balance überall, also kommt das Thema dort wieder vor, wo es hingehört: im Fluss, in den Schätzungen, in den WIP-Limits, in der Code Review, in der Art, wie man auf Qualität schaut. Wo KI nichts ändert, sage ich nichts dazu, und wo sie etwas ändert, sage ich es an der Stelle, an der die Leserin es sich ohnehin gerade fragt.

Einen Einwand höre ich oft: Wenn die KI den Code für mich schreibt, brauche ich Lean weniger. Es ist genau umgekehrt. Wenn die Kosten der Codeproduktion einbrechen, bleibt alles andere, wo es war: das Warten auf Freigaben, Feedbackschleifen von Wochen, die Zeit, die Arbeit in einer Warteschlange liegt. Wer früher ein Feature in drei Tagen schrieb und sieben Tage auf das Deployment wartete, konnte das Missverhältnis ertragen. Wenn man es heute in zwei Stunden schreibt, werden diese sieben Tage unerträglich und überdeutlich sichtbar.

Das ist das Diagramm, das im Buch zum Kapitel über den Fluss gehört. Zähl die Tage: Fast alle sind Warten, und kein einziges dieser Kästchen wird kürzer, weil ein Agent den Code für dich schreibt.

Im Buch findest du drei Verschwendungsarten, die es im Toyota Production System nicht geben konnte.

Vibe Coding: Code erzeugen, ohne ihn zu verstehen, und ihn akzeptieren, solange er zu funktionieren scheint. Das ist technischer Cargo-Kult in moderner Fassung, man übernimmt die äusseren Formen (der Code kompiliert, die Funktionen werden aufgerufen) ohne die Substanz. Jede Zeile, die man akzeptiert, ohne sie verstanden zu haben, sind technische Schulden, die man beim Unterschreiben nicht sieht und bei jeder Wartung bezahlt.

Dann ist da die generative Überkapazität. Die klassische Überproduktion entsteht durch Entwickler, die etwas bauen, “wenn wir schon dabei sind”; hier baut der Agent, während er nachdenkt: Varianten, die niemand angefragt hat, erfundene Randfälle, Fehlerbehandlung für Szenarien, die das System gar nicht kennt. Alles davon muss trotzdem jemand pflegen.

Der letzte ist der Verification Overhead, also der Aufwand, das Ergebnis des Agenten kritisch gegenzulesen. Er ist nicht null und taucht in keiner Schätzung auf. Der Agent kennt weder deine Architekturkonventionen noch die impliziten Geschäftsregeln, die sich das Team über Jahre angesammelt hat. Wer diese Zeit nicht mitzählt, hält Erzeugungsgeschwindigkeit für Produktivität, und das ist sie nicht.

Warum Papier

Weil viele von euch danach gefragt haben. Manche lesen gern digital, und manche bevorzugen bei einem Nachschlagetext Papier: Es bleibt neben der Tastatur aufgeschlagen liegen, man schreibt an den Rand, man findet die Seite, die man braucht, ohne etwas zu öffnen. Das ist Geschmackssache, und Version 3.0 deckt jetzt beides ab.

Die gedruckte Ausgabe ist 6x9 Zoll gross, also 15,24 x 22,86 cm, 316 Seiten, cremefarbenes Papier. Die vierundzwanzig Diagramme habe ich eigens für den Druck überarbeitet, damit sie auf der Seite so lesbar sind wie am Bildschirm.

Für wen es ist, und für wen nicht

Wenn dein Team Code schneller schreibt, als es ihn in Produktion bringt, ist die Tastatur nicht der Engpass. Dieses Buch hilft, ihn zu finden und zu beseitigen, mit dem, was ohnehin schon da ist: dem Board, auf das ihr jeden Morgen schaut, den Zahlen eures eigenen Flusses, der Code Review am Freitagnachmittag. Geschrieben ist es für Senior-Entwickler, Tech Leads, Architekten und CTOs kleiner Technologieunternehmen, also für Leute, die tatsächlich Code schreiben und keine Zeit für Theorie haben. Die Beispiele sind der Lesbarkeit halber in Python, die Prinzipien gelten in jeder Sprache.

Das Buch ist nichts für Manager auf der Suche nach Motivationsfolien und nichts für Berater auf der Suche nach einem Framework zum Weiterverkaufen. Und es ist kein Buch über das Toyota Production System: Toyota ist die historische Voraussetzung, nicht das Thema.

Wo es zu finden ist

Kindle- und Printausgabe gibt es auf Amazon: 9,99 Euro für Kindle, 19,90 Euro gedruckt. Auf Leanpub bleibt die digitale Fassung, mit Updates wie immer inklusive für alle, die sie schon gekauft haben.

Eine wichtige Klarstellung: Das Buch ist auf Italienisch geschrieben. Eine englische Ausgabe ist noch für dieses Jahr geplant. Spanisch, brasilianisches Portugiesisch und Deutsch hängen davon ab, wie viele danach fragen. Wenn du eine deutsche Ausgabe willst, schreib mir an d.teti@bittime.it und sag mir welche Sprache. Bei genügend Anfragen lasse ich übersetzen.

Wenn dir das Buch geholfen hat, ist eine ehrliche Rezension das Nützlichste, was du tun kannst. Für ein selbstverlegtes Fachbuch wiegen diese paar Zeilen mehr als jede Kampagne.