L'extreme programming ha dato impulsi importanti alla modalità di sviluppo di software, ma non è indicato per tutte le situazioni e per tutti i team. L'XP parte dal presupposto che, all'inizio del progetto, il cliente non abbia ancora un'idea precisa del prodotto finito. In tal caso, il software può essere progettato in modo agile, con una progettazione in continua evoluzione.
Così facendo, da un lato si soddisfa il cliente, in quanto si cerca di trovare insieme a lui la soluzione giusta, coinvolgendolo in ogni fase. Dall'altro, gli sviluppatori possono implementare i progetti in base alle loro valutazioni, invece di dover fare sempre dei compromessi. Se invece il cliente arriva con una descrizione già pronta del prodotto e una lista di funzioni da consegnare al team di sviluppatori, è molto difficile utilizzare l'XP.
Già il pair programming può mettere i piccoli team davanti a dei problemi se le risorse necessarie non sono disponibili. Anche gli incontri periodici con il cliente richiedono tempo, sottratto al lavoro effettivo di programmazione. In una situazione ideale ciò non conta: il risultato sarà inequivocabilmente migliore se il team può concedersi il tempo necessario e le risorse richieste.
Nella pratica, però, gli sviluppatori sono sotto pressione per via del budget limitato e delle scadenze stabilite. In più, il cliente potrebbe non avere interesse o le possibilità di impegnarsi nel progetto nella misura richiesta dall'XP.
Se invece le circostanze consentono di procedere in base all'extreme programming, con questo metodo un team può fornire risultati eccellenti. I test continui si traducono in sistemi stabili, e la procedura iterativa, insieme all'approccio minimalistico, fa sì che vengano create davvero solo le funzioni necessarie per il progetto.