Frank Westphal ist Schnellsprecher. Wörter wie "Selbstorganisation", "Ganzheitlichkeit" und "osmotische Kommunikation" purzeln aus ihm heraus. Der 33-jährige Hamburger ist Trainer und Berater für "Extreme Programming". Doch wenn er über die Entwicklung neuer Software spricht, klingt das so: "Es geht um eine Veränderung der Kultur. Um einen Paradigmenwechsel." Das soll das Extreme Programming, kurz XP, leisten. Steckt dahinter lediglich eine neue Methode, eine Form der Gruppenorganisation oder eine ganze Philosophie?

"Es geht um die vier Grundwerte Kommunikation, Schlichtheit, Feedback und Mut", sagt Westphal. "Darauf bauen die einzelnen Arbeitstechniken auf, die wiederum alle so extrem wie möglich praktiziert werden." Das hätten wir doch gern ein bisschen konkreter. "Nun, der klassische Ablauf der Software-Entwicklung funktioniert von jeher nach dem gleichen Schema: Zuerst werden monate- oder jahrelang Pflichtenhefte verfasst, die schnell Telefonbuchdicke erreichen", erläutert Westphal. "Dann werden Designs erstellt, Baupläne gemalt, und erst danach sind die Programmierer dran, die schließlich den ganzen Kram haarklein umsetzen sollen, und zwar möglichst bis vorgestern." Ganz zuletzt komme der Kunde wieder ins Spiel, der nun das erste Mal begutachten könne, was da eigentlich gebastelt wurde. "Oft genug stellt er fest, dass er die Software in dieser Form gar nicht gebrauchen kann, weil er sich etwas ganz anderes vorgestellt hat. Oder weil die Wettbewerbssituation sich mittlerweile komplett geändert hat, oder, oder, oder."

Offenbar besteht ein großer Bedarf nach Erneuerung in der Software-Branche. Nirgendwo sonst ist das Scheitern so teuer und gleichzeitig so weit verbreitet. Die Marktforscher von Kienbaum schätzen, dass die Hälfte aller IT-Projekte der öffentlichen Hand fehlschlagen, in der freien Wirtschaft immerhin noch 40 Prozent. Oft bleiben nach jahrelanger Arbeit und Investitionen in Millionenhöhe lediglich Stapel unbrauchbar gewordener Dokumentationen und ein paar Schnipsel Programmcode übrig.

Das wollen die Verfechter des Extreme Programming nun ändern. Bislang wird die neue Methode in Deutschland von einigen hundert Programmierern praktiziert, mit steigender Tendenz. Die Extremprogrammierung soll dabei den Produktionsprozess von Software vom Kopf wieder auf die Füße stellen. "Bei XP verzichten wir ganz auf den theoretischen Überbau eines Pflichtenheftes. Wir halten die Wünsche des Kunden in Form von Storys fest", erläutert Westphal. Eine solche Story spielt nicht in höheren, abstrakten Gedankengefilden, sondern beschreibt eine konkrete Funktionalität in der realen Welt: Eine Chipkarte wird gelesen, eine Zugangsschranke öffnet sich, eine Kreditkartennummer wird abgefragt. Diese Geschichten werden auf altmodischen Karteikarten notiert und gemeinsam mit dem Kunden nach Geschäftswert geordnet. "Wir hatten sogar mal die Idee, statt Karteikarten Briefumschläge zu verwenden und den Kunden in jeden Umschlag genau die Summe Bargeld stecken zu lassen, die ihm diese eine Funktionalität wert ist", treibt Westphal den Gedanken auf die Spitze.

Das Wichtigste wird so quasi zwangsläufig zuerst erledigt und alles Nachrangige nach hinten geschoben. Sollte gegen Ende des Projekts die Zeit knapp werden, dann bleiben lediglich die unbedeutenderen Funktionen auf der Strecke. Der Kunde bekommt dann immer noch ein lauffähiges Programm, das zwar nicht alles hat, was er sich wünschte, mit dem er aber immerhin arbeiten kann.

Nach jedem Veröffentlichungszyklus, der so kurz wie möglich sein sollte, sortiert der Kunde seine Prioritäten neu. "Es ist auch schon vorgekommen, dass der Klient einzelne Karteikarten kurzerhand zerrissen hat", erzählt Westphal, "weil er im Laufe des Prozesses gelernt hat, dass diese Eigenschaften gar nicht benötigt werden."

Die herkömmliche Form der Software-Entwicklung orientiert sich eher am Modell des Hausbaus: Der Bauherr gibt die Pläne frei, schaut zwischendurch vielleicht ein paarmal vorbei und nimmt am Ende das Gebäude ab – oder eben auch nicht. Bei XP gehört der Kunde zum Team, darf sich sogar vor Ort herumtreiben, um in den Prozess einzugreifen. Dienstleister, die sich wünschen, ihre Auftraggeber ständig um sich zu haben – extrem ungewöhnlich.

Im Arbeitsraum eines Extreme-Programming-Teams herrscht ein lebendiges, permanentes Grundgemurmel. Bis auf die sprichwörtlichen Pizzaschachteln entspricht hier nichts dem Klischee vom Programmierer als blassem, kontaktscheuem Eigenbrötler, der sein Leben in selbstgewählter Einzelhaft vor Tastatur und Monitor verbringt. Noch auffälliger ist, dass an jedem Rechner zwei Personen arbeiten, die sich Tastatur, Maus und Monitor teilen. "Pair Programming" heißt dieses Doppelspiel, bei dem die Partner sich regelmäßig mit Schreiben und Gegenlesen abwechseln. "Die Qualität des Programmcodes wird dadurch einfach besser", sagt Jutta Eckstein. Die Münchnerin ist freie Beraterin und Prozesstrainerin für Extreme Programming. "Es handelt sich dabei um eine verschärfte Form des permanenten Reviews. Außerdem arbeitet jeder Einzelne konzentrierter, man lernt fortwährend voneinander, und es wissen immer mindestens zwei Leute über jede Stelle im Code Bescheid."

Aber ist es nicht doppelt so teuer, wenn zwei Programmierer die Arbeit machen, die sonst ein Einzelner erledigt? Diese Frage untersuchte man 1999 an der Universität von Utah. Ergebnis: Verglichen mit einem Einzelkämpfer, benötigte das Doppel zusammen zwar bis zu 60 Prozent mehr Arbeitszeit. Allerdings wurden im Zweiklang auch wesentlich weniger Fehler produziert, das Duo hatte mehr Vertrauen in die eigene Arbeit – und mehr Spaß dabei.

"Für viele ist Paarprogrammierung anfangs sicherlich ein Kulturschock", räumt Jutta Eckstein ein, "wenn sie es aber erst einmal ausprobiert haben, wollen die meisten gar nicht mehr anders arbeiten."

Aber ist das wirklich immer nur spaßig? Der Hamburger Torsten Mumme deutet vorsichtig auch gelegentliche Schwierigkeiten an: "Pair Programming ist so, als würden Sie sich nackt hinstellen. Sie haben keine Geheimnisse mehr und können niemandem etwas vormachen. Das bedarf natürlich auch einer gewissen menschlichen Reife." Auch der Einstieg des 46-Jährigen in die XP-Praxis verlief nicht ganz ohne Mühen: "Als ich damit anfing, musste ich nach 15 Jahren Berufserfahrung Programmieren wieder neu lernen." Das lag allerdings weniger an den Zweierbanden als vielmehr an einem Grundprinzip der XP-Logik: "Jedes Konzept wird nur ein einziges Mal ausgedrückt. Das klappt nur, wenn Sie sehr kleine Teile haben." Einer der Leitsätze der Extremprogrammierer lautet dann auch: "Do it once and only once!"

Anstatt nun solch einen Software-Teil anzufertigen und ihn anschließend auszuprobieren, dreht der XPler die Reihenfolge um: Zuerst bastelt er sich einen Test, der natürlich fehlschlägt, da er nichts zu testen hat. Erst dann wird der eigentliche Code geschrieben, dessen einzige Aufgabe es nun ist, diese Probe zu bestehen. Zuerst kommt der Rahmen, dann das Bild. "Der Test sagt mir vor allen Dingen auch, wann ich fertig bin", erklärt Mumme, "und verhindert, dass ich mir mehr Arbeit mache, als nötig ist."

Auch Frank Westphal will XP nicht als flippige Spaßveranstaltung verstanden wissen. "Viele denken, XP wäre fröhliches Cowboy-Hacking, in Wahrheit ist es eine unglaublich disziplinierte Form der Arbeit, die sehr viel Prinzipientreue verlangt." Und XP sei anstrengend. "Am Ende eines Tages ist jeder von uns wirklich erledigt."

Die XP-Kurse des Informatik-Doktoranden Martin Lippert gehören an der Hamburger Universität zu den beliebtesten Veranstaltungen. "Es gibt aber immer wieder einige, die von ihrem Naturell her Probleme mit dieser Form der Teamarbeit haben, die sind aber ganz eindeutig in der Minderheit", sagt Lippert.

Jutta Eckstein berichtet vom Software-Projekt eines Kunden aus der Versicherungsbranche, bei dem man sie zu Hilfe holte. Vier Millionen Euro und drei Jahre Arbeit waren bereits in den Sand gesetzt worden, als sich ein Krisenstab entschloss, es vielleicht doch einmal mit der merkwürdigen Extremmethode zu versuchen. "Zu diesem Zeitpunkt waren 70 Programmierer mit der Entwicklung beschäftigt, und sie hatten bis dahin nichts Erwähnenswertes produziert." Sie habe dann erst einmal das Team radikal verkleinert. "Wir mussten uns von einer Menge Leute trennen, die in die neue Arbeitsweise einfach nicht zu integrieren waren. Allein das ging schon nicht ohne Widerstände beim Kunden über die Bühne." Kein Wunder, denn in vielen Unternehmen ist bis heute die Anzahl der untergeordneten Mitarbeiter das wichtigste Statussymbol.

Auch der Kunde sei mit seiner neuen Rolle, in der er plötzlich mehr Verantwortung tragen sollte, nicht auf Anhieb zurechtgekommen: "Er beteiligte sich recht halbherzig. Irgendwann machte es aber zum Glück ,klick‘ bei ihm, und er begann zu erkennen, was er auf einmal für Gestaltungsmöglichkeiten hatte." Von diesem Zeitpunkt an lief dann alles jedoch viel leichter. Nach nur sechs Monaten führte die kleine Extremistengruppe das verfahrene Projekt erfolgreich zuende.

Auch die Geschichte vom ersten XP-Praxiseinsatz beginnt mit einem schiffbrüchig gewordenem Großprojekt: 1996 wurde Kent Beck, einer der XP-Väter, vom Autohersteller Chrysler um Unterstützung gebeten, da die Neukonstruktion des hauseigenen Gehaltsabrechnungssystems auch nach mehreren Jahren intensiver Arbeit nicht spürbar vorankam. Beck verordnete den Autobauern einen kompletten Neustart, und bereits nach drei Wochen konnte er ein System vorweisen, das wenigstens in der Lage war, einen Lohnscheck auszudrucken. Es wird erzählt, dieser Scheck hänge heute noch eingerahmt in irgendeinem Chrysler-Büro.

Trotz steigenden Interesses aufseiten der Entwickler und obwohl die althergebrachte Form des Software-Baus "schließlich nachweislich nicht funktioniert", wie Westphal behauptet, stößt der flexible und hierarchiearme Ansatz der Extreme Programmer immer wieder auf Skepsis. Und zwar ausgerechnet dort, wo das meiste Geld durch erfolglose Software-Projekte verbrannt wird – bei Großunternehmen und öffentlichen Auftraggebern.

Das gescheiterte Polizeisystem INPOLneu oder das aktuelle Lkw-Maut-Debakel bildeten nur die Spitze eines Eisbergs dokumentierten Scheiterns. "Nehmen Sie die Banken", sagt Westphal, "die müssen schnell reagieren und stehen unter großem Konkurrenzdruck. Die wären geradezu prädestiniert für XP. Aber ausgerechnet dort ist man momentan relativ weit weg von neuem Denken."

Ein geflügeltes Wort unter Entwicklern besagt, es sei noch nie jemand gefeuert worden, weil er IBM beauftragt hat. "Manche von uns meinen", sagt Westphal, "dass wohl noch eine ganze Management-Generation wegsterben muss, bevor XP auf breiter Ebene akzeptiert wird."