Rechercher dans ce blog

03 décembre 2025

(6/8) Diagnostiquer un train agile avec le modèle de seuils

 Série "Ce que les colonies de fourmis enseignent à l'agilité"




Dans les cinq premiers articles de cette série, j'ai exploré comment les fourmis s'organisent collectivement : le syndrome du noyau actif, les prothèses cognitives nécessaires à l'auto-organisation, le passage des castes fixes aux rôles flexibles, le leadership distribué, et le PI Planning comme jeu de biens publics.

Aujourd'hui, je propose d'appliquer le modèle de seuils à un usage pratique : diagnostiquer un train agile avant qu'il ne casse.

Parce qu'un RTE qui attend les symptômes (burnout, vélocité qui s'effondre, turnover) arrive trop tard.

Observer une colonie pour comprendre ses déséquilibres

Deborah Gordon observe une colonie de Pogonomyrmex barbatus depuis trois décennies. Elle a appris à repérer les signaux faibles qui indiquent qu'une colonie va mal.

Une fourmi qui sort du nid toutes les 30 secondes alors que les autres sortent toutes les 5 minutes : seuil d'activation trop bas. Elle porte seule une charge que le groupe devrait partager. Si elle meurt ou s'épuise, la colonie perd un maillon critique.

Des fourmis qui restent au fond du nid pendant que d'autres s'activent : seuil d'activation trop haut. Elles ne réagissent jamais aux signaux d'urgence. Si la colonie fait face à une crise, elles ne se mobiliseront pas.

Des fourmis qui ne font plus qu'une seule tâche, même quand d'autres tâches sont urgentes : spécialisation rigide. Le seuil pour les autres tâches est devenu si élevé qu'elles ne réagissent plus. Si l'environnement change, la colonie ne s'adapte pas.

Ces déséquilibres ne se voient pas au premier coup d'œil. Mais quand on sait les repérer, on peut intervenir avant l'effondrement.

Dans un train agile, c'est pareil.

Les 4 seuils pathologiques d'un train agile

Le modèle de seuils que j'ai décrit dans l'article 2 s'applique au diagnostic d'un train. Voici les 4 déséquilibres que je recherche systématiquement quand j'accompagne une transformation.

Seuil 1 : Le seuil trop bas (surcharge chronique)

Ce que c'est : Une équipe dont le seuil d'activation est devenu si bas qu'elle réagit à tout. Elle porte 80% de la charge du train. Elle intervient sur toutes les dépendances critiques. Elle est sur tous les fronts.

Pourquoi c'est un problème : C'est le syndrome du noyau actif (article 1). Cette équipe va s'épuiser. Si elle craque, le train s'effondre.

Signaux observables :

  • Vélocité stable ou croissante, mais verbatims d'épuisement en rétro
  • Cette équipe est sollicitée dans presque toutes les dépendances inter-équipes
  • Les seniors de cette équipe commencent à partir ou à demander des pauses
  • Le Scrum Master signale une charge mentale élevée

Questions à se poser comme RTE :

  • Est-ce que cette équipe porte des compétences critiques que les autres n'ont pas ?
  • Est-ce que son seuil bas vient d'une expertise technique ou d'une dynamique relationnelle ("on sait qu'ils vont dire oui") ?
  • Quelles compétences peut-on redistribuer pour remonter leur seuil ?

Action corrective :

  • Identifier les compétences monopolisées par cette équipe
  • Former d'autres équipes pour créer de la redondance
  • Refuser explicitement certaines sollicitations ("cette équipe ne prend plus de nouvelles dépendances ce PI")
  • Célébrer publiquement leur contribution pour éviter le ressentiment

Seuil 2 : Le seuil trop haut (sous-utilisation chronique)

Ce que c'est : Une équipe dont le seuil d'activation est si élevé qu'elle ne réagit jamais aux signaux d'urgence. Elle livre son périmètre, mais ne s'implique pas dans les problèmes collectifs du train.

Pourquoi c'est un problème : Cette équipe est une ressource dormante. Elle pourrait contribuer davantage, mais ne le fait pas. Le train perd en capacité collective.

Signaux observables :

  • Vélocité correcte, mais aucune participation aux dépendances inter-équipes
  • Cette équipe n'est jamais sollicitée pour aider les autres
  • Lors du PI Planning, elle valide rapidement ses objectifs sans négocier de dépendances
  • Verbatims en rétro : "On fait notre job, mais on ne sait pas trop ce que font les autres"

Questions à se poser comme RTE :

  • Est-ce que cette équipe a des compétences qui seraient utiles ailleurs ?
  • Est-ce que son périmètre est trop isolé du reste du train ?
  • Est-ce qu'elle a été découragée dans le passé quand elle a voulu s'impliquer ?

Action corrective :

  • Créer des Features transverses qui obligent cette équipe à collaborer
  • La solliciter explicitement pendant le PI Planning ("votre expertise sur X nous manque pour cette Feature")
  • Reconnaître publiquement sa contribution quand elle s'implique
  • Si le seuil reste trop haut : questionner la pertinence de cette équipe dans le train

Seuil 3 : Le seuil rigide (spécialisation figée)

Ce que c'est : Une équipe dont le seuil d'activation pour certaines tâches est devenu si élevé qu'elle ne fait plus qu'une seule chose. Elle s'est hyperspécialisée. Elle ne peut plus s'adapter.

Pourquoi c'est un problème : C'est le modèle des fourmis Atta (article 3). Efficace dans un environnement stable, fragile face à l'imprévu. Si le contexte change, cette équipe ne peut pas pivoter.

Signaux observables :

  • Cette équipe ne travaille que sur un type de Features (ex : uniquement du front, uniquement de l'infra)
  • Elle refuse systématiquement les Features qui sortent de son périmètre technique
  • Verbatims : "C'est pas notre job", "On n'a pas les compétences pour ça"
  • Les autres équipes la perçoivent comme un goulot d'étranglement

Questions à se poser comme RTE :

  • Est-ce que cette spécialisation est voulue (component team) ou subie (manque de formation) ?
  • Est-ce que l'organisation renforce cette rigidité (manager qui protège son périmètre) ?
  • Quelle serait la première compétence à élargir pour rendre cette équipe plus flexible ?

Action corrective :

  • Créer des Features transverses qui obligent à sortir du périmètre habituel
  • Former l'équipe sur des compétences adjacentes (ex : front → fullstack)
  • Faire du pair programming avec d'autres équipes
  • Embarquer le management pour qu'il ne renforce pas les silos

Seuil 4 : Le seuil absent (free-riding)

Ce que c'est : Une équipe qui n'a aucun seuil d'activation pour contribuer au bien commun. Elle profite de l'alignement créé par les autres sans y contribuer.

Pourquoi c'est un problème : C'est le free-riding (article 5). Si trop d'équipes font ça, le bien commun s'effondre. Le PI Planning devient du théâtre.

Signaux observables :

  • Cette équipe arrive au PI Planning sans Features préparées
  • Elle ne remonte aucun risque ni dépendance
  • Elle valide des objectifs vagues ("améliorer la performance", "refactoring technique")
  • En cours de PI, elle découvre des blocages qu'elle aurait dû voir au PI Planning

Questions à se poser comme RTE :

  • Est-ce que cette équipe comprend les règles du jeu (DoR, préparation PI) ?
  • Est-ce qu'elle a été sanctionnée dans le passé pour avoir remonté des risques (effet "don't shoot the messenger") ?
  • Est-ce que le management la protège du collectif ?

Action corrective :

  • Imposer la Definition of Ready : Features sans DoR = pas affichées au PI Planning
  • Rendre visible publiquement qui a préparé et qui n'a pas préparé (pré-PI Planning obligatoire)
  • Créer un ROAM board public où chaque équipe doit coller au moins 1 risque
  • Si le comportement persiste : questionner la légitimité de cette équipe dans le train

Grille de diagnostic rapide pour RTE

Voici comment j'utilise ce modèle en pratique quand j'accompagne un train.

Avant le PI Planning :

  • Je regarde qui a préparé ses Features → détection seuil absent (free-riding)
  • Je regarde la répartition des dépendances → détection seuil trop bas (une équipe sur tous les fronts)

Pendant le PI Planning :

  • Je regarde qui négocie activement vs qui valide passivement → détection seuil trop haut (sous-utilisation)
  • Je regarde qui refuse systématiquement certaines Features → détection seuil rigide (spécialisation figée)


En cours de PI :

  • Je regarde les verbatims des rétros → "épuisement" = seuil trop bas, "on ne sait pas ce que font les autres" = seuil trop haut
  • Je regarde qui est sollicité sur les dépendances non planifiées → confirmation seuil trop bas

En fin de PI :

  • Je cartographie les 4 types de seuils pathologiques
  • Je priorise les actions correctives pour le prochain PI

Cette grille me permet de passer d'une animation "symptomatique" (réagir aux crises) à un pilotage systémique (anticiper les déséquilibres).

Ce que j'ai vu sur le terrain

Train en déséquilibre : secteur bancaire

8 équipes. Projet réglementaire. Délais serrés.

Diagnostic après PI #2 :

  • Seuil trop bas : 2 équipes portaient 70% des dépendances inter-équipes. Verbatims : "On n'en peut plus."
  • Seuil trop haut : 3 équipes ne participaient jamais aux dépendances. Verbatims : "On fait notre job, c'est tout."
  • Seuil rigide : 1 équipe refusait tout ce qui n'était pas du back-end pur.
  • Seuil absent : 2 équipes arrivaient systématiquement non préparées au PI Planning.





Actions correctives mises en place :

  • Formation croisée entre les 2 équipes en surcharge et les 3 en sous-charge
  • Features transverses obligatoires pour casser la rigidité de l'équipe back-end
  • Pré-PI Planning obligatoire avec checklist publique pour les équipes free-riders

Résultat PI #4 :

  • Charge redistribuée : les 2 équipes en surcharge sont passées de 70% à 45% des dépendances
  • Les 3 équipes en sous-charge ont commencé à contribuer activement
  • L'équipe rigide a accepté sa première Feature fullstack
  • Taux de préparation passé de 40% à 75%

Le train n'était pas encore parfait, mais il ne s'effondrait plus.

Train équilibré : Chez Renault 

70 personnes. Multi-pays. 8 PI documentés.

Diagnostic maintenu sur toute la durée :

  • Aucun seuil pathologique majeur détecté après le PI #3
  • Charge répartie de manière relativement homogène
  • Spécialisations présentes mais flexibles (les équipes acceptaient de sortir de leur zone de confort)
  • Taux de préparation stable à ~85%

Comment on a évité les déséquilibres :

  • Pré-PI Planning systématique dès le PI #1 → détection précoce du free-riding
  • Features transverses régulières → prévention de la rigidité
  • Formation continue → redistribution des compétences critiques
  • Reconnaissance publique → prévention de l'épuisement du noyau actif

Le modèle de seuils n'a pas servi à corriger des crises. Il a servi à ne jamais les laisser arriver.

Ce que je retiens

Le modèle de seuils n'est pas qu'un outil d'analyse. C'est une boussole de pilotage.

Les 4 seuils pathologiques :

  1. Seuil trop bas = surcharge chronique (équipe "noyau actif")
  2. Seuil trop haut = sous-utilisation (équipe "dormante")
  3. Seuil rigide = spécialisation figée (équipe "caste")
  4. Seuil absent = free-riding (équipe "passager clandestin")

Un RTE qui sait les repérer peut intervenir avant l'effondrement.

Avant le burnout. Avant le turnover. Avant l'échec du PI.

Les fourmis nous ont montré comment fonctionne le modèle de seuils. Maintenant, on peut l'utiliser pour diagnostiquer nos trains.

Et vous ? Quels seuils pathologiques voyez-vous dans votre train ? Quelles équipes portent trop ? Quelles équipes ne contribuent pas assez ?

Dans le prochain article, nous explorerons un modèle d'organisation radicalement différent : celui du Bataillon d'Exploration dans L'Attaque des Titans. Quand l'organisation militaire rencontre l'intelligence distribuée des fourmis, quel hybride en ressort ?

Références

Posted by on

Aucun commentaire:

Enregistrer un commentaire

Inscription à : Publier les commentaires (Atom)