capables de traiter le projet de bout en bout,
-délimiter les micro-projets de telle façon qu'ils présentent entre eux aussi peu d'interfaces que possible,
-faire des tests de cohérence, fréquents et réguliers,
-organiser la communication entre équipes,
-permettre aux équipes de s'aider mutuellement et de partager leur vision d’une situation difficile,
-permettre aux équipes de préciser le projet à mesure de son avancement,
-offrir très vite des résultats mesurables.

Comme le souligne Kent Beck dès le début de son ouvrage, les idées qu'il avance sont simples et ont sans doute déjà été expérimentées par d'autres. Son apport essentiel réside dans la réunion de ces principes, la démonstration de leur interdépendance, leur codification et leur crédibilisation par son expérience exceptionnelle. Même le nom qu'il a choisi participe à l'attrait et à la compréhension de cette approche du développement de projet informatique.
Kent Beck ne laisse pas indifférent. Son talent d'orateur renforcé par sa force de 
conviction ont

ont porté depuis vingt ans à trente ans. Fortement empreinte de l’exceptionnelle souplesse de Smalltalk, elle est cependant applicable aux autres langages à objets et en particulier à Java.
Pour une armée, l’agilité permet de modifier sa route rapidement et de s’adapter à la situation. En revanche, les grandes armées nécessitent des plans lourds qui doivent tout prévoir et complexes à mettre en œuvre. Les techniques classiques de développement rendent les modifications plus coûteuses à mesure que le développement avance. Pour éviter les modifications tardives, les projets débutent par des spécifications longues, les plus complètes possible. Cependant, aussi poussée qu’elle puisse être, la spécification initiale ne peut empêcher l’utilisateur final de se découvrir de nouveaux besoins dans un environnement mouvant. A l’opposé, Kent Beck propose un modèle de développement plus agile qui permet de garder constant le coût des modifications.

D'une façon apparemment contradictoire, l'agilité évite d'avoir recours à de grandes embardées et permet une adaptation fine du projet si un contrôle permanent est effectué. 
A l'opposé, la lourdeur rend la mesure des écarts par rapport  aux objectifs beaucoup plus difficile et nécessite des corrections certes moins fréguentes mais beaucoup plus radicales. Et parce qu'elle aura des répercussions majeures, la correction sera mûrement réfléchie donc appliquée avec un délai variant à l'exponentielle. Mais l’agilité est inopérante sans une bonne communication. Le télégraphe de Chappe joua un rôle fondamental dans l'agilité 

La performance n'est évidemment pas exempte de difficulté. Cependant tout développeur expérimenté a appris que la réussite d'un projet repose avant tout sur la capacité d'une équipe à mettre en oeuvre des principes simples et fédérateurs et aux leaders de cette équipe à entretenir le même esprit, coûte que coûte.

vraisemblablement joué dans la réussite des projets auxquels il a participé, mais la mise en oeuvre de la programmation extrême en a fait un grand maître. Ses principes fonctionnent parce qu'ils sont facilement compréhensibles de tous et donc facilement applicables et qu'ils autorisent un contrôle permanent. Ils représentent ce  que les développeurs Smalltalk