La méthodologie est la couche supérieure

Les pratiques de livraison logicielle forment une pile avec trois couches, et la plupart des équipes essaient de les adopter dans le mauvais ordre.

Couche 1 : Fondamentaux. Contrôle de source, suivi du travail, communication d'intention, habitudes d'estimation et traçabilité. Ce sont les pratiques que ce cours couvre. Elles sont indépendantes de la méthodologie — une équipe Scrum et une équipe Kanban en ont toutes deux besoin, et elles se ressemblent presque identiquement dans les deux contextes.

Couche 2 : Méthodologie. Scrum, Kanban, XP ou un hybride. C'est ici que vous choisissez une cadence (sprints ou flux continu), définissez des rôles (ou choisissez explicitement de ne pas le faire) et adoptez des cérémonies (mêlées quotidiennes, rétrospectives, sessions de planification). La méthodologie donne à une équipe un rythme et une structure — mais elle suppose que les fondamentaux sont déjà en place.

Couche 3 : Mise à l'échelle. SAFe, LeSS, Lean Portfolio Management ou patterns de coordination maison. Cette couche n'importe que lorsque plusieurs équipes doivent coordonner la livraison. Elle suppose que les fondamentaux et la méthodologie fonctionnent au niveau de l'équipe.

La pile importe parce que chaque couche dépend de celle en dessous. Une équipe qui exécute Scrum sans suivi de travail solide passera la moitié de chaque réunion de planification de sprint à redécouvrir ce qui est en cours. Une organisation qui adopte SAFe sans rétrospectives fonctionnelles au niveau de l'équipe mettra à l'échelle le dysfonctionnement, pas la livraison.

La plupart des « transformations agiles » échouent parce qu'elles commencent à la couche 2 ou 3. Elles achètent un outil, embauchent un coach, renomment des réunions — et se demandent ensuite pourquoi la vélocité ne s'améliore pas. La réponse est presque toujours la même : les fondamentaux n'étaient pas là.

Chaque méthodologie suppose que vous avez déjà les bases. Scrum suppose que vous pouvez suivre le travail dans un backlog, commiter du code dans un dépôt partagé et estimer l'effort avec assez de cohérence pour planifier un sprint. Kanban suppose que vous pouvez visualiser les éléments de travail, mesurer le temps de cycle et tracer un ticket de la demande à la livraison. XP suppose que vous pouvez écrire des tests, réviser du code et déployer fréquemment.

Aucune de ces hypothèses n'est énoncée dans les guides de méthodologie, parce que les auteurs les considéraient évidentes. Mais pour de nombreuses équipes, elles ne sont pas évidentes — elles sont aspirationnelles. Et quand une équipe adopte une méthodologie sans les fondamentaux, la méthodologie devient du théâtre : les cérémonies ont lieu, les artefacts existent, mais les résultats ne changent pas.

Vous avez vu cela. L'équipe qui exécute la planification de sprint mais ne peut pas répondre « à quoi nous sommes-nous engagés lors du dernier sprint? » parce que les tickets n'ont pas été mis à jour. L'équipe qui fait des mêlées quotidiennes mais ne peut pas partager les progrès parce que la moitié du travail n'est pas suivie. L'équipe qui tient des rétrospectives mais ne peut pas agir sur les insights parce qu'il n'y a pas de système pour assigner et suivre les actions.

La solution n'est pas d'abandonner la méthodologie. La solution est de bien faire les fondamentaux d'abord, puis de superposer la méthodologie par-dessus. C'est l'ordre que ce cours suit : les modules 2 à 4 couvrent les fondamentaux (contrôle de source, tickets, estimation), et le module 5 vous aide à choisir quelle méthodologie — le cas échéant — adopter une fois que la fondation est solide.