Arrêtez de choisir une méthode Agile. Choisissez une taille de promesse.

Version originale en anglais : https://dev.to/karkael/stop-picking-a-method-pick-a-promise-size-3956

Commençons par le débat auquel je ne crois plus : Scrum contre Kanban.

C'est un débat de vitrine, qui vend des certifications, remplit des conférences, permet de mettre une tribu dans sa bio. Et il masque quelque chose de bien plus utile : ces méthodes sont sœurs. Sur notre projet, nous en avons pratiqué trois en dix mois, et voici ce qui a réellement changé entre elles...

Rien ! Ni les cérémonies, ni l'outillage, ni la forme du projet, ni son périmètre fonctionnel, ni sa méthodologie au sens sérieux du terme. Nous avons tenu un daily, un weekly, un refinement et une rétro de la première semaine au dernier jour, dans les trois phases. (Scrum n'a ajouté que deux événements à cette liste : le planning et la démo — Guide Scrum 2020.)

Une variable a bougé. Une seule. La taille de la promesse — l'engagement d'une personne.

C'est tout. C'est tout l'article. Ce qui suit explique pourquoi ce curseur a bougé, et ce qui a fixé sa position : notre niveau de certitude à cet instant. Pas notre maturité, pas le conseil d'un coach, pas la promesse d'un framework.

Le décor

Anonymisé, mais la configuration est banale :

• 4 personnes, dont le lead-architecte — qui codait aussi
• Next.js / React, bibliothèque de composants dans Storybook, CI/CD conteneurisée
• Une équipe UX en parallèle dès le premier jour, encore en maquettage Figma quand nous livrions déjà

Dix mois jusqu'à la fin des évolutions, et notez que les phases ci-dessous se chevauchent. Ça compte plus que la séquence.

flowchart LR
    subgraph P1["Mois 1-3 · certitude = les composants"]
        direction TB
        K["KANBAN<br/>3 développeurs<br/>unité : un composant<br/>« combien de jours ? »"]
    end
    subgraph P2["Mois 4-6 · certitude = les pages"]
        direction TB
        S2["STRONG OWNERSHIP<br/>1 dev = 1 page<br/>unité : une page<br/>« combien de semaines ? »"]
    end
    subgraph P3["Mois 7-10 · certitude = tout le périmètre"]
        direction TB
        SC1["SCRUM · sprints de 2 semaines<br/>avant la MEP<br/>fonctionnel + qualité + sécurité<br/>« combien de storypoints ? »"]
        SC2["SCRUM · même cadence<br/>après la MEP<br/>évolutions post-lancement<br/>« combien de storypoints ? »"]
    end
    subgraph P4["Mois 11+ · plus d'évolution majeure"]
        direction TB
        K2["KANBAN À NOUVEAU<br/>TMA<br/>unité : un ticket<br/>« combien de jours ? »"]
    end
    K --> S2
    S1 --> S2
    S2 --> SC1
    SC2 --> K2

Relisez ce diagramme : pendant les trois premiers mois, nous faisions tourner deux méthodes en même temps. Les trois développeurs tiraient des composants sur un board Kanban tandis que l'architecte était déjà en strong ownership sur le socle et le pipeline de déploiement. Personne n'a trouvé ça bizarre, parce que personne ne « respectait un framework strict ». Chacun répondait à la question d'estimation qui correspondait à ce qu'il savait.

Mois 1 à 3 : Kanban, parce que nous avons copié Figma

« Nous avons construit la codebase dans l'ordre où l'UX la dessinait. »

Pas par hasard — par décision. Un design system ne se dessine pas page d'abord. Il commence par Typography, puis les couleurs et les espacements, puis les atomes, puis les Inputs, les Cards, la Table. Les pages viennent en dernier, parce qu'une page est un assemblage. Le front a donc suivi la même montée : Typography, les atomes, la Table, puis — seulement là — l'assemblage.

Le gain était calendaire, pas esthétique. Design et développement ont cessé de faire la queue l'un derrière l'autre pour avancer côte à côte : le Gantt s'est compressé au lieu de s'étirer. Attendre des maquettes de pages finies avant la première ligne de code nous aurait coûté ces trois mois, simplement.

Kanban convient à ce moment pour une raison précise : il demande de rendre le flux explicite et de limiter le travail en cours (The Kanban Guide) — il ne demande jamais de s'engager sur un périmètre. Nous n'avions aucun périmètre à engager. Nous avions une certitude sur les composants et rien d'autre : nous promettions donc en jours, et uniquement sur des composants.

Effet de bord qui justifie à lui seul le billet d'entrée : ces composants sont devenus un vocabulaire commun. Quand une spec a dit plus tard « un tableau filtrable à en-tête collant », personne n'a eu à deviner et personne n'a eu à le construire.

Mois 4 à 6 : un dev, une page. Et non, ce n'est pas de l'Extreme Programming.

Puis les maquettes sont devenues des pages entières, puis des parcours. Un ticket a cessé d'être « développer Pagination » pour devenir « développer la page de résultats » : des jours de travail sur une douzaine de fichiers. Quatre personnes dans un dépôt Next.js, et le curseur devait bouger : promettre en jours ne correspondait plus au travail.

Chaque développeur a donc possédé une page, de bout en bout. Route, récupération des données, composition, tests. L'architecte a continué de posséder le socle, et relisait tout. Même board, mêmes dailies, même rétro — promesse plus grande.

J'ai entendu appeler ça de l'Extreme Programming. C'est l'inverse.

XP prescrit explicitement la propriété collective du code : « la convention explicite que chaque membre de l'équipe est non seulement autorisé, mais a le devoir positif, de modifier n'importe quel fichier si nécessaire » (Agile Alliance) — pratique renommée « Shared Code » dans la seconde édition du livre de Beck. Ce que nous faisions se range dans une autre case de la taxonomie de Martin Fowler sur la propriété du code : le strong ownership (seul le propriétaire modifie le module), adouci en weak ownership (les autres peuvent, mais consultent). Fowler dit ouvertement son aversion pour le strong ownership, et sa raison est solide : un changement trivial qui traverse une frontière devient une négociation.

Deux choses ont rendu le nôtre bon marché :

• La couche partagée est restée collective. Composants, tokens, utilitaires — n'importe qui, n'importe quand. La propriété portait sur les pages, qui partageaient des composants mais pas de logique.
• La phase 1 a payé la phase 2. Les pages étaient indépendantes parce que trois mois de Kanban avaient déjà extrait tout le partageable. Tentez le strong ownership sur des pages qui partagent de la logique métier, et ça vous fera mal.

Si vous y allez, rendez la propriété exécutable plutôt que sociale : un fichier CODEOWNERS fait demander automatiquement par GitHub la relecture du propriétaire des chemins touchés (GitHub Docs). Et traitez-la comme une rotation, pas comme un titre.

Mois 7 à 10 : Scrum, parce que « terminé » voulait enfin dire quelque chose

Deux mois avant la MEP, le travail restant a changé de nature, pas de taille : trous fonctionnels transverses, accessibilité, états d'erreur, performance, revue de sécurité. Les 20 % ennuyeux qui font 80 % de la qualité perçue.

Ce travail a une propriété que le précédent n'avait pas : il est finissable. Un Sprint est un conteneur de durée fixe avec un Sprint Goal et une Definition of Done (Guide Scrum) : un dispositif d'écoulement de stock, pas un dispositif de productivité. En Kanban, nous aurions tiré des améliorations indéfiniment, parce qu'il y en a toujours une de plus.

Nous avons fait des Sprints de 2 semaines. Volontairement plus longs que les deux habituelles : les sujets de sécurité et de qualité se découpent mal en quinzaines sans produire des fonctionnalités à moitié durcies, et à quatre, la charge de cérémonie d'une cadence bimensuelle était disproportionnée. C'est là que notre Definition of Done a pris des dents — les items de sécurité sont devenus des critères de sortie explicites plutôt que de bonnes intentions, ce qui est la version pratique de ce que l'OWASP appelle intégrer la sécurité dans le pipeline au lieu de la greffer à la fin (OWASP DevSecOps Guideline).

Un ajustement au passage : nous avons commencé à répondre en storypoints, même si les storypoints n'apparaissent nulle part dans le Guide Scrum. Le framework demande que les éléments soient dimensionnés ; nous avons ajouté ce concept pour se mesurer. Ce qui confirme plutôt le propos — ce que nous avons adopté est une unité de promesse, pas une religion.

Puis nous sommes passés en production — et nous avons continué à sprinter deux mois de plus. Le backlog post-lancement était fait de vraies évolutions : des fonctionnalités repoussées pour tenir la date, et la première salve de demandes venues des utilisateurs réels. Même cadence, même Definition of Done, mêmes promesses de trois semaines.

Les objections honnêtes

« Le strong ownership crée des silos de connaissance. » C'est la critique standard et c'est la bonne à soulever — mais sur notre projet, elle n'a pas mordu. Les congés sont arrivés, les uns ont couvert les autres, rien ne s'est bloqué. La raison : la codebase était correctement déclarée et documentée, le code était lisible, et tout passait en relecture par les pairs. Les silos sont un symptôme de code illisible plus merges non relus. Corrigez ces deux-là et la propriété cesse d'être un fief.

« Changer trois fois de méthode a dû vous coûter cher. » Moins qu'on ne croit, et voici le mécanisme : la catégorisation en épiques JIRA et un rituel de refinement pour les storypoints existaient très tôt dans le projet — bien avant Scrum, et à la lettre ils n'appartiennent ni au Kanban ni au strong ownership. Le travail était déjà catégorisé et déjà discuté collectivement. Chaque transition a donc changé un nombre, pas un système. C'est l'argument pratique en faveur de cérémonies stables dont on ne laisse bouger que la promesse.

Là où les tenants de XP gardent raison : le pair programming, le trunk-based development et l'intégration continue attaquent les collisions de merge de face, sans tracer aucune frontière organisationnelle, et distribuent la connaissance comme effet de bord plutôt que comme discipline à entretenir. Si votre équipe binôme déjà bien, essayez cette voie d'abord — vous n'aurez peut-être jamais besoin de faire quitter « les jours » au curseur.

Une dernière chose : la MEP n'est pas un événement méthodologique

Regardez à nouveau la chronologie. La date la plus scrutée de tout le projet — le lancement — est le seul moment où rien n'a changé dans notre façon de travailler. Même Scrum, mêmes Sprints de trois semaines, même board, tout droit à travers. Nous étions en production, et la taille de la promesse est restée exactement où elle était.

Le curseur est redescendu deux mois plus tard, et pour une raison complètement différente : les évolutions se sont épuisées. Ce qui restait était petit, indépendant, imprévisible et sans aucun périmètre à engager — un bug, une correction de contenu, une montée de version. Dimensionner ça en storypoints et l'enfermer dans des promesses de trois semaines ajoute de la cérémonie à un travail qui n'a aucun stock à écouler. La TMA est donc redevenue un Kanban, et nous avons recommencé à répondre en jours.

C'est le signe que c'est la certitude qui commande, et pas le calendrier. Les deadlines, les lancements et les comités de pilotage donnent l'impression qu'ils devraient déplacer votre méthode. Ils ne le font pas. Ce qui la déplace, c'est ce que vous savez — et après le lancement, sur un produit stable, vous en savez moins sur la semaine prochaine que pendant le Sprint. Le curseur est un potentiomètre, pas une échelle. Le nôtre est monté dix mois puis redescendu, et ce n'est pas une régression.

Ce que je dirais à mon moi passé

Arrêtez de demander « quelle méthode Agile convient à ce projet ». Demandez « quelle taille de promesse pouvons-nous honnêtement tenir ce mois-ci » — le nom du framework découle de la réponse, et ce sera le débat de quelqu'un d'autre.

Avez-vous déjà déplacé ce curseur en cours de projet ? Qu'est-ce qui vous a dit qu'il était temps ?

Sources : Manifeste Agile · Open Guide to Kanban · Agile Alliance — Collective Code Ownership · Martin Fowler — Code Ownership · GitHub Docs — About code owners · Guide Scrum 2020 · OWASP DevSecOps Guideline