Pourquoi ce sujet. « Agile » circule sans que le texte d'origine ait jamais été lu. Le mot est donc rempli par ce que chacun en a entendu ailleurs : des sprints, des post-its, une réunion debout. Lire le texte remet tout le monde devant la même page, et fait apparaître que ce qu'on croyait être des règles agiles n'y figure pas.
Dans les années 90, le développement logiciel a la réputation d'un métier qui ne tient pas ses promesses. Deux textes installent ce constat.
Fred Brooks, No Silver Bullet, 1986. Brooks avait dirigé le développement d'OS/360 chez IBM. Sa thèse : la difficulté du logiciel est essentielle, elle tient à la nature de ce qu'on fabrique, pas aux outils. Donc aucune méthode ne fera à elle seule gagner un ordre de grandeur de productivité.
Le CHAOS Report du Standish Group, 1994. Une enquête sur des projets informatiques américains :
| Sort du projet | Part | Ce que ça veut dire |
|---|---|---|
| Réussis | 16 % | budget, délai et périmètre tenus tous les trois |
| En dérive | 53 % | livrés, mais en retard, plus chers, ou amputés |
| Abandonnés | 31 % | arrêtés avant livraison |
Le rapport a été discuté depuis, sur sa méthode et sur sa définition du succès. Ce qui compte ici est son effet : il a installé dans toute la profession l'idée que le logiciel était en crise. Brooks dit qu'aucune méthode ne le sauvera, le CHAOS Report montre l'ampleur du problème. Au milieu des années 90, la profession sait qu'elle a un problème sérieux et n'a pas de réponse.
Le manifeste ne promettra d'ailleurs aucun gain de productivité, et ne prétendra pas supprimer la difficulté du logiciel. Il change ce qu'on en fait : arrêter de croire qu'on la maîtrise en la prévoyant mieux.
17 personnes, 3 jours, et un accord que personne n'attendait.
Du 11 au 13 février 2001, 17 praticiens se réunissent à Snowbird, une station de ski de l'Utah. Ils viennent de courants différents, et pour la plupart concurrents :
| Qui | D'où il vient |
|---|---|
| Kent Beck | Extreme Programming |
| Ken Schwaber et Jeff Sutherland | Scrum |
| Alistair Cockburn | Crystal |
| Martin Fowler | conception logicielle, refactoring |
| Robert C. Martin | pratiques de développement, à l'origine de la réunion |
Les 12 autres viennent de DSDM, de Feature-Driven Development, d'Adaptive Software Development. Tous praticiens, chacun défendant une façon de travailler qui contredit celle du voisin. Personne n'attend d'accord.
« Personnellement, je ne m'attendais pas à ce que ce groupe d'agilistes tombe un jour d'accord sur quoi que ce soit de substantiel. » Alistair Cockburn, cité par Jim Highsmith
Ils s'accordent quand même, mais sur peu : 4 phrases et 12 principes. Pas sur une méthode, pas sur des pratiques, pas sur un vocabulaire commun. Ce qu'ils publient est le point où leurs façons de travailler se recoupent, et ce point est petit.
Ce que « plus que » change. Le manifeste garde les processus, la documentation, les contrats et les plans. Il dit lequel des deux l'emporte quand il faut arbitrer.
| Formulation | Ce qu'elle voudrait dire |
|---|---|
| « au lieu de » | la colonne de droite disparaît |
| « plus que » | les deux existent, et on sait qui gagne en cas de conflit |
Un arbitrage n'a lieu que si les deux termes ont de la valeur. Personne n'arbitre entre une chose utile et une chose inutile.
Le manifeste s'accompagne de 12 principes qui détaillent ces 4 valeurs.
Le manifeste fait 81 mots, un peu plus de 300 avec les 12 principes. Voici des mots que tout le monde associe à l'agilité et qui n'y figurent nulle part :
| Mot absent du texte | D'où il vient |
|---|---|
| sprint | Scrum |
| daily, mêlée quotidienne | Scrum |
| rétrospective | Scrum, et avant lui les project retrospectives de Norman Kerth |
| Product Owner, Scrum Master | Scrum |
| story point, vélocité | XP, puis pratique courante |
| user story | Extreme Programming |
| backlog | Scrum |
| itération de 2 semaines | pratique d'équipe, jamais prescrite |
| le mot « Scrum » lui-même | — |
La seule indication de durée est dans le principe 3 : « des cycles de quelques semaines à quelques mois et une préférence pour les plus courts ». Une fourchette et une préférence. Aucune cérémonie, aucun rôle, aucun outil, aucun indicateur : le manifeste donne une direction et s'arrête là.
Chacun a rempli ce vide avec ses propres pratiques. 25 ans plus tard, on trouve sous le mot « agile » des choses qui se contredisent : Scrum, Kanban, SAFe, des certifications, des rituels appliqués sans avoir lu les 4 phrases. Le texte n'a aucun moyen de se défendre contre ces usages, et c'est le reproche le plus courant qu'on lui fait.
À arbitrer. Une règle dit quoi faire dans les situations prévues, un cap dit quoi faire dans les autres. Pour savoir si on le suit bien, on regarde ce qui sort : est-ce qu'on livre quelque chose d'utilisable régulièrement, est-ce que les gens qui savent peuvent décider, est-ce qu'on change d'avis quand on apprend. Aucune de ces questions ne se lit sur un tableau de bord de conformité.
Deuxième nœud. Le manifeste est court, mais il change la façon dont on croit connaître ce qu'on va construire.
Le modèle qui domine avant 2001 repose sur une idée simple : on peut savoir à l'avance ce qu'il faut construire. On spécifie, on planifie, on exécute, on contrôle l'écart. Ça marche quand ce qu'on fabrique est connu d'avance.
Le manifeste part d'un autre constat : dans le logiciel, on ignore ce que l'utilisateur voudra, ce que la technique permettra, où sera le marché dans 6 mois. La connaissance se produit en faisant.
| Prévoir puis contrôler | Faire, observer, apprendre, adapter | |
|---|---|---|
| Ce qu'on sait au départ | l'essentiel, à préciser | peu, et on le sait |
| Rôle du plan | la référence à tenir | l'hypothèse du moment |
| Un écart au plan | un incident à corriger | une information à intégrer |
| Source de la connaissance | l'analyse, avant | le retour du réel, pendant |
| Question de pilotage | « avons-nous respecté le plan ? » | « est-ce que ce qu'on fait a encore du sens ? » |
Trois déplacements suivent de là, et ce sont eux qui touchent le travail d'un dirigeant.
Dans le premier modèle, un projet conforme au plan est réussi, même si ce qu'il livre ne sert plus à personne. Le manifeste déplace la preuve vers ce qui est livré et utilisé : un plan tenu à la lettre sur un produit devenu inutile est un échec, un plan abandonné parce qu'on a trouvé mieux est un succès.
Première question : « Est-ce qu'on a fait ce qu'on avait dit ? »
Seconde question : « Est-ce que ce qu'on fait a encore du sens et de la valeur ? »
Les deux sont légitimes. Le manifeste dit laquelle passe devant quand elles se contredisent.
Dans un modèle prédictif, la communication et la confiance sont des conditions de confort : on les traite quand il reste du temps, elles ne figurent dans aucun tableau de bord. La première valeur les met au centre : si la connaissance se produit en faisant, elle circule entre les personnes, et ce qui l'empêche de circuler abîme le produit. Une information qui ne remonte pas, une objection qu'on n'ose pas dire, une décision prise sans ceux qui savent : ce sont des défauts de production.
Le déplacement le plus lourd de conséquences. Deux principes portent dessus :
« Réalisez les projets avec des personnes motivées. Fournissez-leur l'environnement et le soutien dont ils ont besoin et faites-leur confiance pour atteindre les objectifs fixés. »
« Les meilleures architectures, spécifications et conceptions émergent d'équipes autoorganisées. »
Si les décisions se prennent au moment où l'information arrive, elles ne peuvent pas toutes remonter :
C'est là que se situe ce que beaucoup d'entreprises appellent gouvernance partagée. Le terme n'est pas dans le manifeste et ne recouvre pas la même chose partout : sociocratie, holacratie, ou le plus souvent une formule maison.
Quand une organisation parle de gouvernance partagée, quelles décisions l'équipe peut-elle prendre sans demander une validation ?
Une liste de décisions concrètes renseigne mieux qu'une définition générale. Elle montre où se trouve réellement le pouvoir d'agir.
Trois pratiques courantes permettent de voir comment les valeurs se traduisent dans le travail.
Pour comprendre une pratique agile, trois questions suffisent :
La troisième question montre le compromis. La colonne de droite conserve une valeur réelle : choisir davantage d'interactions demande de rendre les personnes disponibles ; choisir l'adaptation retire une part de prévisibilité.
Valeur : les individus et leurs interactions plus que les processus et les outils.
Principe : « la méthode la plus simple et la plus efficace pour transmettre de l'information est le dialogue en face à face ».
Ce que ça coûte : il faut être disponible au même moment, tous les jours. Une information seulement orale se retrouve aussi moins facilement plusieurs mois plus tard.
Valeur : l'adaptation au changement plus que le suivi d'un plan.
Principe : « accueillez positivement les changements de besoins, même tard dans le projet ».
Ce que ça coûte : certains sujets restent en bas de la liste et peuvent ne jamais être traités. Le contenu lointain du plan reste donc moins prévisible.
Principe : « à intervalles réguliers, l'équipe réfléchit aux moyens de devenir plus efficace, puis règle et modifie son comportement en conséquence ». Principe 12, le seul qui porte sur l'équipe plutôt que sur le produit.
Valeur : les individus et leurs interactions.
Ce que ça coûte : du temps pris sur la production et une discussion parfois inconfortable sur ce qui n'a pas marché.
Aucune de ces pratiques n'est prescrite par le manifeste. Leur caractère agile dépend de la boucle d'apprentissage qu'elles créent et de la valeur qu'elles servent.