S’il a redynamisé le développement de logiciels, l’extreme programming ne convient pas dans tous les cas de figure ni à toutes les équipes. XP part du principe que le client, au début du projet, n’a encore aucune idée précise du produit fini. Dans un tel cas, le logiciel peut être planifié et développé de manière agile, c’est-à-dire petit à petit.
Il en résulte d’une part la satisfaction du client : on cherche collectivement avec lui la solution adaptée et il est associé à chaque étape. D’autre part, les développeurs peuvent mettre en œuvre des projets d’une façon qu’ils jugent appropriée plutôt que de devoir faire des compromis en permanence. Cependant, si le client vient voir l’équipe de développeurs avec une description finie du produit et une liste de fonctions, il sera alors très difficile d’employer XP.
Le pair programming notamment peut mettre de petites équipes dans l’embarras, car les capacités requises à cet effet ne sont pas disponibles. Les réunions régulières avec les clients demandent également du temps qui ne peut pas être réintégré dans le travail de programmation à proprement parler. Dans une situation idéale, cela n’a aucune importance : le résultat sera nettement meilleur si l’équipe peut prendre le temps nécessaire et disposer des ressources souhaitées.
Dans la pratique en revanche, un budget limité tout comme des délais de livraison clairement fixés mettent les développeurs sous pression. Par ailleurs, le client peut ne pas être intéressé ou ne pas être en mesure de prendre part au projet à la hauteur des exigences XP.
Si en revanche la situation permet de procéder selon l’extreme programming, une équipe peut fournir un résultat exceptionnel avec cette méthode. Les tests permanents génèrent des systèmes stables et le processus itératif garantit en combinaison avec l’approche minimaliste que seules des fonctions importantes pour le projet sont effectivement créées.