Extreme Programming (XP)

Bild: Wikimedia Commons / Lisamarie Babik - CC BY 2.0

Bei der heutigen "Monokultur" von Scrum, Kanban und SAFe mag man es kaum noch glauben, aber gab eine Zeit, zu der keines dieser drei das dominierende agile Framework war. Um das Jahr 2000, also zu der Zeit als das agile Manifest geschrieben wurde, war ein anderes das bekannteste: Extreme Programming (XP). Damals noch so bekannt, dass es in den Dilbert-Comics veralbert wurde, sank es später zu einem nur noch schwach erinnerten Mythos herab. Höchste Zeit ihn hervorzuholen und zu entstauben.

Ein Sprung zurück in der Zeit: 1996 befindet sich beim amerikanischen Chrysler-Konzern ein IT-Projekt der Lohnbuchhaltung in der Krise, drei Jahre nach Beginn der Software-Entwicklung konnte noch kein einziges Gehalt mit dem neuen System ausgezahlt werden. Die Probleme sind dieselben die sich bis heute in IT-Grossprojekten finden - die Integration von Entwicklungs-Branches führt zu schwerwiegenden Merge-Konflikten, Tests, Bugfixes und Releases erzeugen massive Aufwände, die Kommunikation zwischen Fachabteilungen und Entwicklern ist voller Missverständnisse und Konflikte.

Neu zum Projekt gestossene Projektmanager und Entwickler untersuchen die Ursachen und finden ein Muster - da alle der gerade genannten Tätigkeiten für die Beteiligten anstrengend und unerfreulich sind, werden sie so lange wie möglich aufgeschoben. Bedingt dadurch wachsen sie zu riesigen Arbeitspaketen heran, die zum Zeitpunkt ihrer Umsetzung zum Teil bereits veraltet sind und durch ihre Grösse, Unübersichtlichkeit und Vernetztheit selbst zu ernsthaften Fehlerquellen werden.

Die gemeinsam erarbeitete Lösung für dieses Problem ist das Durchführen dieser Tätigkeiten in immer kürzeren Abständen und immer kleineren Umfängen. Die Idee dahinter: kleine Arbeitspakete sind übersichtlicher, weniger in sich vernetzt und werden bei Fehlern tendenziell kleinere Bugs erzeugen, kurze Abstände sorgen für häufige Wiederholung und damit auch für mehr Übung, für engere Zusammenarbeit, intensivere Kommunikation und als Folge dessen für weniger Missverständnisse.

Wichtig für das Verständnis dieser Entstehungsgeschichte ist, dass in all dem wenig Neues steckte. Code Reviews, Merges, Tests, Releases und Kommunikation mit Kunden und Auftraggebern gibt es, seitdem Software entwickelt wird. Das Ungewöhnliche war die aus damaliger Sicht unglaubliche Beschleunigung. Aus einmal pro Quartal oder pro Jahr wurde mehrmals pro Woche oder sogar pro Tag. Diese extreme Häufigkeit gab dem Ganzen ihren Namen: Extreme Programming.

Die einzelnen Praktiken von XP sind vor diesem Hintergrund zu verstehen: Pair Progamming ist die extrem intensive Zusammenarbeit von zwei Entwicklern, Unit Tests sind extrem kleine Validierungen von Funktionalität. Iterationen (ein- bis dreiwöchige Zeiträume) sind extrem kurze Lieferzyklen, Refactorings sind extrem häufige Überarbeitungen der Codebasis, etc. Dass sie für XP nötig sind, ist offensichtlich, und dass sie so zentral sind macht es zu einem der IT-spezifischsten unter den agilen Frameworks.

Vermutlich ist dieser sehr starke IT-Bezug auch einer der Gründe dafür, dass Extreme Programming der ganz grosse Durchbruch verwehrt geblieben ist. Bereits die "sichtbaren Praktiken" wie Pairing und Reviewing sind in Berater- und Management-Präsentationen nur schwer zu vermitteln, auf "unsichtbare Praktiken" wie Test First und Refactoring trifft das um so mehr zu. Und selbst wenn sie verstanden werden, ist ihre Einführung ungleich schwerer als die neuer Rollen und Meetings.

Aus diesen Umständen ergibt sich auch ein fast schon tragisches Phänomen: das was von XP in andere Frameworks übernommen wurde, ist in der Regel nicht der IT-spezifische Kernbereich, sondern es sind die im Vergleich weniger wichtigen Prozess-Elemente. Das heisst nicht, dass diese (v.a. User Stories, Story Points, Planning Poker und Onsite Customer) nicht gut und richtig wären, aber dass vor allen sie in Scrum und SAFe integriert wurden, vermittelt ein schiefes Gesamtbild ihres Ursprungs.

Noch einmal anders gesehen kann man aber auch Positives daran finden, dass Extreme Programming aus dem Scheinwerferlicht verschwunden ist. Da aus Softwareentwicklungssicht kaum ein anderes Framework so passend zur IT ist, kann man seinen Bekanntheitsgrad als Indikator dafür benutzen, ob und wie vertieft sich ein Entwicklungsteam mit dem Thema Agilität auseinandergesetzt hat. Wenn XP dort ein Begriff (oder sogar in Anwendung) ist, kann man als Agile Coach direkt zu den fortgeschrittenen Themen springen und kann auf Grundlagenarbeit verzichten.

Quelle: Twitter