Agile : pourquoi, et ce que le mot recouvre

Agile : pourquoi, et ce que le mot recouvre

1. Le problème que l'agile résout

   Le cycle en cascade suppose qu'on sait tout du besoin avant de commencer. L'expérience montre le contraire : le besoin se précise quand on montre quelque chose aux utilisateurs.

   Le coût d'un mauvais besoin tardif

   Plus un besoin faux est découvert tard, plus il coûte cher. Corriger un écran de saisie est une question d'heures. Corriger l'architecture qui le soutient après qu'un millier d'utilisateurs l'utilisent, c'est un projet à part entière. Le cycle itératif ne réduit pas le coût des corrections : il déplace le moment où on les découvre.

   Les quatre valeurs du Manifeste

   1. les individus et leurs interactions plutôt que les processus et les outils ;
   2. des logiciels opérationnels plutôt que la documentation exhaustive ;
   3. la collaboration avec les clients plutôt que la négociation contractuelle ;
   4. l'adaptation au changement plutôt que le suivi d'un plan.

   Ces valeurs ne sont pas un rejet des processus et des documents : elles sont un arbitrage. « Plutôt que » ne veut pas dire « sans ». Un produit qui fonctionnera sans documentation est un défaut, pas une qualité. Le Manifeste dit que, quand les deux comptent, le premier l'emporte.

   Scrum n'est pas « agile »

   Scrum est un cadre agile, parmi d'autres (Kanban, XP, SAFe). Présenter Scrum comme la définition de l'agile est une erreur de vocabulaire qui produit des discussions sans conclusion. Un projet peut être agile sans Scrum, et appliquer Scrum de manière mécanique ne garantit rien.

2. L'empirisme : les trois piliers

   Le mot « empirique » n'est pas décoratif. Il décrit la différence de nature entre une équipe qui décide et une équipe qui constate.

   Transparence, inspection, adaptation

   • transparence : le travail et son état sont visibles par tous. Un tableau de tâches qui ne reflète pas la réalité détruit la transparence — c'est alors pire que pas de tableau, parce qu'il induit en erreur ;
   • inspection : on regarde régulièrement le résultat et le processus. Sans inspection régulière, rien ne peut être corrigé ;
   • adaptation : on change le plan en fonction de ce qu'on a constaté. L'inspection sans adaptation est un rituel vide : on regarde des indicateurs, on constate qu'ils sont mauvais, et on change.

   Les cinq valeurs Scrum

   Commitment, focus, ouverture, respect, courage. Deux méritent un mot : l'ouverture suppose que l'équipe et les parties prenantes admettent que le plan initial était une estimation, pas une promesse ; le courage désigne la capacité à dire qu'un engagement ne tiendra pas, a eviter un scenario un scenario pessimiste, à demander de l'aide. Une équipe qui ne pratique pas le courage declare des"I'll" qu'elle ne tiendra pas, et le Sprint se termine en échec pour tout le monde.

   Le test honnête : « Scrum mais »

   Le symptôme le plus courant de l'échec de Scrum n'est pas son absence, c'est sa déformation. La phrase à surveiller est « Scrum, mais… » :

   • « Scrum, mais le chef de projet décide de tout » → plus d'autonomie d'équipe ;
   • « Scrum, mais le sprint ne peut jamais bouger » → plus de capacité d'adaptation ;
   • « Scrum, mais on ne montre rien avant la fin du sprint » → plus d'inspection avec les utilisateurs ;
   • « Scrum, mais on garde le même périmètre, seules les dates changent » → plus de valeur livrée.

   Chaque « mais » retire un pilier. Le diagnostic d'un Scrum qui ne fonctionne pas consiste presque toujours à trouver le « mais » qui a été ajouté.

3. Le cycle d'inspection et d'adaptation

   Un cycle court n'est pas un cycle agile. Un cycle de six mois dont on examine le résultat à la fin est un cycle en cascade avec des noms différents.

   La durée du cycle : le bon indicateur

   La question utile n'est pas « sommes-nous agiles » mais « combien de temps s'écoule-t-il entre une décision et la preuve qu'elle était bonne ? » Une équipe qui met trois semaines a mettre en oeuvre le verifier est en train de payer un risque pendant trois semaines, quel que soit le vocabulaire employé.

   Ce que le cycle court permet réellement

   1. réduire l'écart entre l'intention et la réalité : une erreur de conception coûte un cycle, pas un projet ;
   2. obtenir de l'information : chaque démonstration est une mesure du marché ;
   3. maintenir la motivation : voir le résultat de son travail est un facteur de performance mesuré, pas une évidence.

   Quand un cycle long reste justifié

   Certains contextes resistent a l'iteration : les systemes critiques où chaque modification doit être validée formellement, contrats qui imposent un calendrier, travail de recherche dont le résultat est incertain par nature. Dans ces cas, l'agilité porte sur la façon de travailler et d'apprendre, pas sur la durée du cycle. Forcer un cycle court là où il est contre-productif est aussi une erreur que l'immobilisme.

   Le point de vigilance sur la métrique

   Un cycle court qui ne produit aucune valeur livrable devient de l'agilité de façade : beaucoup de réunions, des burndowns verts, et un produit qui n'avance pas. Le test reste : à la fin du cycle, quelque chose de nouveau est-il réellement utilisable ? Si la réponse est non, le cycle est une cérémonie de plus.