Pourquoi ce sujet. Les 4 valeurs et les 12 principes se lisent en 10 minutes. Le Scrum Guide fait 13 pages. La difficulté commence dans les décisions quotidiennes. Certaines organisations installent les rendez-vous et les outils tout en retirant les moments où elles apprennent quelque chose.
Le corpus est court. C'est la pratique qui coûte.
Le manifeste fait 2 pages : 4 valeurs, 12 principes. Le Scrum Guide de 2020 fait 13 pages, rôles et rendez-vous compris. Un après-midi de lecture attentive suffit à couvrir l'ensemble du texte de référence.
La difficulté est ailleurs. Elle est dans ce qu'on fait un mardi matin quand la démo montre que la fonctionnalité ne sert à personne, quand une équipe dit qu'elle ne tiendra pas la date, quand une rétrospective désigne une décision de direction comme le principal frein. Ces situations demandent un jugement qu'aucun texte ne donne, et le texte ne prétend pas le donner.
L'Agile est simple à comprendre et difficile à pratiquer. Ça vaut aussi pour le piano, la conduite d'un entretien difficile et la cuisine. Personne n'a jamais appris ces choses en lisant.
Une certification Product Owner ou Scrum Master se passe après 2 jours de formation. Elle vérifie qu'une personne connaît le cadre : les rôles, les rendez-vous, les artefacts, le vocabulaire. C'est un contenu réel, et le vérifier a du sens.
Ce qu'elle ne mesure pas : la capacité à tenir une priorisation devant un dirigeant qui veut tout, à dire non à un commercial, à animer une rétrospective où quelqu'un accuse quelqu'un d'autre, à décider ce qu'on retire du sprint le jeudi. Ces gestes s'apprennent en situation, avec des erreurs, et ils prennent des mois.
Un PO certifié qui n'a jamais arbitré et un PO non certifié qui arbitre depuis 3 ans ne font pas le même métier. Le second est plus utile à une équipe.
L'incertitude demande plus de discipline, pas moins.
Une objection courante : sans spécification écrite ni plan à 18 mois, on travaille à l'estime. C'est l'inverse qui est demandé. Quand on ne peut pas savoir à l'avance quelle est la bonne solution, la seule façon d'avancer est de vérifier souvent où on en est.
Ça veut dire livrer quelque chose d'utilisable toutes les 2 semaines, le montrer à de vraies personnes, écouter ce qu'elles en font, et changer la suite en conséquence. Tenir ce rythme demande une rigueur que peu d'organisations ont : tests automatisés pour livrer sans casser, définition de fini partagée, discipline de réunion, et surtout l'acceptation d'apprendre qu'on s'est trompé.
Le cycle en V permet de repousser la mauvaise nouvelle à la recette. L'Agile la fait arriver toutes les 2 semaines. C'est plus exigeant à vivre.
« Agile » et « pas de documentation » sont deux choses différentes. Le manifeste dit qu'un logiciel qui fonctionne compte plus qu'une documentation exhaustive, et il ajoute explicitement que les éléments de droite gardent de la valeur.
On écrit moins de spécifications en amont. On écrit plus de tests, plus de critères d'acceptation, et on se parle davantage.
Ce qui disparaît quand on retire un rendez-vous.
Scrum a peu de règles, et chacune existe pour une raison. La phrase qui commence par « on fait Scrum, sauf que » est suivie, presque toujours, de la suppression d'un endroit où l'équipe apprenait quelque chose.
| Ce qu'on retire | Ce qu'on croit économiser | Ce qu'on perd |
|---|---|---|
| Pas de PO disponible | le temps d'une personne occupée ailleurs | l'arbitrage de priorité. L'équipe le fait à sa place, sur des critères techniques |
| Pas de revue | 1 heure toutes les 2 semaines | le retour des personnes qui utilisent. On apprend à la mise en production |
| Pas de rétrospective | 1 heure toutes les 2 semaines | le seul moment où l'équipe change sa façon de travailler |
| Pas de definition of done | une discussion pénible | l'accord sur ce que « fini » veut dire. Chaque fin de sprint le renégocie |
| Sprints à périmètre imposé | rien, on garde l'engagement | la capacité à retirer du périmètre. Il ne reste que la qualité à sacrifier |
Un cadre allégé de ses boucles de retour garde ses réunions et perd sa fonction. L'équipe continue de faire le Daily et le sprint, et personne n'apprend plus rien de nouveau.
Devant un « sauf que », se demander : qu'est-ce qu'on apprenait à ce moment-là, et où est-ce qu'on l'apprend maintenant ?
Les mêmes outils, retournés vers le contrôle.
Le Dark Agile décrit une organisation où le dispositif agile est complet et où chaque élément sert à surveiller l'exécution.
| L'outil | Sa fonction d'origine | Son usage retourné |
|---|---|---|
| Daily | l'équipe se coordonne entre elle, 15 minutes | chacun rend compte au manager de ce qu'il a fait hier |
| Vélocité | l'équipe prévoit ce qu'elle peut prendre au prochain sprint | indicateur de productivité, comparé entre équipes |
| Sprint | une boucle de retour de 2 semaines | une série de petites échéances à tenir |
| Backlog | les options ouvertes, réordonnées à chaque fois qu'on apprend | la liste des tâches à exécuter dans l'ordre |
| Rétrospective | l'équipe change sa façon de travailler | un tour de table où on ne parle pas des causes réelles |
Aucun de ces retournements ne demande de mauvaise intention. Un manager qui a passé 15 ans à suivre l'avancement voit dans le Daily un point d'avancement, et dans la vélocité un indicateur. Il utilise l'outil qu'il a sous la main avec les réflexes qu'il a.
La vélocité en donne l'exemple le plus net : dès qu'elle est observée comme mesure de performance, elle monte. Les équipes estiment plus large, et le chiffre augmente sans qu'une ligne de plus soit livrée. Le sujet est traité pour lui-même dans « la perversion des indicateurs ».
SAFe organise l'Agile sur plusieurs dizaines d'équipes. Le besoin est réel : coordonner 200 personnes demande autre chose que 3 équipes de 7. La difficulté est dans ce que la réponse ajoute : des niveaux de planification, des rôles de coordination, des instances d'arbitrage, un calendrier commun trimestriel.
Une organisation qui a mis 3 ans à raccourcir ses boucles de décision peut, avec ce type de dispositif, les rallonger à nouveau. Ça ne condamne pas SAFe, ça donne le point à surveiller : après installation, est-ce qu'une équipe met plus ou moins de temps qu'avant à changer d'avis sur ce qu'elle construit ?
Est-ce que l'organisation se sert de l'Agile pour apprendre et corriger ses décisions, ou pour faire exécuter un plan déjà arrêté ?
La question se pose à un prestataire, à un cadre installé, et à sa propre équipe dans 6 mois.