19.3.2026
Wenn sich der Engpass verschiebt
Deutsch · English
Softwareentwicklung verändert gerade ihre grundlegende Natur.
Eine hilfreiche Perspektive darauf kommt aus der Theory of Constraints, entwickelt von Eliyahu M. Goldratt.
Theory of Constraints im Kern
Die Grundidee ist überraschend simpel: In jedem System gibt es meist eine dominante Engstelle, die den Durchsatz bestimmt.
Verbessert man diesen Engpass, verbessert sich das gesamte System. Und wenn er verschwindet, taucht er an anderer Stelle wieder auf. Fortschritt besteht deshalb oft nicht darin, Systeme einfach schneller zu machen. Fortschritt bedeutet, den Engpass zu verschieben.
Goldratt formulierte daraus einen iterativen Prozess:
- Constraint identifizieren
- Constraint maximal ausnutzen
- Alles andere darauf ausrichten
- Constraint erweitern
- Zurück zu Schritt 1 (weil sich der Engpass verschiebt)
Jede ernsthafte Verbesserung eines Systems besteht letztlich darin, diesen Engpass bewusst zu verlagern. In Wissensarbeit kann dieser schnell wechseln oder fragmentieren.
Interessanterweise hilft diese Perspektive auch, eine der einflussreichsten Ideen der Softwareentwicklung neu zu verstehen.
XP als Engpass-Verschiebung
Als Extreme Programming Ende der 90er entstand, lag das Radikale nicht in einzelnen Praktiken wie Pair Programming, Test-Driven Development oder Simple Design.
Das Radikale war das Systemdenken. XP funktionierte, weil sich seine Praktiken gegenseitig verstärkten.
XP war kein Werkzeugkasten. Es war ein zusammenhängendes System von Praktiken, das darauf ausgelegt war, den Durchsatz eines Teams unter Unsicherheit zu maximieren.
Im Kern war XP ein Versuch, die dominanten Engpässe in der Softwareentwicklung systematisch zu stabilisieren. Das Ergebnis war ein Entwicklungsprozess, der Änderungen dauerhaft möglich halten sollte.
Der Engpass verschiebt sich erneut
Mit generativer KI verändert sich diese Landschaft erneut. Und radikal.
Große Sprachmodelle reduzieren viele Aufgaben, die lange Zeit einen erheblichen Teil der Entwicklungsarbeit ausmachten. Modelle können Code generieren, Varianten vorschlagen und Lösungsräume erkunden.
Coding Agents gehen noch einen Schritt weiter. Sie können selbstständig ganze Entwicklungszyklen automatisieren.
Damit verändert sich nicht nur die Geschwindigkeit. Es verändert sich die Struktur des gesamten Systems.
Die technische Umsetzung ist nicht mehr automatisch der limitierende Faktor. Der Engpass liegt zunehmend an anderen Stellen:
- Problemformulierung – Was bauen wir eigentlich?
- Designentscheidungen – Welche Struktur trägt langfristig?
- Evaluation – Ist eine generierte Lösung wirklich gut?
- Verständnis – Kann das Team den Code noch erklären?
Der limitierende Faktor wird zunehmend kognitiv und koordinativ.
Was das für XP bedeutet
XP bewegt sich vom Schwerpunkt Coding hin zur kollektiven Kognition.
Wenn sich der Engpass verschiebt, verschiebt sich auch die Funktion der Praktiken.
Einige werden zentraler.
Einige verändern ihre Rolle.
Und einige entstehen erst jetzt.
Der neue Engpass: menschliches Verständnis
Pair Programming
Cognitive Triad
Pair Programming verbindet zwei Perspektiven: „Driver“ schreibt Code, „Navigator“ behält Struktur und Design im Blick.
Mit großen Sprachmodellen entstehen neue spannende Konstellationen.
Modelle sind starke Sparringspartner. Sie können Code vorschlagen, Varianten diskutieren, Lösungsräume explorieren.
Aber sie verstärken auch Confirmation Bias. Kritische Reflexion kann abnehmen. Falsche Annahmen skalieren schneller als je zuvor.
Mit Coding Agents verändert sich diese Dynamik weiter. Werkzeuge können selbstständig Code schreiben, Tests ausführen und Änderungen als Pull Requests vorschlagen.
In der Extremform entwickelt sich Pair Programming zu einer kognitiven Triade: Customer — Developer — Model.
Agenten machen die engst mögliche Kopplung plötzlich operational.
Der Kunde bringt Problemverständnis. Der Entwickler verantwortet Systemstruktur und Kontext. Das Modell übernimmt Umsetzung und Exploration.
Dabei beschreibt die Triade keine feste Besetzung, sondern Rollen. Mehrere Menschen können beteiligt sein. Modelle können parallel arbeiten oder als Sub-Agents spezialisiert werden.
Der Entwickler wird weniger „Driver“ und stärker „Navigator“ eines Systems, das ganze Lösungsräume ausarbeitet und in großen Strukturen materialisiert.
Ein zentraler Aspekt bleibt Pair Rotation. Im klassischen XP wechselten Paare häufig, teilweise alle 20 Minuten. Ziel war maximaler Wissenstransfer und kollektives Verständnis.
Im KI-Kontext wird diese Idee radikalisiert. Nicht nur Personen rotieren. Auch Rollen rotieren, oft unabhängig voneinander.
Customer, Developer und Model können in unterschiedlichen Kombinationen neu zusammenkommen. Modelle können ausgetauscht, spezialisiert oder als Sub-Agents neu instanziiert werden. Sie können zudem asynchron im Hintergrund operieren, parallel zusätzliche Lösungsräume explorieren und Ergebnisse zurückmelden, sobald sie verfügbar sind.
Pairing wird damit zu einem dynamischen System aus wechselnden Perspektiven, nicht zu einer festen Zusammenarbeit. Möglich wird dies durch etwas grundsätzlich Neues:
Der Denkprozess selbst wird persistent.
Chats, Prompts, Agent-Logs und Entscheidungssequenzen hinterlassen eine Spur: ein externes Protokoll des Entscheidungsbaums.
Dieses Protokoll ist mehr als Dokumentation. Es ist: reviewbar, versionierbar, reproduzierbar (nicht deterministisch, aber hinreichend stabil), teilweise sogar ausführbar.
Damit entsteht ein neues Team-Artefakt: nicht nur Code und Tests, sondern der Weg zur Entscheidung.
Die Spannung zwischen diesen drei Rollen erhöht die kollektive Intelligenz – genau das ursprüngliche Ziel von Pair Programming.
Collective Code Ownership
Radical Code Transparency
Collective Ownership bedeutet: Jeder darf alles ändern.
Mit Coding Agents wird diese Idee radikalisiert.
Ein Agent mit Projektzugriff kann alles verändern, aber nur innerhalb der System-Constraints.
Code manifestiert sich zunehmend als Ergebnis orchestrierter Prozesse. Collective Ownership mit einer Maschine.
Autorschaft wird bedeutungslos.
Entscheidend wird stattdessen kollektives Verständnis. Mit dem Ziel: Maximale Reduktion von Black-Box-Risiko.
Collective Ownership wird zu radikaler Code-Transparenz.
Wenn Code jederzeit durch Menschen oder Agenten verändert werden kann, muss seine Struktur und Motivation für alle nachvollziehbar bleiben.
Im Limit verliert Code seinen Status als langlebiges Asset. In vielen Fällen ist es effizienter, Code neu zu erzeugen, als bestehenden Code zu ändern.
Damit wird Code austauschbar. Zwei Implementierungen sind gleichwertig, solange sie im selben Kontext entstehen und dieselben Tests erfüllen.
Das System besitzt keinen Code mehr – es besitzt stattdessen die Fähigkeit, ihn jederzeit neu zu erzeugen.
Kontrolle über ein driftendes System, das Code erzeugt
Test-Driven Development
Behavior-First Engineering
Tests waren schon immer Spezifikation.
Mit generativer Programmierung werden sie zur Steuerschnittstelle.
Coding Agents können Code erzeugen, verändern und neu strukturieren. Aber sie brauchen klare Grenzen für akzeptables Verhalten.
Test-First erfüllt genau diese Funktion. Tests definieren das gewünschte Verhalten vor der Implementierung und werden zum Vertrag zwischen Mensch und Maschine.
In einer agentischen Entwicklungsumgebung werden Tests zur Programmiersprache, mit der wir Coding Agents steuern.
Der Agent kann Tests lesen, schreiben, ausführen und seine Implementierung so lange anpassen, bis Tests grün sind. Die klassische TDD-Schleife, nur dass ein Teil davon automatisiert wird.
Damit verschiebt sich die Hierarchie: Tests werden zum Primärartefakt. Code wird zur Ableitung.
TDD wird somit noch zentraler, zu verhaltensorientierter Entwicklung.
Es stabilisiert ein probabilistisches System gegen Drift – also gegen das schleichende Auseinanderlaufen von Verhalten unter scheinbar gleichen Bedingungen.
Continuous Integration
Continuous System Verification
Continuous Integration sorgt dafür, dass Integrationsprobleme früh sichtbar werden.
Mit generativer KI steigt die Änderungsrate erheblich.
CI wird zum Immunsystem.
Neben klassischen Tests prüfen Pipelines zunehmend auch, ob grundlegende Systemeigenschaften stabil bleiben.
In einem System, das durch generative Modelle verändert wird, entsteht eine neue Gefahr: probabilistische Drift. Kleine, lokal korrekte Änderungen können das System schrittweise von seiner ursprünglichen Struktur und Semantik wegbewegen.
CI wird zum Mechanismus, diese Drift sichtbar und kontrollierbar zu machen.
Da Änderungen schneller und in größeren Einheiten entstehen, wächst auch ihr potenzieller Impact. Den Blastradius zu begrenzen wird zentral.
XP kannte schon immer Acceptance Tests als Schnittstelle zum Kunden. In einer agentischen Entwicklungsumgebung entsteht eine ähnliche Struktur innerhalb des Teams:
Continuous Integration wird zum Akzeptanztest für den generierten Code, zu kontinuierlicher Systemverifikation.
Das Entwicklungsteam definiert die Kriterien, die ein System erfüllen muss, bevor es als verstanden und integrierbar gilt.
Designstrategie für eine Welt extrem billigen Codes
Refactoring
Continuous Code Assimilation
Refactoring hält Software soft – langfristig.
Im Zeitalter generativen Codes ist Refactoring nicht mehr Aufräumen. Es ist Entropiekontrolle.
Modelle erzeugen funktionierenden Code, doch selten ein kohärentes Design. Unterschiedliche Patterns, redundante Abstraktionen und inkonsistente Strukturen entstehen parallel.
Refactoring wird zum kontinuierlichen Assimilationsprozess.
Generierter Code wird nicht einfach übernommen, sondern aktiv in die Architektur integriert.
Erst durch Refactoring übersetzt das Team maschinell erzeugtes Rohmaterial in sein Systemverständnis. Das Refactoring hilft, generierten Code zu verdauen.
Coding Agents verstärken diese Dynamik weiter. Große strukturelle Änderungen, die einst Tage kosteten, lassen sich mit agentischer Unterstützung in Minuten durchziehen.
Refactoring wird von einer knappen Ressource zu einer billigen Operation und fast kontinuierlichen Aktivität.
Damit solche Systeme stabil bleiben, gewinnen klare Kontextgrenzen an Bedeutung. Konzepte wie Core Models und Bounded Contexts helfen, Systeme in Einheiten zu strukturieren, die sich unabhängig verstehen, generieren und neu zusammensetzen lassen. Sie schaffen Inseln, in denen generativer Code beherrschbar bleibt – mit begrenztem Blastradius und einer Komplexität, die sowohl für Menschen als auch für Modelle im Kontext bleibt.
Gleichzeitig entsteht eine neue Gefahr: Wenn Veränderung zu billig wird, steigt die Versuchung, Struktur permanent zu verschieben, ohne sie wirklich durchdrungen zu haben. Mit generiertem Code steigt die Änderungsrate und strukturelle Konsistenz wird fragiler.
Design wird insgesamt weniger vorausschauend und stärker evolutionär. XP hat das immer behauptet. Agentic Coding macht es realistisch.
Simple Design
Radical Simplicity
Simple Design bedeutet: nur so viel Design wie nötig.
Im LLM-Zeitalter wird diese Praxis noch wichtiger.
Generative Systeme haben eine natürliche Tendenz zur Überkomplexität.
Sie erzeugen zusätzliche Abstraktionen, defensive Strukturen und generische Architekturen.
Generierter Code unterscheidet sich grundlegend: Produzierter Code entsteht nicht mehr 100% aus unserer Intention heraus, sondern als Ergebnis eines stochastischen Prozesses.
Die Aufgabe des Teams verschiebt sich.
Es geht weniger darum, Lösungen zu erfinden. Und mehr darum, Komplexität konsequent zu entfernen.
Simple Design wird zu einer Praxis der radikalen Einfachheit – einem Filter gegen generative Komplexität und somit zu einer der wichtigsten Fähigkeiten überhaupt.
System Metaphor
Shared Mental Model
Die System Metaphor war selbst eine Form eines generativen Modells.
Sie adressierte ein zentrales Problem: Wie schafft man ein gemeinsames Verständnis mit ausreichend Bandbreite, um ein wachsendes System zu tragen.
Diese Funktion wird im Zeitalter generierten Codes wieder wichtig.
LLM-generierter Code kann lokal sinnvoll erscheinen, ohne global kohärent zu sein. Unterschiedliche Teile des Systems folgen dann implizit verschiedenen Architekturideen.
Teams brauchen deshalb wieder stärker ein gemeinsames mentales Modell ihres Systems. Erzählbare Strukturen wie Metaphern, Domänenmodelle und narrative Beschreibungen.
Eine gute Systemmetapher wirkt wie ein kognitiver Kompressionsmechanismus: Sie macht Komplexität erzählbar. Und somit überhaupt erst kollektiv beherrschbar.
In einer Welt mit Coding Agents wird sie zur generativen Architektur.
Coding Standards
Machine-Readable Design
Coding Standards sind nicht mehr nur soziale Konventionen.
Mit KI-generiertem Code verändert sich ihre Rolle deutlich.
Code entsteht heute schneller und in größerer Menge als je zuvor.
Dabei entstehen neben Implementierungen auch zahlreiche Zwischenartefakte. Teams müssen Systeme strukturstabil halten, obwohl ständig neues Material entsteht.
Damit wächst eine neue Gefahr: strukturelle Drift.
Coding Standards werden zu einer Form maschinell durchsetzbarer Design-Disziplin, die verhindert, dass ein System aus ständig neu erzeugtem Code seine Kohärenz verliert.
Sie sind das System Prompt des Repositories: Steuersignale für generativen Code.
Äußerer Wertschöpfungsloop: Earn or Learn
On-Site Customer
Customer-Driven Discovery
Der On-Site Customer bringt den Anforderungsdialog direkt ins Team.
Im Zeitalter generativer KI verschiebt sich diese Rolle am deutlichsten.
Der Kunde kann heute selbst beginnen, den Problem- und Lösungsraum zu explorieren. Mit Hilfe generativer Modelle lassen sich Szenarien durchspielen, Interaktionen testen und mögliche Lösungen skizzieren.
Auch Acceptance Tests verändern sich. Was früher häufig ein Engpass war, kann nun test-first vom Kunden vorbereitet werden. Mit KI-Unterstützung lassen sich Beispiele, Szenarien und Grenzfälle schnell formulieren und iterieren.
Kunde (oder Product Person) wird zum Mit-Entdecker im Suchprozess nach der richtigen Lösung. Die alte XP-Idee der Driving Metaphor bekommt neues Momentum.
Doch in Kombination mit Coding Agents entsteht eine noch tiefere Veränderung. Wenn Modelle aktiv an Exploration und Implementierung teilnehmen, verschiebt sich die grundlegende Einheit der Zusammenarbeit.
Das klassische XP-Paar erweitert sich zur kleinsten funktionsfähigen Einheit moderner Produktentwicklung: Customer — Developer — Model.
Was im Pair Programming als kognitive Triade sichtbar wird, wird hier zur Struktur des gesamten Teams.
Der Kunde bringt Problemverständnis und Hypothesen ein. Der Entwickler verantwortet Systemstruktur, Kontext und Integration. Das Modell ermöglicht schnelle Exploration und Umsetzung.
Der On-Site Customer entwickelt sich weiter zur kundengeleiteten Exploration innerhalb einer kognitiven Triade.
Die Idee des Whole Team wird radikalisiert. Das Team wird zu einem gekoppelten System aus Menschen und generativen Modellen, das gemeinsam den Problem- und Lösungsraum durchsucht.
On-Site Customer wird damit zu etwas, das XP immer angedeutet hat, aber selten vollständig erreicht wurde: Der Kunde wird zum Ko-Designer eines sozio-technischen Systems, das Denken und Implementieren eng miteinander verschränkt.
Planning Game
Continuous Discovery Loop
Das Planning Game synchronisiert Entwicklung und Business.
Mit LLMs verschiebt sich der Engpass fundamental.
Implementierung wird billig. Exploration wird skalierbar. Teams können plötzlich mehr Lösungen erzeugen, als sie sinnvoll bewerten können.
Das eigentliche Risiko ist zu frühes Bauen.
Das Planning Game entwickelt sich zu einem kontinuierlichen Erkenntniszyklus aus Hypothesenbildung, Exploration und Lernen.
Coding Agents verstärken diese Dynamik weiter. Sie können Experimente vorbereiten, Tests ausführen und Ergebnisse analysieren.
Das Planning Game wird teilweise automatisiert. Entwickler und Product Owner planen weniger Arbeit, als sie Erkenntnisgewinn orchestrieren.
Wert entsteht nicht mehr im Schreiben von Code, sondern im Verwerfen von Möglichkeiten.
Wenn Optionen explodieren, wird Selektion zum Engpass. Einschränkungen durchzusetzen wird zu einem zentralen Skill.
Nein wird wichtiger als Ja.
Small Releases
Micro-Experiments
Small Releases reduzieren Risiko, indem Software in kleinen Schritten ausgeliefert wird.
Mit generativer KI wird Codeproduktion extrem billig. Features lassen sich schneller erzeugen als je zuvor.
Das neue Risiko ist Feature-Überproduktion.
Small Releases werden zu kleinen Experimenten. Jede Änderung testet eine Hypothese über Nutzerverhalten, Systemwirkung, Produktwert.
Ein Release ist dann vor allem eines: ein Lernschritt.
Wenn Experimente billig genug werden, ersetzen sie zunehmend Diskussionen. Ein Release kann schneller Klarheit schaffen als ein Meeting.
XP hatte diese Idee immer implizit. Generative Systeme treiben sie nun auf die Spitze.
Nachhaltigkeit als Systeminvariante
Sustainable Pace
Sustainable Cognitive Load
XP zielte immer auf nachhaltiges Arbeitstempo.
Mit KI entsteht jedoch eine neue Versuchung: Geschwindigkeit künstlich zu erhöhen.
Der eigentliche Engpass bleibt jedoch menschliche Urteilskraft.
KI verschiebt den Engpass in den menschlichen Kopf.
Wenn Iterationsgeschwindigkeit steigt, wachsen auch Entscheidungsdruck, Kontextwechsel, mentale Belastung.
Sustainable Pace entwickelt sich zu nachhaltiger mentaler Belastung.
XP schützt damit seine wichtigste Ressource: menschliche Aufmerksamkeit.
Neue Muster
Neben diesen Transformationen entstehen auch neue Muster, die im ursprünglichen XP noch nicht existierten.
Ein besonders interessantes ist Disposable Code.
Wenn LLMs Prototypen extrem schnell erzeugen können, wird Code zu etwas, das man explorativ nutzt und anschließend verwirft. Die gute alte Spike Solution wird zur Kerndisziplin.
Daraus ergibt sich ein weiteres Muster: Reconstructive Programming.
Ein generiertes System dient zunächst als Exploration. Danach wird die eigentliche Implementierung bewusst neu aufgebaut – testgetrieben und aus Verständnis heraus.
Ein dritter neuer Aspekt ist Exploration at Scale.
LLMs erlauben es, viele Varianten eines Lösungsraums zu untersuchen. Die Rolle des Menschen verschiebt sich dadurch von der Produktion zur Auswahl und Entscheidung.
Gerade in unbekannten oder unscharf verstandenen Umgebungen wird diese Fähigkeit entscheidend: Exploration ersetzt dort Spekulation durch überprüfbare Erkenntnis.
XP-Shift durch generative KI
XP verschiebt sich systematisch entlang des neuen Engpasses – von Codeproduktion hin zu Verständnis, Entscheidung, Systemkohärenz.
| XP-Shift | Stabilisierter Engpass |
|---|---|
| kognitive Triade | Qualität von Entscheidungen |
| radikale Code-Transparenz | kollektives Verständnis des Codes |
| verhaltensorientierte Entwicklung | stabil definiertes Systemverhalten |
| kontinuierliche Systemverifikation | Systemintegrität |
| kontinuierlicher Assimilationsprozess | strukturelle Kohärenz des Systems |
| radikale Einfachheit | kognitive Komplexität |
| gemeinsames mentales Modell | kollektives Architekturverständnis |
| maschinell durchsetzbares Design | strukturelle Konsistenz generierten Codes |
| kundengeleitete Exploration | Problem-Solution-Fit |
| kontinuierlicher Erkenntniszyklus | Problemverständnis und Problemwahl |
| kleine Experimente | Lernen aus Nutzerfeedback |
| nachhaltige mentale Belastung | menschliche Urteilskraft |
XP war schon immer menschenzentriert. Es war ein System, das konsequent um den Menschen herum gebaut wurde.
Daran ändert sich auch im Zeitalter generativer KI nichts.
Im Gegenteil: Je mehr wir automatisieren, desto wichtiger wird die Frage, worauf wir diese Systeme eigentlich ausrichten.
XP gibt darauf eine klare Antwort: auf Verständnis, auf Feedback, auf Zusammenarbeit – und auf die Fähigkeit von Menschen, gemeinsam gute Entscheidungen zu treffen.
Generative KI verändert, wie wir Software bauen.
XP stellt sicher, dass wir dabei nicht verlernen, warum wir sie bauen.
Warum XP gerade jetzt relevant ist
XP zielte nie primär auf Geschwindigkeit, sondern auf Stabilität unter Unsicherheit. Genau diese Eigenschaft wird im Umgang mit generativen Systemen zentral.
Wir programmieren nicht mehr primär ein System. Wir programmieren die Bedingungen, unter denen ein System entsteht. Generativer Code macht einige der radikalsten XP-Ideen wieder notwendig.
XP war immer eine Methode zur Maximierung der Lernrate. Ein System aus engen Lernschleifen und bewusst verschobenen Engpässen.
Im KI-Zusammenhang tritt dieser ursprüngliche Kern deutlicher hervor. Generative KI erhöht die Geschwindigkeit der Exploration. Sie vergrößert den Lösungsraum dramatisch. XP sorgt dafür, dass Teams in diesem Raum nicht die Orientierung verlieren.
Modelle und Coding Agents erzeugen enorme Mengen Code. Doch genau diese Produktionsmaximierung erzeugt neue Risiken. Große Mengen Code können so schnell degenerieren wie sie generiert werden. Ohne starke Feedbackmechanismen wächst Komplexität unkontrolliert über unsere Köpfe hinweg.
Die neuen Engpässe
Der Engpass verschiebt sich dadurch. Während Maschinen immer schneller Code erzeugen, stabilisieren die XP-Praktiken die Ressourcen, die sich nicht einfach automatisieren lassen:
- Verstehen
- Entscheiden
- gemeinsame mentale Modelle
- kohärente Systemstruktur
Mit anderen Worten: In einer Welt, in der Code billig wird, werden Verständnis und Urteilskraft zur knappsten Ressource.
Genau hier greifen die klassischen XP-Praktiken.
Der eigentliche XP-Shift
Extreme Programming wollte ursprünglich eine Sache erreichen: Änderungen jederzeit billig halten.
Wenn Codeproduktion billig wird, verschiebt sich der Preis. Dann wird Verständnis teuer.
Die neue Mission lautet deshalb:
Die Kosten des Verstehens flach halten.
Die Produktion von Code ist nicht mehr der Engpass.
Die Produktion von Bedeutung ist es.
Wenn du XP im Kontext von KI erprobst, würde ich mich freuen, von dir zu hören: f@frankwestphal.de
Wenn dir dieser Text etwas gebracht hat, kannst du meine Arbeit mit einer Spende unterstützen. Ich entwickle diese Ideen weiter und möchte daraus eine kleine Serie machen.
5.5.2005
Extreme Programming:
Extreme Programming:
Auf ein Neues
von Frank Westphal und Tammo Freese
erschienen in der InfoWeek 09/2005
Vor noch fünf Jahren galten seine Ideen zur Softwareentwicklung als unglaublich extrem. Heute sind viele der Extreme Programming (XP) Praktiken akzeptiert. Mit einer von Grund auf neu geschriebenen, zweiten Auflage seines Bestsellers "Extreme Programming Explained" zeichnet Kent Beck ein aktuelles Bild: Die vielleicht effektivste und zugleich menschlichste Softwareentwicklungsmethodik ist gerade noch effektiver und menschlicher geworden.
Das neue Extreme Programming schlägt leisere Töne an. Die Kinderkrankheiten hat es hinter sich gebracht, es ist erwachsen geworden. Im Kern finden sich nach wie vor die vier groß geschriebenen Werte: Einfachheit, Kommunikation, Feedback und Mut. Schon seit frühesten Tagen lag XP als fünfter Wert Respekt zu Grunde, der in der neuen Fassung nun explizit seinen Einzug ins Wertesystem feiert.
Mehr pragmatisch und weniger dogmatisch
Die wohlbekannten XP-Praktiken sind aus den gesammelten Erfahrungen der vergangenen Jahre sowohl verbessert, vereinfacht und konkretisiert als auch verallgemeinert worden. Fanden sich im ursprünglichen XP nur ein Dutzend Praktiken, hat sich die Anzahl mit der Überarbeitung verdoppelt. Der Grund zur scheinbaren Zunahme der schlanken Methode ist, dass die Menge der Praktiken jetzt in Pflicht und Kür aufgeteilt ist: Während die primären Praktiken meist isoliert anwendbar sind und deshalb in jedem Prozess zu einer sofortigen Verbesserung führen können, setzen die weiterführenden Praktiken auf den Grundstock auf und führen den agilen Prozess schließlich an seine Leistungsgrenzen. Nichtzuletzt durch diese Abschwächung gelingt es dem runderneuerten XP, einerseits die Eingangsschwelle für jedermann zu senken und andererseits in Anwendungsbereiche vorzudringen, für die es initial nicht geeignet schien. Als Beispiele seien hier nur große und verteilte Projekte genannt.
Bei Programmierern beliebt
Vieles hat sich durch XP verändert: Einige XP-Praktiken werden mittlerweile im Studium vermittelt. Automatisiertes Testen ist zum festen Bestandteil der Entwicklungskultur geworden. Zur inkrementellen Verbesserung des Softwaredesigns stehen Entwicklungsumgebungen mit automatisierter Refactoringunterstützung zur Verfügung. Und Pair Programming wird heute viel einfacher akzeptiert. Während sich das leichtgewichtige XP bislang nicht gegen schwergewichtige Prozesse durchsetzen konnte, scheint es vor allem in kleineren Unternehmen Erfolg zu haben. Der Grund dafür ist sicherlich, dass dem vorherrschenden chaotischen "Code und Fix" Vorgehen vieler Softwareunternehmen mit XP's gesundem Menschenverstand schnell zu einem massiven Produktivitätsgewinn verholfen werden kann.
Im Management wenig Durchdringung
War XP auch die erste agile Methode, die von einer breiten Masse wahrgenommen wurde, steht ihr Bekanntheitsgrad in keinem Verhältnis zu ihrem Verbreitungsgrad. Ganz anders sah dies aus, als das erste Buch erschien. Zu Zeiten der Dotcom-Ära gedieh XP überaus prächtig, schließlich passte seine Philosophie hervorragend in die damalige Projektlandschaft von kleinen schnellen Teams in einer Welt mit sich rapide verändernden Anforderungen. Mit dieser Ära ging teils auch der für innovative, sich selbst organisierende Projektteams nötige kulturelle Nährboden verloren. Die Verbreitung von XP fand darin ihre organisatorischen Grenzen. Und während der Name gerade in Programmiererkreisen große Aufmerksamkeit erzeugte, stieß er im Management übel auf. Zudem war XP aus Sicht der Programmierer beschrieben, so dass die Änderungen in der Projektabwicklung aus Management- und Kundensicht nicht als Chancen, sondern lediglich als Risiken wahrgenommen wurden. Dieses Bild will mit dem neuen XP korrigiert werden. Denn mit seinem erweiterten Rollenmodell werden auch Nicht-Programmierer in das XP-Team eingebunden.
Lean Thinking
Auffällig ist, wie viele Anleihen aus dem Lean Manufacturing herausgearbeitet wurden. Gerade die Parallelen zum Toyota Produktionssystem, der Just in Time Fertigungsstrategie des führenden japanischen Autobauers, können ein Weg sein, den XP-Ideen im Management zu einer höheren Akzeptanz zu verhelfen. Über viele Jahre standen nur solche Fragen wie die Effizienz von Pair Programming, Testgetriebener Entwicklung oder eines Kunden vor Ort im Zentrum der Diskussion. Dabei bekäme es der weiteren Akzeptanz besser, würde sich die Aufmerksamkeit in heutigen Zeiten des Kostendrucks mehr auf übergeordnete Themen wie Wertschöpfungsketten, Return on Investment, Zero Defects und Time to Market verlagern. Denn durch die Einführung neuer Praktiken wie der Ursachenforschung zur Fehlerprävention sowie der Anwendung der Theory of Constraints zur Vermeidung von Flaschenhälsen gelingt es XP, die nötige, am japanischen Kaizen orientierte Philosophie der kontinuierlichen Prozessverbesserung zu etablieren. Wie weit man jedoch mit dem extremen Programmieren gehen will, bleibt insbesondere nach Aufweichung der Praktiken jedermann selbst überlassen. XP stellt in sich eh kein Ziel dar, sondern ist und bleibt ein Weg zur Verbesserung der Softwareentwicklung.
