Agile Softwareentwicklung: Extreme Programming (XP) erklärt

Man soll sich immer Fragen "Wie sieht die einfachste Lösung aus?".

Einfachheit ist schwierig. Es ist immer leichter, Dinge "einfach so" umzusetzen. Dann kommen aber fast immer komplizierte Lösungen dabei raus. Auch wird häufig zu weit in die Zukunft gedacht und dies direkt mit umgesetzt. So werden oft viele Dinge umgesetzt, die wahrscheinlich niemals so gebraucht werden.

XP  ist hier eine Wette. Man wettet darauf, heute etwas Einfaches zu tun und morgen etwas mehr zu zahlen, wenn man es ändern muss, statt heute etwas Kompliziertes zu tun, das vielleicht niemals eingesetzt wird.

Feedback ist zentral. Vom System, vom Kunden, von anderen Entwicklern oder vom Nutzer.

Feedback vom System ist unendlich wertvoll für einen Programmierer. Das System sollte so entwickelt werden, dass es innerhalb von Sekunden Feedback über seinen Status gibt.

Kunden sollten so eingebunden sein, dass sie immer Feedback zum aktuellen Stand und den Fragen der Programmierer geben können.

Die Entwickler sollten sich gegenseitig häufig, wertvolles Feedback zu ihrer Arbeit geben.

Der Nutzer sollte so schnell wie möglich das Produkt nutzen können um Feedback geben zu können.

Viele Dinge, die gute Programmierer tun müssen, erfordert Mut. Ein Projekt, dass sich verrannt hat, muss zum Teil erneut angegangen werden. Code der nicht mehr gebraucht wird, muss weggeschmissen werden. Ein Problem muss dem Kunden so schnell wie möglich mitgeteilt werden. All diese Dinge brauchen Mut. Sie müssen aber gemacht werden. Werden sie herausgezögert, werden sie immer schwerwiegender und gefährden die gesamte Arbeit.

Alles beim XP sollte so angelegt sein, dass jeder so unmittelbares Feedback wie möglich, für seine Arbeit bekommt.

Hier können es für die Entwickler durch automatisierte Tests Sekunden oder Minuten sein. Für Rückmeldung vom Nutzer sollten nicht mehr als ein paar Tage oder Wochen vergehen. Der Kunde sollte tägliche Rückmeldung geben können.

Umso schneller und gleichmäßiger - umso besser.

Jedes Problem soll so behandelt werden, als wäre es lächerlich einfach zu lösen.

Die Zeit, die bei den 98% der Problemen gespart wird, bei denen dies zutrifft, kann dann für die 2% wirklicher Probleme verwendet werden.

Programmierer akzeptieren dies fast nie. Sie planen für die Zukunft und bauen Alles so abstrakt und "wiederverwendbar", dass eine Änderung dieser Angewohnheit enorm schwierig sein kann.

Statt zu Planen, ist die Fähigkeit, Komplexität bei Bedarf hinzuzufügen zu können, viel wichtiger. Sie sollte besonders trainiert werden.

Große Brocken sind schlechter umzusetzen, als kleine Stückchen. Daher sollte Software immer inkrementell umgesetzt werden. Kleine, funktionierende Einheiten, die separat getestet werden können.

Jedes Problem wird durch eine Reihe kleiner, aber wirkungsvoller Änderungen gelöst.

Die beste Strategie ist diejenige, die das dringendste Problem löst und gleichzeitig die meisten Optionen offen hält.

Veränderungen haben einen Grund. Fast immer ist dies ein guter Grund. Daher sollten Veränderungen begrüßt werden. Sie gehören zur Arbeit eines Entwicklers einfach dazu.

Arbeit die schlampig durchgeführt wird, macht keinen Spaß. Dem Programmierer nicht, dem Kunden nicht, dem Nutzer nicht. Niemanden.

Daher sollten die Ansprüche an die Qualität der Arbeit niemals verringert werden.

Grundlage jeder Softwareentwicklung ist das Programmieren. Wir als Entwickler müssen verstehen, wofür Programmieren da ist. Es setzt Gedanken um in ausführbare Programme.

Es dient als wunderbares Kommunikationsmittel.

Wenn wir etwas programmiert haben, müssen wir testen, ob es auch das ist, was wir uns gedacht haben. Hierzu nutzen wir natürlich automatische Tests. XP sagt: Was nicht automatisch getestet ist, gibt es nicht.

Als Entwickler müssen wir uns daher mit automatisierten Tests auseinandersetzen. Und zwar genauso intensiv, wie wir uns mit dem Programmieren auseinandersetzen.

Wenn Ideen ohne Programme in die Welt kommen könnten - würden wir Entwickler ganz schnell arbeitslos sein. Wir setzen Ideen anderer Leute um - und zwar für andere Leute.

Wir haben Ahnung vom Programmieren - aber erstmal keine Ahnung von der Domäne unserer Kunden und Nutzern.

Daher müssen wir zuhören können. Den Kunden, den Managern, den Nutzern und den Kritikern.

Zuhören ist so wichtig, dass wir hier unbedingt enorme Kompetenz aufbauen sollten.

Einfach nur zuhören, Test schreiben und Programmieren klappt so nicht. Irgendwann kommt so ein Vorgehen an seine Grenzen.

Ohne sich Gedanken über die interne Struktur eines Codes zu machen, stößt diese schnell an Grenzen. Neue Features sind nur noch enorm aufwändig zu verwirklichen. Bugs werden nicht mehr gefunden. Der Code wird unverständlich und irre kompliziert.

Daher müssen wir Entwickler lernen, wie man gutes Design - eine saubere und gute Struktur des Codes - entwerfen kann.

Dies müssen wir von Zeit zu Zeit auch anwenden.

Statt den Programmierern zu sagen, wie sie Etwas zu erledigen haben, sollte man sich darauf konzentrieren, Strategien zu lehren, wie man lernt und wie man entscheiden kann, was wie zu erledigen ist.

Man soll mit knappem Budget rechnen. Dieses zwingt Programmierer und Kunden dazu, Anforderungen und Ansätze zu beschneiden. Sie werden ermutigt, möglichst gute und einfache Arbeit zu liefern.

Wenn die Ressourcen zu knapp sind - es sich nicht mal ein wichtiges Problem damit lösen lässt - ist das Projekt nicht interessant.

Man merkt dadurch oft, dass man mit viel weniger Ressourcen auskommt, als erwartet.

Viele Entwickler wollen, dass ein Projekt nicht scheitert. Sie tun Alles, damit das Projekt nicht scheitert. Wenn es scheitert, dann soll es wenigstens nicht die eigene Schuld sein - schließlich hat man sich an alle Regeln gehalten.

Dieses Prinzip sagt: Tu alles, damit das Projekt ein Erfolg wird. Dies ist die richtige Sichtweise.

Entscheidungen, die ohne Überprüfung gefällt werden, haben eine Wahrscheinlichkeit, dass sie falsch sind.

Daher sollten wichtige Entscheidungen durch gezielte Experimente überprüft werden.

Wenn z.B. über das Design der Software gesprochen wird, sollte das Ergebnis eine Reihe von Experimenten sein, deren Ergebnisse, dann zum Design führen - statt eines fertigen Designs, dass nur "besprochen" wurde.

Man sollte auf Augenhöhe und mit Professionalität kommunizieren. Hier sollte man auch in der Lage sein, sein Fachgebiet zu erklären. Vor allem die Konsequenzen, die aus bestimmten Handeln entstehen, sollen kommuniziert werden.

Extreme Programming geht davon aus, dass ein Team aus erfahrenen Entwicklern, von sich aus instinktiv gute Software entwickeln kann. Diese Instinkte, diese Intuition sollte man unbedingt nutzen.

XP - und auch andere Methoden - sollten nur dazu dienen, dem Team die richtige Richtung zu zeigen und ihnen Werkzeuge zu geben, damit sie diese immer wieder anpeilen können.

Als Team soll man Verantwortung übernehmen, statt nur darauf zu warten, dass einem gesagt wird, was zutun ist. Hierbei geht es nicht um das Picken von Rosinen.

Verantwortung übernehmen motiviert auch ungemein.

XP sagt ganz klar, dass man die vorgestellten Verfahren, an die eigenen Gegebenheiten anpassen soll. Jedes Team, jede Firma ist anders und sollte anders arbeiten.

Keiner soll nach dem Schauen eines solchen Kurses sagen: Ah, so geht das.

ABER: Wer keine Erfahrung besitzt, kann häufig nicht gut entscheiden, was wirklich wichtig ist und wie so eine angepasste Methode aussehen könnte. Daher sollte man erst mit größer werdender Erfahrung Methoden anpassen.

Softwareentwickler haben immer viel Kram, den sie mit sich rumschleppen. Programmiersprachen, Frameworks, Methoden, Entwicklungsumgebungen und so weiter. Was soll hier bevorzugt werden?

Wir sollten Dinge bevorzugen, die

• wenig

• einfach

• wertvoll

sind.

Mit diesen Dingen im Gepäck, kann man schnell die Richtung ändern. Wir sollen nicht an schweren Dingen hängen. Dicken Frameworks oder Umgebungen.

Seine Arbeit zu messen ist wichtig und wird häufig gemacht.

Wir sollten bei unseren Messungen jedoch ehrlich zu uns sein. Aufwände lassen sich nicht in Minuten rechnen. Niemanden ist etwas damit geholfen, statt "grob 2 Wochen" von 9,76 Tagen zu sprechen.

Also, messen ja - aber sich klar darüber sein, was genau diese Messung aussagt.

Es braucht bestimmte Rollen, um mit XP arbeiten zu können.

Auch wenn die Verantwortung für ein gutes Gelingen der Entwicklung bei allen Beteiligten liegt, gibt es bestimmte Personen, die für einen bestimmten Bereich mehr Verantwortung tragen.

Die Leute müssen für die Rollen passen. Es gibt jedoch einige Grundideen:

Programmierer sind nicht gleichzeitig Kunden.

Technische Entscheidungen sollen von geschäftlichen Entscheidungen getrennt sein.

Ausnahmen bestätigen hier natürlich wieder die Regel. Aber auch hier muss man genau wissen, was man tut.

Eine Person kann auch mehrere Rollen einnehmen. Hierbei muss man jedoch sorgfältig sein.

Programmierer stehen beim XP im Mittelpunkt. Könnten sie von sich aus, alle kurzfristigen und langfristigen Interessen sorgfältig gegeneinander abwägen, bräuchte es nur Programmierer.

Ihre Schwerpunkte sind andere, als in klassischen Projekten. Neben dem Programmieren müssen sie auch viel kommunizieren und vereinfachen.

Sie müssen z.B. mit dem Kunden diskutieren, ob bestimmte Dinge wirklich erforderlich sind. Aber auch der Code soll einfach sein.

Ein Programmierer soll eine Hand voll Tools verfügen, die er wirklich beherrscht und die gut eingesetzt werden können - statt zu viele Konzepte und Ansätze zu kennen, und damit eine aufwändige Lösung zu riskieren.

An Fähigkeiten muss er einigermaßen gut programmieren können Refactoring betreiben können und man muss den Code automatisiert testen können.

Ohne Mut geht es nicht. XP-Programmierer müssen auch mit Ängsten klarkommen.

• für dumm gehalten zu werden

• für nutzlos gehalten zu werden

• überflüssig zu werden

• nicht gut genug zu sein

Wer den Weg geht, wird auch Spaß an der Softwareentwicklung haben.

Der Programmierer weiß, wie man programmiert. Der Kunde weiß, was programmiert werden soll. Zumindest will er dies herausfinden und lernt daher immer dazu.

Ein XP-Kunde muss einige Methoden kennen - z.B. das Planungsspiel. Auch muss er eine Haltung haben und sich daran gewöhnen, dass Projekt zwar beeinflussen, aber nicht kontrollieren zu können.

Kunden fällen Geschäftsentscheidungen - das ist eine der schwierigsten Fähigkeiten überhaupt.

Klassische Kunden, sind es gewohnt, dass die IT nicht die Hälfte von dem fertig bekommt, was sie verspricht und/oder die Hälfte von dem, was sie fertigstellt einen Fehler hat. Daher geht er auch nicht mehr auf die Wünsche der IT ein.

XP braucht einen anderen Kunden. Die Programmierer müssen ihrem Kunden aber auch klar machen können, wieso Etwas so und nicht so gemacht werden soll.

Auch müssen Kunden Funktionstests schreiben. Sie müssen die Testfälle erstellen, mit denen die Funktionalität des Systems getestet wird. Akzeptanztests.

Das Testen der Units liegt beim XP in der Verantwortung der Programmierer. Tester sind dennoch als Rolle wichtig, denn sie helfen dem Kunden dabei Funktionstests zu schreiben und durchzuführen.

Es geht beim Tester also darum, dass er die Anforderungen an das System, aus Sicht des Kunden, testet.

Hierfür arbeitet er eng mit dem Kunden zusammen.

Der Terminmanager wird im XP als "das Gewissen" des Teams bezeichnet.

Er ist für die Schätzungen und den Liefertermin zuständig. Er schätzt nicht selbst - dies wird von demjenigen gemacht, der eine Funktionalität auch umsetzt - aber, er fordert die Schätzung ein.

Der Terminmanager hält auch das gesamte Projekt im Blick. Er macht das Team darauf aufmerksam, wenn die Zeit knapp wird oder man im Verzug ist.

Er ist kein Chef und ist nicht dafür da Überstunden anzuordnen.

Der Coach ist für den Gesamtprozess verantwortlich. Er soll das Team dabei unterstützen, in die richtige Richtung zu laufen.

Wenn sich das Team verzettelt, soll der Coach es darauf aufmerksam machen. Dabei soll er so wenig wie möglich eingreifen, dann jeder Eingriff nimmt dem Team Selbstbewusstsein. Es kann jedoch auch notwendig sein, ein wenig konkreter einzugreifen. Dies sollte jedoch nur so lange gemacht werden, bis das Team wieder in die richtige Richtung läuft.

Ein Coach sollte - und das ist der Unterschied zu SCRUM - auch technisch in der Lage sein, gutes Design und die Fähigkeiten für XP zu lehren. Er muss nicht der beste Programmierer sein - aber er muss erkennen, wo noch Defizite im Team herrschen. Dieser Teil kann in einigen Situationen auch von einem anderen erfahrenen Teammitglied übernommen werden.

Umso erfahrener das Team wird, umso weniger wichtig wird der Coach.

XP-Programmierer sind selten Spezialisten. Daher kann es immer mal wieder einzelne Situationen geben, bei denen das Team einen Spezialisten braucht. Diese nehmen im XP die Rolle des Beraters ein. Sie sind temporär Teil des Teams, um eine klare Aufgabe zu lösen oder dem Team das Wissen zum Lösen der Aufgabe zu lehren.

Das Team sollte einem Berater nicht einfach so vertrauen. Es sollte nachfragen, diskutieren und verstehen, was der Berater vor hat.

Der Boss ist dafür da, dem Team Mut zu machen. Er steht außerhalb des Prozesses und muss sich nicht mit XP auskennen. Er muss nur akzeptieren, dass die Entwickler anders arbeiten, als er es gewohnt ist.

Auch muss ihm klar sein, dass Kommunikation von Seiten des Teams ehrliche und offene Kommunikation ist. Kein Gejammer oder überzogene Angstmache.

Es wird ein grober Plan entworfen. Dieser wird ständig weiter verbessert. Hierbei gelten immer kürzere Zeiträume.

Der Plan wird schnell und kostengünstig erstellt.

Er dient unter anderem den Zwecken

• ein Team zusammenzuführen

• über Umfang und Prioritäten zu entscheiden

• das Vertrauen aller Beteiligten zu stärken, dass das System tatsächlich implementiert werden kann

• einen Fixpunkt für regelmäßiges Feedback zur Verfügung zu stellen

Folgende Prinzipien finden Anwendung:

• Detailliert wird immer nur die nächste Iteration geplant. Alles danach wird nur anhand von Stichpunkten geplant.

• Verantwortung kann nur übernommen werden. Ein Manager kann das Team nur bitten, die Verantwortung zu übernehmen - und sich dann dessen Reaktion anhören

• Die Person, die für die Implementierung verantwortlich ist, schätzt den Aufwand

• Abhängigkeiten ignorieren. Jedes Teil soll so implementiert werden, dass die Teile beliebig vertauscht werden könnten.

• Die Prioritäten ergeben sich nach dem Geschäftswert.

Das Piel hat 3 Phasen

• Erforschen - Herausfinden, was das alte System geleistet hat

• Verpflichtung - Entscheiden, welche Anforderungen als nächstes in Angriff genommen werden

• Steuerung - Die Entwicklung wird gesteuert, wobei die Realität den Plan formt

Bewusstsein für das gesamte System bekommen.

1. Stoycard schreiben - Die Geschäftsseite schreibt auf eine Storycard, was das System leisten soll. Leistungsmerkmale werden beschrieben und es wird auch das WIESO geklärt.

2. Storycard einschätzen - Die Entwickler schätzen die optimale Entwicklungszeit.

3. Storycard aufteilen - Wenn sie das nicht können oder die Geschäftsseite erkennt, dass ein Teil der Story wichtiger ist als ein anderer, wird die Storycard mit den Kunden weiter erläutert und/oder aufgeteilt.

Datum und Umfang der nächsten Version werden festgelegt und die Entwickler commiten sich darauf.

1. Nach Wert sortieren - Die Geschäftsseite teilt die Storycards in drei Stapel.

• Das System funktioniert nicht ohne diese Storys

• Leistungsmerkmale der Story sind weniger wichtig, liefern jedoch enormen Geschäftsgewinn

• Leistungsmerkmale sind wünschenswert, aber nicht unbedingt erforderlich

2. Nach Risiko sortieren - Die einzelnen Stapel werden jeweils in drei Stapel geteilt

• Die Leistungsmerkmale können genau eingeschätzt werden (da schon bekannt oder sehr einfach)

• Die Leistungsmerkmale können halbwegs eingeschätzt werden

• Die Leistungsmerkmale können nicht eingeschätzt werden

3. Geschwindigkeit festlegen - Die Entwicklerseite teilt mit, mit welcher idealen Geschwindigkeit sie pro Kalendermonat entwickeln kann.

4. Die Geschäftsseite wählt die Storycards für eine Version aus, indem sie entweder

• ein Datum festlegt, und dann Storycards je nach Schätzung und Geschwindigkeit auswählt, oder

• Storycards auswählt, und das Datum für die nächste Version berechnet

Zweck ist, den Plan ständig an die Gegebenheiten und Geschwindigkeiten anzupassen. Hierzu gibt es die Iteration von einer bis drei Wochen länge.

1. Iteration - Am Beginn jeder Iteration wählt die Geschäftsseite die Elemente aus, die während dieser einen Iteration entwickelt werden können. Die erste Iteration soll zu einem funktionsfähigem System führen.

2. Plankorrektur - Wenn erkannt wird, dass das Tempo langsamer ist, schätzen die Entwickler neu, und der Umfang der Version wird angepasst.

3. Neues Leistungsmerkmal - Wenn die Geschäftsseite ein neues Leistungsmerkmal braucht, kann sie das als Storycard schreiben. Die Entwicklung schätzt die Storycard ein und die Geschäftsseite entfernt andere Storycards mit gleichem oder höherem Aufwand aus der aktuellen Version.

4. Neueinschätzung - Wenn der Plan den Entwicklungsverlauf nicht mehr genau genug beschreibt, kann eine Neueinschätzung gemacht werden.

Jede Iteration (1-3 Wochen) hat ihre eigene Planung. Diese wird jedoch nur von den Entwicklern ausgeführt. Hier werden die Storycards in sogenannte Taskcard aufgeteilt. Diese werden übernommen und geschätzt.

Grundidee ist, dass gleiches Verständnis zwischen Kunde und Entwickler zentral für eine gute Softwareentwicklung ist. Daher muss ein Kunde direkt vor Ort mit bei der Entwicklung dabei sein.

Hier wird als Kunde derjenige angesehen, der das Programm auch benutzt - bzw. die Vision des Programmes entwickelt hat.

XP setzt auf Metapher, wenn es um das Reden über ein Produkt oder Programm geht.

Eine Metapher ist ein sehr gutes Mittel, um ein gemeinsames Verständnis von einer Vision zu bekommen.

Eine klare Metapher hilft Allen, das Produkt zu begreifen.

Jeder im Team ist für den gesamten Code verantwortlich. Nur so entsteht funktionierende Software.

Wissensinseln sollen abgebaut werden. Es gibt kein "mein Code" und "dein Code".

Durch Versionskontrolle, gute Kommunikation und automatisierte Tests gibt es genug Sicherheit, dass gemeinsame Verantwortung ein großer Vorteil ist und nur wenige Risiko birgt.

XP geht in Iterationen vor. Ständig werden lauffähige Versionen der Software bereitgestellt. Daher ist eine fortlaufende Integration sehr wichtig.

Neue Features sollten klein sein. Sie sollten automatisiert getestet sein und dann in den bestehenden Code integriert werden.

Am besten sollte dies automatisch geschehen.

Innerhalb eines Codes, sollen einheitliche Progammierstandards  verwendet werden. Hierbei sollte sich das Team freiwillig auf einen Standard verständigen.

Ein Standard soll das Arbeiten erleichtern. Am besten gehst du da nicht zu dogmatisch vor. Er sollte leichtgewichtig und einfach sein und jederzeit den Bedürfnissen angepasst werden können.

Zentrale Technik im XP. Programmiert wird immer im Paar. Zu zweit sitzt man vor der selben Aufgabe und vor dem selbe Code. Ja, am selben Rechner.

Es gibt verschiedene Ausführungen vom Pair Programming. Typisch ist, dass einer den Code schreibt und der andere seine Kommentare dazu abgibt. Pair Programming ist auch immer Kommunikation.

Die Rollen "Pilot" und "Navigator" werden häufig gewechselt. Auch die Paare werden innerhalb des Teams durchmischt.

Einfaches Design und dummes Design liegen leider direkt nebeneinander. Daher muss man aufpassen, dass man wirklich einfach bleibt.

Hierfür sollte man Refactoring zur täglichen Praxis erheben und nicht davor zurückscheuen, den Code jederzeit zu ändern, wenn man merkt, dass das Design nicht passt.

Auch sollte man eine klare, prägnante Metapher haben, damit man sicher sein kann, dass auch zukünftiger Code dieser Metapher folgt. So kann man das Design so wählen, dass es die Metapher unterstützt und sie nicht behindert.

Wenn man als Paar programmiert, ist es einfacher, einfaches Design zu entwickeln.

Hierzu ist Clean Code und objektorientiertes Design enorm wichtig. So helfen z.B. die SOLID-Prinzipien enorm dabei, die Software flexibel und stabil zu machen.

Tests schreiben macht Spaß wenn es ein einfaches Design gibt. Ist das Design zu ausladend oder zu komplex, werden dies die Tests auch. Dann beschäftigt man sich als Entwickler 80% seiner Zeit mit Testen. Das sollte nicht sein.

Automatische Tests sind über­le­bens­wich­tig. Sie machen stolz und erzeugen einen doppelte Boden. Es gibt weniger Bugs und man erstellt signifikant häufiger die Software, die der Kunde auch haben will.

Jeder sollte für den gesamten Code verantwortlich sein und ihn ändern dürfen. Hier kommt Refactoring ins Spiel. Dies bedeutet die Technik, Code so anzupassen, dass das Design sich ändert, das Verhalten jedoch gleich bleibt.

Diese Technik ist enorm wichtig für uns Entwickler. So verbessern wir jeden Tag unseren Code und unser Design.

Pfadfinderregel anwenden: Verlasse ein Stück Code immer ein bisschen besser, als du es vorgefunden hast.

20% des Aufwands ist für 80% der Features zuständig.

20% der Funktionen werden 80% der Zeit genutzt.

20% Können in einer Technik, ermöglicht 80% der Anwendungen.

Hier ist der Schreibtisch, das Teambüro und auch der Rechner gemeint. Spielt damit rum. Whiteboardwände, Sitzecken oder sonstige Ideen. Heutzutage immer häufiger anzutreffen - damals noch recht neu.

Jeder Entwickler soll sich auch seine eigene Hardware und Software aussuchen können. So ist er motivierter und produktiver

Dies soll ganz klar anmerken, dass Überstunden nicht gut sind. Softwareentwicklung ist eine anstrengende, hoch konzentrierte Tätigkeit. Niemand kann längere Zeit hinweg 60 Stunden pro Woche gute Arbeit abliefern.

Wenn Überstunden anstehen, gibt es ein Problem, dass sich nicht durch Überstunden lösen lässt.

Das ist ganz einfach. Man setzt sich mit allen Verantwortlichen und Mitwirkenden zusammen und entscheidet, dass man jetzt nach XP entwickeln möchte.

Zusammen einigt man sich auf ein paar Grundlagen und organisiert z.B. das Planungsspiel und die Releases.

Rollen werden verteilt.

Dann geht es los.

Wenn Probleme auftauchen, werden die Werte, Prinzipien und Techniken des XP zur Rate gezogen.

Wichtigster Hinderungsgrund ist die Unternehmenskultur. Wenn ein Unternehmen einem Team immer direkt vorgibt, wie und was es zutun hat, wird es XP sehr schwer haben.

Auch sollte man XP nicht ausprobieren, wenn der Kunde vor der Implementierung ein komplettes Design oder eine komplette Spezifikation des Programms haben möchte.

Auch eine Kultur, die Überstunden unterstützt, ist mit XP nicht vereinbar. So lässt sich keine gute Leistung abliefern.

Wirklich intelligente Entwickler tun sich auch manchmal schwer mit XP. Sie fühlen sich durch das ständige Kommunizieren und die fortwährende Evolution oft eingeschränkt.

Werden die Teams zu groß, klappt XP auch nicht. Möglichst kleine Teams sind hier wichtig.

Auch kann die Umgebung ein No-Go für XP sein. Kleine, strickt getrennte Einzelbüros eignen sich nicht für XP. Auch das Verteilen der Programmierer über mehrere Stockwerke funktioniert nicht.

Ein Festpreis ist immer kritisch. Liefere die 20 Funktionen in 12 Monaten für Preis X.

Er funktioniert bei der Softwareentwicklung einfach nicht. Der Kunde will so viel wie möglich für sein Geld, die Entwickler wollen so wenig wie möglich liefern. Daher gibt es immer Konflikte. "Das stand so nicht in den Anforderungen!" "Das ist doch komplett anders gemeint gewesen!"

Besser sind hier agile Abmachungen. Die Entwickler arbeiten X Monate für den Preis von Y um das Produkt fertig zu stellen. Sie tun dies mit vollem Einsatz. Nach jeder Iteration hat der Kunde die Möglichkeit das Projekt zu beenden. (Dies unterstützt das "mit vollem Einsatz").