Mary Poppendieck: Schluss mit vollen Warteschlangen

8 Min. Lesezeit

Sie machte die Wartezeit unübersehbar

Lean kam nicht als Fabrikkostüm für Software

Mary Poppendieck entdeckte Lean nicht in einem Zertifizierungskatalog, um anschließend Fabrikvokabular auf ein Backlog zu kleben. Sie begann als Programmiererin für Prozesssteuerung, leitete später die IT in der Fertigung und arbeitete in der Produktentwicklung. In ihrem Rückblick auf diesen Berufsweg beschreibt sie ihre frühe Programmierarbeit bei Bell Labs, automatisierte Fahrzeugsteuerungen bei General Motors und Steuerungssysteme für die Maschinen, mit denen 3M Klebeband herstellte.

Diese Geschichte zählt, weil sie nie verlangte, Software zum Fließbandprodukt zu machen. Softwareentwicklung enthält Entdeckungsarbeit. Während Teams bauen, lernen sie, was Kunden brauchen, was das System leisten kann und welche Annahmen falsch waren. Die brauchbare Lehre aus Lean bestand darin, dieses Lernen voranzubringen, statt es unter Arbeitsvorräten, Übergaben und voreiligen Festlegungen zu begraben.

Mary und Tom Poppendieck gaben dieser Übertragung 2003 mit Lean Software Development: An Agile Toolkit eine dauerhafte Form. Es folgten Bücher über Umsetzung, Führung und die Lean-Denkweise. Ihre Arbeit verband Kundennutzen, Arbeitsfluss, Qualität, Lernen, Respekt vor Menschen und den Blick auf das Gesamtsystem. Außerdem gab sie Verantwortlichen für Software Worte für ein längst spürbares Problem: Alle wirkten beschäftigt, doch das Unternehmen wartete monatelang auf Antworten.

Die meiste Zeit wartet die Arbeit

In ihrer Analyse des vermeintlichen Gegensatzes zwischen Qualität und Geschwindigkeit von 2005 beschreibt Poppendieck, wie sich der Weg von einer Kundenanfrage bis zur bereitgestellten Software abbilden lässt. In den Wertstromanalysen ihrer Kurse wurde typischerweise weniger als ein Fünftel dieser Gesamtzeit tatsächlich an der Anfrage gearbeitet. Den Rest verbrachte sie in einer Warteschlange.

Dieses Muster lässt sich schmerzhaft leicht wiederholen. Eine Änderung am Arbeitsablauf wartet auf eine Produktentscheidung. Die Entscheidung wird zum Ticket und wartet auf ein Team. Der Code wartet auf Review. Das Review wirft eine Integrationsfrage auf, und die Arbeit wartet auf einen Anbieter. Tests beginnen am Ende, finden einen Fehler und schicken die Änderung erneut durch denselben Hindernisparcours. Jede Abteilung kann eine ordentliche Auslastung melden, während der Kunde nichts bekommt.

Das Management reagiert oft, indem es noch mehr ins System drückt. Mehr Umfang. Noch eine Initiative. Jeder Spezialist soll voll ausgelastet bleiben. Ein KI-Werkzeug kaufen, damit Entwickler schneller Code produzieren. Die Warteschlangen wachsen, der Abstimmungsbedarf steigt und die Durchlaufzeit wird länger. Dann plant jemand einen Workshop über Velocity.

Die Antwort aus Lean ist weniger theatralisch. Begrenzen, was ins System gelangt. Eine kleine, wertvolle Änderung fertigstellen. Sehen, wo sie wartet. Diesen Engpass beseitigen. Wiederholen.

Das macht ein Board voller bunter Karten noch lange nicht zu Lean. Ein Board kann einen Stau mit bewundernswerter optischer Einheitlichkeit darstellen. Die Arbeit kommt erst voran, wenn die Organisation die Bedingungen ändert, die den Stau erzeugen.

Lokale Produktivität kann die Umsetzung beschädigen

Die meisten Organisationen messen Einzelteile, weil sich dafür leicht Zuständigkeiten vergeben lassen. Analysten sollen mehr Anforderungen erstellen. Entwickler sollen mehr Tickets schließen. Tester sollen mehr Fehler finden. Der Betrieb soll die Stabilität durch weniger Releases schützen. Der Einkauf soll die Anbietersätze drücken. Jeder Bereich kann sein Ziel erreichen, während die Umsetzung zwischen ihnen zusammenbricht.

Poppendiecks Alternative besteht darin, das Ganze zu optimieren. Entscheidend ist der Weg vom Bedarf zum brauchbaren Ergebnis: Geschäftsentscheidungen, Entwicklung, Tests, Bereitstellung, Betrieb, Support und das Lernen aus Kundenfeedback. Ihr Essay über Produktivität in der Softwareentwicklung stellt die Frage, wie wirksam aus Ideen wertvolle Software entsteht, statt zu zählen, wie viele Codezeilen Menschen produzieren.

Stellen wir uns ein Logistikunternehmen vor, das die Bearbeitung von Ausnahmefällen automatisiert. Der Betrieb weiß, welche Fälle einen Vormittag ruinieren. Ein Anbieter verantwortet die Transportplattform. Ein interner Entwickler pflegt die Integration. Die Finanzabteilung bestimmt die Regeln für Entschädigungen. Arbeitet jeder aus seiner eigenen Warteschlange, bekommt das Unternehmen beeindruckende Betriebsamkeit und langsames Lernen. Niemand verantwortet das vollständige Ergebnis.

Bringen wir diese Menschen stattdessen für ein kleines, durchgängiges Ergebnis zusammen: einen teuren Ausnahmefall erkennen, richtig zuordnen, das Ergebnis prüfen und im Einsatz beobachten. Die Grenzen der Software werden sichtbar. Die Entscheidungen ebenfalls. Das Team kann nun lernen, ob die Automatisierung hilft, bevor es jeden vorstellbaren Ausnahmefall in eine kleine Privatbürokratie programmiert.

So sieht Softwarefluss aus, wenn das Führungsprinzip den Code und die Arbeitsorganisation erreicht. Entweder verbessert sich der gesamte Weg, oder der Kunde wartet weiter.

Qualität gehört in den Arbeitsfluss

Lean wird regelmäßig zum Kostensparspruch verstümmelt. Leute streichen, Reserven reduzieren, mehr Leistung verlangen und die entstehende Fragilität effizient nennen. Poppendiecks Arbeit weist in die Gegenrichtung. Qualität muss in die Arbeit eingebaut werden, weil spät entdeckte Fehler Warteschlangen, Nacharbeit und verspätetes Lernen erzeugen.

Ihr Essay von 2005 rückt Tests nah ans Programmieren und verbindet sie mit häufiger Integration und automatisierten Prüfungen. Das Prinzip reicht über eine bestimmte Testpraxis hinaus. Unsicherheit dort aufdecken, wo sie entsteht. Eine Geschäftsregel als Beispiel festhalten, solange die Menschen verfügbar sind, die sie verstehen. Eine Integration prüfen, solange die Änderung klein ist. Bereitstellungen so routiniert machen, dass der Releasetag weder ein Gremium noch günstigen Wind braucht.

Hier trifft Mary Poppendiecks Geschichte auf Kent Becks kurze Feedbackschleifen. Beck gibt den Entwicklungsrhythmus vor: testen, ändern, refaktorieren, lernen. Poppendieck erweitert den Blick. Wartet die getestete Änderung trotzdem zwölf Tage auf Freigabe, hat die Organisation einen Teil des Arbeitsflusses geschützt und das Ganze vernachlässigt.

Geschwindigkeit und Qualität sind keine natürlichen Gegner. Verzögerung und späte Erkenntnisse lassen sie so aussehen. Liegen die Belege näher an der Entscheidung, kommt ein Team schneller voran, weil es weniger Zeit darauf verschwendet, das Falsche zu bauen, weiterzureichen, erneut zu entdecken und zu reparieren.

Entscheiden, bevor eine wertvolle Option wegfällt

Traditionelle Projektsteuerung mag frühe Gewissheit. Den gesamten Arbeitsablauf spezifizieren. Die Plattform auswählen. Das Integrationsdesign festschreiben. Das ganze Programm schätzen. Änderungen so teuer machen, dass niemand mehr erwähnt, was er dazugelernt hat.

Lean Software Development behandelt voreilige Gewissheit als Verschwendung. Eine Entscheidung ohne die nötigen Informationen ist bloß eine Vermutung mit Termindruck. Poppendieck plädierte dafür, detaillierte Anforderungen näher an der Umsetzung festzulegen. Dann weiß das Team mehr und muss keine Warteschlange von Änderungen an alten Vermutungen pflegen.

Diese Idee lässt sich leicht missbrauchen. „Später entscheiden“ darf keine Erlaubnis sein, ein Team zu blockieren, während Führungskräfte einer unbequemen Wahl ausweichen. Der letzte verantwortbare Zeitpunkt liegt unmittelbar bevor eine wertvolle Option wegfällt, nicht am Nachmittag danach. Teams brauchen klare Grenzen, schnellen Zugang zu Entscheidern und kleine Experimente, die bessere Belege liefern.

Bei einem neuen KI-gestützten Ablauf zur Schadenbearbeitung könnte das heißen: Datenschutzgrenzen, Nachvollziehbarkeit und menschliche Eingriffsmöglichkeiten früh festlegen, die Wahl des Orchestrierungsframeworks aber vertagen. Den riskantesten Schadenfall mit den tatsächlichen Sachbearbeitern testen. Lernen, wo das Modell scheitert. Es austauschbar halten. Die Architektur sollte erst Erkenntnisse ermöglichen und dann dauerhafte Festlegungen.

KI füllt die Warteschlange im Maschinentempo

KI-Werkzeuge zum Programmieren machen Poppendiecks Lehre aktueller. Sie können die Zeit verkürzen, die eine plausible Umsetzung braucht. Schnelleres Programmieren klärt aber keine Produktentscheidung, bringt keine Abteilungen zusammen, gewährt keinen Produktionszugang, repariert keine Anbieterbeziehung und legt nicht fest, welche Fehler das Unternehmen akzeptieren kann. Werkzeuge können dabei helfen. Entscheidungsbefugnis und Verantwortung müssen trotzdem klar zugeordnet sein.

Warten bereits zwanzig Änderungen auf Review, sind vierzig weitere keine Beschleunigung. Erfolgt die Bereitstellung monatlich, weil das System fragil ist, vergrößert schnellerer Code den Arbeitsvorrat. Verantwortet niemand ein intern mit KI gebautes Werkzeug, nachdem sein Ersteller den Job wechselt, hat die Organisation Software produziert, aber keinen verlässlich betriebenen Dienst.

Das ist die moderne Form lokaler Optimierung. Das Programmieren wird schneller, also erklärt die Führung die gesamte Umsetzung für schneller. Die Wirklichkeit stellt die vollständige Rechnung: mehr Reviews, mehr Tests, mehr Abhängigkeiten, mehr Verhalten im Betrieb und mehr Vermutungen, die jemand verwerfen muss.

Die brauchbare Frage lautet nicht, wie viel Code der Agent produziert hat. Fragen wir, ob eine wertvolle Änderung früher in den Einsatz kam, mit genügend Belegen für Vertrauen und genügend Verantwortung für ihren Betrieb. Wenn KI ein Unternehmen für Software verantwortlich macht, verhindert Lean-Denken, dass billige Produktion zu teurem Stau wird.

Die Entscheidung der Führung

Ein CTO repariert den Arbeitsfluss nicht, indem er Entwickler zu mehr Konzentration auffordert. Einige Engpässe stecken im Code. Andere in Budgets, Freigabestrukturen, Teamgrenzen, Anbieterverträgen, Releasevorgaben und der Unentschlossenheit der Führung. Die Führung verantwortet die Bedingungen rund um die Arbeit.

Mit einer wichtigen Anfrage beginnen. Ihren Weg vom Bedarf des Fachbereichs bis zur Nutzung des Ergebnisses verfolgen. Die Wartezeit zählen. Die Übergaben finden. Fragen, warum Tests genau dort stattfinden. Erkennen, welche Entscheidung keinen Verantwortlichen hat und welcher Spezialist zum Pflichtstopp für jede Änderung geworden ist.

Dann einen echten Engpass beseitigen. Weniger Arbeit gleichzeitig beginnen. Die Menschen, die das System bauen, betreiben und nutzen, auf dasselbe Ergebnis ausrichten. Einem Team Entscheidungsspielraum für einen Dienst geben, den es versteht und betreuen kann. Qualitätsprüfungen vorziehen. Eine Abhängigkeit auflösen, statt sie mit einem Abstimmungsritual zu umgeben.

Poppendieck warnte 2019 vor Transformationen um ihrer selbst willen. Organisationen brauchen keine neue Identität namens „Wir machen jetzt Lean“. Sie brauchen Produkte und Dienste, die Kunden schätzen, ein Arbeitsumfeld, das menschliches Urteilsvermögen nutzt, und ein System, das lernt, bevor der Markt die Lektion für sie beendet.

Ihr bleibender Beitrag war, Verzögerung sichtbar zu machen. Ein Team kann beschäftigt wirken, während der Nutzen in einer Warteschlange verhungert. Sobald Führungskräfte das sehen, entscheiden sie selbst, ob sie diese Schlange weiter füttern.

Quellen

• An Interview, Mary Poppendieck
• Software Development Productivity, Mary Poppendieck
• Breaking the Quality-Speed Compromise, Mary Poppendieck
• Autorenbiografie von Mary Poppendieck, O’Reilly
• Lean Software Development: An Agile Toolkit, Addison-Wesley
• Implementing Lean Software Development, Addison-Wesley