En 2001, 17 représentants des méthodes légères alternatives aux processus lourds traditionnels se sont réunis pour trouver les points communs à leurs méthodes "to find common ground". De cette réunion de quelques jours est né le Manifeste Agile : un texte bref énonçant des grands concepts, simples, mais qui proposent une nouvelle façon de penser un projet de développement informatique. Si certains dénoncent une certaine évidence de ces concepts, il n'en est pas moins que ce manifeste a pour lui le mérite de les formaliser et surtout de les structurer en un tout homogène et cohérent, par opposition aux pratiques semblables mais complètement hétérogènes d'une entreprise à l'autre et d'un projet à l'autre.
Le manifeste agile résume sa philosophie en quatre oppositions entre les concepts traditionnels et les concepts proposés.
Ce sont les individus qui font la valeur du travail accompli, ce sont donc eux que l’on doit privilégier. Sans l’artisan, les meilleurs outils ne servent à rien. Les processus qui définissent ce que doit faire chaque personne brident le potentiel caché derrière chacun : faire interagir les gens au maximum est bien plus fructueux et permet d'améliorer grandement l'efficacité et la qualité du travail fourni, en rassemblant des visions différentes d'un même problème.
Les processus lourds génèrent une documentation qui se veut exhaustive avec tous ses inconvénients : ambigüité du langage, coût de la rédaction, coût du maintien en accord avec la réalité, etc. Ces documents ne sont qu'une illusion d'avancement du projet. Même une conception technique initiale peut être complètement remise en cause en phase de codage (ou après) : comment peut-on alors déterminer l'avancement du projet ? Une régression ?
Dans les méthodes Agiles, un seul critère permet de mesurer l'avancement d'un projet : le logiciel qui fonctionne. La documentation n'est qu'un support concret qui aide à produire le logiciel.
Dans tout projet, le but premier est de gagner de l’argent, autant pour le client (rentabilisation) que pour le fournisseur (prestation). Si la négociation protège plus ou moins des risques financiers, elle peut provoquer l’échec des projets (délais non respectés, budgets insuffisants) et engendrer d'interminables procès où tout le monde y perd au bout du compte (le client n'a pas son logiciel et le fournisseur ferme boutique).
Il faut sortir de la guerre client/fournisseur et penser en équipe qui veut atteindre un but commun : réussir le projet.
Un plan prédéfini a tendance à nous rendre autistes aux événements qui surviennent pendant le projet. Il est en plus à l'origine des conflits client/fournisseur classiques sur les délais de livraison. Pour le client, pouvoir adapter les besoins en cours de projet est un atout concurrentiel : il est réactif aux fluctuations des marchés et s'assure en plus que le logiciel développé répond parfaitement à ses véritables besoins.
Les méthodes Agiles sont conçues pour s’adapter au changement, en assurant un plan macroscopique précis et adaptatif.