Il y a un moment précis où l’on reconnaît une organisation dont le flux est structurellement cassé. Ce n’est pas quand les choses vont mal. C’est quand les choses vont bien — en apparence — et que les principes sautent quand même.

La limite de WIP que tout le monde avait acceptée ? Elle saute parce que ce projet-là est « stratégique ». La règle de ne pas démarrer une initiative sans discovery validée ? Elle saute parce que le client a signé et qu’on ne peut pas décevoir. Le protocole de documentation des dépendances ? Il saute parce qu’on n’a pas le temps.

Ces moments ne sont pas des accidents. Ce sont des révélateurs. Ils montrent que l’organisation n’avait pas de Kernel — elle avait des intentions.

La différence entre un principe et une intention, c’est le coût de le tenir quand ça devient difficile.

Le Kernel du FOS, c’est l’ensemble des règles que l’organisation s’engage à respecter même sous pression. Pas des bonnes pratiques. Pas des recommandations. Des règles avec des dents — c’est-à-dire avec des conséquences visibles quand elles sont violées.

Dans cet article, je développe les cinq règles que j’ai identifiées comme fondatrices d’un Kernel opérationnel. Ce ne sont pas les seules possibles — un Kernel se construit et s’adapte au contexte. Mais ce sont celles que j’observe le plus systématiquement absentes dans les organisations qui souffrent d’un flux cassé.

Pourquoi le Kernel est la composante fondatrice

Dans l’article précédent, j’ai présenté les quatre composantes du FOS : Kernel, Loops, Scorecard, Playbooks. Le Kernel n’est pas la plus visible. Il n’est pas non plus la plus facile à mettre en place. Mais il est la condition de validité des trois autres.

Sans Kernel, les Loops dérivent. Les boucles de décision existent, mais les décisions qu’elles produisent s’évaporent à la première contrainte. Le WIP décidé en Loop Portfolio est ignoré dès qu’un sponsor pousse un projet urgent.

Sans Kernel, la Scorecard devient décorative. On mesure, on affiche, on commente — mais les métriques ne changent rien aux comportements. Elles servent à documenter les glissements, pas à les prévenir.

Sans Kernel, les Playbooks ne sont jamais activés. Les procédures existent. Personne n’ose les invoquer contre la pression d’un directeur ou d’un client.

Le Kernel est ce qui donne au FOS sa consistance dans le temps. C’est le contrat que l’organisation passe avec elle-même.

Les cinq règles fondatrices

Règle 1 — Le WIP systémique est limité et non négociable

Aucune nouvelle initiative ne démarre si le portefeuille actif dépasse un seuil défini. Ce seuil n’est pas arbitraire — il est calculé à partir de la capacité réelle des équipes, du nombre de dépendances en cours, et du lead time observé. Et surtout, il s’applique à tous les projets, y compris ceux portés par la direction générale.

En pratique : Une organisation de taille intermédiaire avec 8 équipes produit définit un WIP portfolio maximum de 12 initiatives actives. Quand une 13e arrive, le comité de pilotage doit explicitement en arrêter une avant de la lancer. Pas de passe-droit, pas d’exception stratégique.

Anti-pattern : Le projet du DG est toujours « hors WIP ». En pratique, il y a 18 initiatives actives pour 6 équipes. Le WIP limit est affiché sur le mur de la salle de transformation. Personne ne l’invoque jamais.

Règle 2 — Aucune initiative ne démarre sans owner identifié et disponible

Toute initiative qui entre dans le flux doit avoir un responsable nommé — pas un sponsor lointain, pas un comité — une personne physique, disponible à hauteur minimum définie (souvent 50 à 70 % de son temps), capable de prendre des décisions sans escalade constante. Lancer une initiative sans owner disponible, c’est créer volontairement un goulot futur.

En pratique : Avant chaque Loop Portfolio trimestrielle, une liste des initiatives candidates est préparée. Pour chacune, on identifie l’owner proposé et on vérifie sa disponibilité réelle. Si l’owner pressenti est déjà à 100 %, l’initiative est mise en attente — pas lancée avec un owner théorique.

Anti-pattern : On nomme un chef de projet déjà sur trois autres projets comme « responsable » pour que le budget soit validé. Tout le monde sait qu’il ne sera pas disponible. Six mois plus tard, l’initiative est en retard et personne n’en est surpris.

Règle 3 — Toute dépendance est documentée, datée et assignée

Une dépendance non documentée est un risque caché. Le Kernel exige que toute dépendance entre équipes — qu’elle soit technique, décisionnelle ou informationnelle — soit rendue visible avec trois éléments : qui la détient, quel est le délai attendu de résolution, et qui est responsable de la suivre. Une dépendance sans ces trois éléments n’existe pas officiellement — et donc ne peut pas être pilotée.

En pratique : Chaque équipe maintient un registre de dépendances mis à jour en Loop hebdomadaire. Les dépendances non résolues après deux semaines remontent automatiquement en Loop Portfolio. Le registre est public — visible de toutes les équipes et de la direction.

Anti-pattern : Les dépendances sont gérées à la tête du client dans des conversations de couloir. Certaines équipes ont une liste mentale de ce qu’elles attendent des autres. Personne n’a la vision systémique. Le blocage n’est découvert qu’au moment du retard.

Règle 4 — Pas de livraison sans feedback loop active

Toute initiative en cours doit disposer d’au moins un mécanisme de retour utilisateur actif — pas planifié, pas promis, actif. Aucune période de développement ne dure plus de quatre semaines sans un point de validation externe. Cette règle s’applique aussi aux initiatives internes et aux refactorisations techniques : le « client » peut être un utilisateur interne, mais il doit exister et être consulté.

En pratique : Avant de valider le démarrage d’une initiative en Loop Portfolio, on demande systématiquement : quelle est la première validation utilisateur prévue, et dans combien de semaines ? Si la réponse est « à la livraison finale dans six mois », l’initiative est renvoyée en discovery.

Anti-pattern : Les équipes livrent en continu au sens technique du terme — la CI/CD fonctionne — mais les utilisateurs ne voient les changements que lors d’une grande release trimestrielle. La feedback loop technique est présente. La feedback loop de valeur est absente. On confond les deux.

Règle 5 — La performance du système prime sur la performance des équipes

Aucune décision d’arbitrage, de priorisation ou d’évaluation ne peut reposer uniquement sur des métriques d’équipe. Le lead time end-to-end, le WIP systémique et la flow efficiency sont toujours présents dans les discussions de pilotage. Une équipe qui performe dans un système dégradé n’est pas en situation de succès — et une équipe dont les métriques locales sont moyennes peut contribuer à un flux systémique excellent.

En pratique : Lors de chaque Loop Portfolio, le premier point à l’ordre du jour est la revue des métriques systémiques — avant tout point sur l’avancement des projets individuels. Les équipes sont évaluées sur leur contribution au flux global, pas seulement sur leur vélocité propre.

Anti-pattern : Le management récompense les équipes qui livrent vite, indépendamment de ce que ça coûte au système. Une équipe rapide qui crée des dépendances en aval pour d’autres équipes est considérée comme performante. Le flux global se dégrade pendant que les bonus sont distribués.

Comment construire son propre Kernel

Ces cinq règles ne sont pas un template à copier-coller. Elles sont un point de départ. Chaque organisation doit construire son propre Kernel — en fonction de sa maturité, de sa culture, de ses pathologies spécifiques.

La méthode que je recommande pour construire un Kernel en partant de zéro tient en trois étapes.

Étape 1 — Diagnostiquer les violations récurrentes

Avant de poser des règles, listez les situations où votre organisation se contredit systématiquement. Quels principes déclarez-vous respecter et violez-vous régulièrement ? Où sont les « exceptions » qui sont en réalité la norme ? Ces violations sont les endroits où votre Kernel doit être le plus explicite.

Étape 2 — Formuler des règles testables

Une règle de Kernel qui ne peut pas être vérifiée n’est pas une règle. Chaque principe doit avoir une formulation qui permet de dire clairement si on le respecte ou non. « Nous favorisons la collaboration » n’est pas une règle de Kernel. « Aucune dépendance non documentée dans notre registre depuis plus de 48h » en est une.

Étape 3 — Définir le coût de la violation

Une règle sans conséquence est une intention. Pour chaque règle du Kernel, définissez ce qui se passe quand elle est violée : qui est alerté, quelle décision est prise, quel est le processus de remise en conformité. Ce n’est pas une question de sanction — c’est une question de sérieux.

Un Kernel se teste à la première exception. Si la première violation ne déclenche aucune réaction visible, le Kernel n’existe pas encore. Il est en cours de construction.

Ce que le Kernel n’est pas

Quelques clarifications nécessaires, parce que le concept est souvent mal interprété quand on le présente pour la première fois.

Le Kernel n’est pas un règlement intérieur. Il ne couvre pas tout. Il ne cherche pas à prévoir chaque situation. Il couvre les quelques points de rupture systémiques — ceux qui, quand ils lâchent, dégradent le flux de toute l’organisation.

Le Kernel n’est pas figé. Il évolue — lentement, délibérément. Quand une règle ne fait plus sens, on la révise. Mais on ne la révise pas sous pression. On la révise lors d’une Loop Apprentissage, à froid, avec des données.

Le Kernel n’est pas punitif. Son objectif n’est pas de piéger les équipes ou de créer de la bureaucratie. C’est de protéger le flux contre les décisions prises sous pression qui coûtent cher à toute l’organisation — y compris à ceux qui les prennent.

Le Kernel n’est pas l’affaire des équipes seules. C’est un engagement de la direction. Si le Kernel peut être court-circuité par un sponsor senior, il n’a aucune valeur. La crédibilité du Kernel se construit par l’exemple — et notamment par la capacité de la direction à le respecter elle-même, en public.

Par où commencer

Si vous deviez choisir une seule règle pour commencer votre Kernel, je recommande toujours la règle 1 : la limite de WIP systémique.

Pourquoi ? Parce qu’elle est visible, mesurable immédiatement, et qu’elle crée instantanément une conversation sur les arbitrages réels. Quand vous posez la question « combien d’initiatives avons-nous actuellement en cours ? » et que personne dans la salle ne connaît la réponse précise — vous avez votre premier diagnostic. Et votre premier argument pour construire le reste.

Le Kernel ne se décrète pas en atelier de deux jours. Il se construit par accumulation, violation après violation assumée, règle après règle tenue. C’est un processus d’apprentissage organisationnel autant qu’un document.

Mais il faut commencer. Et commencer par une règle qu’on est prêt à tenir vraiment — même quand ça fait mal.

Une note sur les seuils du Kernel. Les règles posées ici fixent des seuils — WIP maximum, durée de dépendance, fréquence de feedback. Ces seuils sont un point de départ. À terme, ils gagnent à être calibrés sur des données historiques réelles plutôt que fixés arbitrairement. La couche d’interprétation statistique du FOS — présentée dans l’article suivant — permet précisément de transformer ces seuils intuitifs en seuils probabilistes défendables face à n’importe quel comité de direction.

Celle-ci va vous parler de votre problème.

Et si vous êtes PM, founder, ou responsable produit … ce problème, vous le vivez probablement en ce moment même.

Vous construisez des features que personne ne vous a demandées.

Pas parce que vous êtes mauvais.

Pas parce que vous ne faites pas d’interviews utilisateurs. Pas parce que vous n’êtes pas dans une démarche produit…

Mais parce que vos utilisateurs ne parlent pas dans votre portail de feedback.

Ils sont trop polis en interview.

Leurs comportements sont biaisés lors de sessions d’observation.

Eux, Ils parlent sur G2. Sur Trustpilot. Dans l’App Store. Sur Google Play. Sur Capterra.

Ils laissent des avis détaillés, des plaintes précises, des demandes explicites, sur des plateformes que vous ne surveillez pas, ou peu, que vous ne pouvez pas surveiller manuellement. Parce que vous avez autre chose à faire.

Résultat ?

Vous construisez à l’aveugle. Vous priorisez à l’instinct, malgré vos tableaux, vos outils, votre WSJF. Et vos vraies utilisateurs, ceux qui ont pris le temps d’écrire ce qu’ils ressentent, n’ont jamais été entendus.

On vient de changer ça.

Aujourd’hui, je vous présente BuildSense en avant-première.

Un outil que j’aurais voulu avoir il y a 5 ans quand je travaillais avec des équipes produit qui naviguaient à vue.

BuildSense fait deux choses que personne ne faisait vraiment bien ensemble.

La première : votre radar produit permanent.

Dès que vous créez votre produit sur BuildSense, quelque chose se passe en coulisses.

L’IA part scanner le web. Trustpilot, G2, Capterra, App Store, Google Play. Elle trouve tout ce que vos utilisateurs ont dit sur votre produit sans que vous ayez rien demandé.

Elle catégorise. Elle classe. Elle extrait.

Et elle vous présente les premières idées de fonctionnalités à construire directement basées sur ce que vos vrais utilisateurs ont écrit, ailleurs, sans filtre, sans biais de politesse.

Vous arrivez sur BuildSense avec un produit vide.

Vous en repartez avec une liste d’idées priorisées par l’IA en moins de 2 minutes.

Ce n’est pas de la magie.

C’est juste écouter là où vos utilisateurs parlent vraiment.

Ensuite, pour les clients sur un plan payant, ce monitoring ne s’arrête pas. Chaque jour, BuildSense continue de surveiller. Chaque nouveau signal remonte automatiquement. Vous êtes toujours dans la boucle. Sans effort.

La deuxième : votre roadmap devient publique. Et vivante.

Vos utilisateurs soumettent des idées. Ils votent. Ils commentent.

Et ils voient, en temps réel, ce que vous planifiez, ce que vous construisez, ce que vous venez de livrer.

Quand leur idée passe en “In Progress” ?

Ils reçoivent un email.

Ce petit email change tout.

Il dit : “Vous avez été entendu.”

Il transforme un utilisateur passif en ambassadeur actif.

Il crée ce lien rare entre un produit et ses utilisateurs : celui où les gens ont l’impression de construire quelque chose ensemble.

Ce n’est pas juste une roadmap.

C’est votre promesse publique que vous écoutez vraiment.

Où en est BuildSense aujourd’hui ?

L’alpha vient de se terminer.

La beta vient de commencer.

Le produit tourne. Les premières intégrations sont en place. Les premiers utilisateurs font leurs premiers tests.

On n’a pas encore tout ouvert.

Mais si vous lisez cette newsletter, vous faites partie des premiers. Et les premiers ont toujours un avantage.

Ce que je vous invite à faire maintenant :

→ Créez votre compte sur buildsense.so

→ Créez votre premier produit … et regardez l’IA analyser vos avis en temps réel

→ Laissez votre feedback ou demandes de fonctionnalités directement sur notre roadmap publique : La même que celle que vous pourrez construire ! On dogfoode notre propre produit !

→ Vous pouvez aussi tester un peu notre ia en jouant avec la démo… mais ça ne vaut pas le fait de créer votre produit à vous !

Ce que vous allez vivre dans ces 5 premières minutes, c’est exactement la valeur qu’on promet à vos utilisateurs.

Une dernière chose.

On prépare notre lancement Product Hunt.

Le jour J, on aura besoin de vous. Pas de votre argent. Pas de votre temps.

Juste un vote. Et 10 secondes de votre journée.

Je vous tiendrai au courant.

En attendant… si vous voulez nous aider : testez. Cassez. Dites-moi ce qui ne va pas.

C’est comme ça qu’on construit quelque chose qui tient.

Robin

CEO BuildSense — Corporate Mavericks

P.S : Si vous avez une app mobile ou un SaaS avec des avis en ligne, BuildSense va vous surprendre dès la première minute. Pas besoin de configuration. Il trouve vos avis tout seul.

Il y a une faille dans tous les systèmes de pilotage par métriques … y compris le FOS tel que je l’ai décrit jusqu’ici. Cette faille est silencieuse, et c’est précisément pour ça qu’elle est dangereuse.

La voici : toute métrique de flux varie naturellement. Le lead time n’est pas une constante : c’est une distribution. Le WIP fluctue. La flow efficiency oscille. Ces variations sont inhérentes à tout système complexe. Elles ne signifient pas forcément que quelque chose va mal.

Mais sans cadre d’interprétation statistique, on ne sait pas distinguer une fluctuation normale d’un signal réel de dégradation ou d’amélioration. On sur-réagit à du bruit. Ou, plus souvent, on ignore un signal faible jusqu’à ce qu’il devienne une crise visible.

Une moyenne qui reste stable peut cacher une variance qui explose. Un système peut se dégrader pendant des semaines avant que sa moyenne ne bouge. C’est précisément ce que les tableaux de bord classiques ne voient pas.

Cet article introduit la couche d’interprétation probabiliste du FOS. Ce que j’appelle la Flow Intelligence Layer. Elle ne remplace pas les métriques descriptives. Elle les rend actionnables en répondant à la vraie question décisionnelle : ce que j’observe est-il statistiquement significatif, ou dois-je attendre davantage de données avant d’agir ?

Le problème fondamental : piloter avec des moyennes

Prenons un exemple concret. Votre lead time end-to-end est mesuré chaque semaine depuis six mois. Voici une séquence typique :

Semaine 1 : 9,2 semaines

Semaine 2 : 10,1 semaines

Semaine 3 : 9,8 semaines

Semaine 4 : 11,4 semaines

Semaine 5 : 10,7 semaines

Semaine 6 : 12,1 semaines

Semaine 7 : 11,8 semaines

Semaine 8 : 12,9 semaines

Moyenne des 4 premières semaines : 10,1 semaines. Moyenne des 4 dernières : 12,1 semaines. Écart : +2 semaines, soit +20 %.

Est-ce une dégradation réelle ou une fluctuation normale ? Sans inférence statistique, vous ne pouvez pas répondre à cette question avec rigueur. Vous pouvez avoir une intuition. Vous pouvez débattre en réunion. Mais vous ne pouvez pas décider avec une base probabiliste solide.

C’est le problème des tableaux de bord classiques : ils montrent des valeurs. Ils ne disent pas si ces valeurs sont significatives. La décision “agir ou attendre” reste alors une affaire d’intuition habillée en données.

Les trois outils statistiques fondateurs

La Flow Intelligence Layer du FOS repose sur trois outils statistiques. Ils ne nécessitent pas de formation avancée en statistiques pour être compris et utilisés mais ils nécessitent d’être introduits explicitement dans le système de pilotage.

1. Les Control Charts (cartes de contrôle)

Le control chart (ou carte de contrôle de Shewhart) est l’outil le plus puissant et le plus sous-utilisé dans le pilotage du flux. Il permet de distinguer visuellement deux types de variation :

La variation commune (bruit) : les fluctuations inhérentes au système, prévisibles, qui ne nécessitent pas d’intervention. Tenter de corriger du bruit est l’une des erreurs les plus coûteuses en management. Deming l’appelait « tampering ».

La variation spéciale (signal) : une variation qui sort du comportement normal du système, statistiquement improbable, qui indique qu’un facteur externe a changé. C’est ça qui nécessite une action.

Un control chart se construit simplement sur une série de mesures de lead time :

Moyenne (μ) : calculée sur la période de référence

Limite de contrôle supérieure : μ + 3σ

Limite de contrôle inférieure : μ - 3σ

Règle de base : tout point hors des limites = signal. On arrête. On cherche la cause.

Règle secondaire : 8 points consécutifs du même côté de la moyenne = dérive. Signal.

Dans notre exemple précédent, un control chart aurait révélé dès la semaine 6 que la trajectoire constituait une dérive statistiquement significative, pas parce que la valeur a dépassé une limite absolue, mais parce que le pattern de 5 points consécutifs au-dessus de la moyenne est statistiquement improbable sous l’hypothèse d’un système stable.

Avant : Notre lead time est passé de 10 à 12 semaines. C’est préoccupant.

Avec inférence : Notre control chart indique une dérive significative depuis la semaine 5 : 5 points consécutifs au-dessus de la moyenne historique. La probabilité que ce soit du bruit est inférieure à 3%. Nous activons le Playbook Dérive de Lead Time. (Et pour que tu découvre en profondeur les playbooks… il faudra attendre encore un poil ;) )

2. Les intervalles de confiance

Une métrique sans intervalle de confiance est une information incomplète. La moyenne du lead time à 10,1 semaines ne dit rien sur la fiabilité de cette estimation ni sur la variabilité du système.

L’intervalle de confiance à 95 % répond à une question précise : si on tire un nouvel échantillon de la même population, dans 95 % des cas la vraie valeur sera dans cet intervalle. C’est une mesure d’incertitude… et l’incertitude est une information décisionnelle à part entière.

Lead time moyen : 10,1 semaines

Écart-type : 1,2 semaines

n (nombre de mesures) : 20

Intervalle de confiance : 10,1 ± 0,54 → [9,56 ; 10,64]

Interprétation : on est à 95% certain que le vrai lead time moyen du système est entre 9,56 et 10,64 semaines.

Pourquoi c’est “décisionnellement” important ? Parce que deux systèmes avec le même lead time moyen peuvent avoir des intervalles de confiance très différents. Un système avec IC [9,5 ; 10,7] est prévisible. Un système avec IC [6 ; 14,2] est chaotique — même si la moyenne est identique. La décision d’investir, de scaler, ou d’alerter doit intégrer cette information. C’est pourquoi il est aussi souvent préférable d’utiliser la médiane comme nous allons le voir plus bas.

Avant : Notre lead time moyen est de 10 semaines.

Avec inférence : Notre lead time est de 10 semaines ± 2,1 (IC 95%). L’intervalle s’est élargi de 40% ce trimestre, ce qui indique une instabilité croissante du système indépendamment de la moyenne.

3. Les percentiles de distribution

La moyenne est une mesure trompeuse dans les systèmes à longue queue ce que sont presque tous les systèmes de flux de valeur. Une minorité d’items avec un lead time très long tire la moyenne vers le haut et masque la réalité de la majorité.

Les percentiles donnent une image bien plus fidèle :

Le P85 est particulièrement utile pour les engagements clients : si vous prometttez une livraison en 14 semaines, vous tiendrez cet engagement dans 85% des cas. C’est un niveau de confiance explicite bien supérieur à un engagement basé sur la moyenne qui, par définition, est dépassée dans la moitié des cas.

Les Playbooks du FOS peuvent ainsi utiliser le P95 comme seuil de déclenchement : si la durée observée d’une dépendance dépasse le P95 historique, on active l’escalade pas avant, pas après.

Avant : Si la dépendance dure plus de 10 jours, on escalade.

Avec inférence : Si la durée de la dépendance dépasse le P95 historique (actuellement 9,3 jours), on active le Playbook Escalade. Le seuil se recalcule automatiquement chaque trimestre.

Comment enrichir chaque composante du FOS

Le Kernel probabiliste

Le Kernel classique (décrit dans le 2nd article de cette série) pose des règles absolues : « on ne lance pas si le WIP dépasse N ». C’est nécessaire et non négociable. Mais ces seuils sont souvent fixés de façon arbitraire, par intuition ou par consensus.

La couche probabiliste permet de calibrer ces seuils sur des données historiques réelles. Le seuil de WIP n’est plus un chiffre round négocié en atelier. C’est le seuil au-delà duquel la probabilité d’augmentation du lead time dépasse un niveau de risque accepté … par exemple 60 %.

Règle Kernel classique : WIP ≤ 12 initiatives actives

Règle Kernel enrichie : WIP ≤ seuil au-delà duquel

P(lead time > 14 semaines) > 60%

[recalibré chaque trimestre sur données réelles]

Ce que ça change : le seuil devient défendable face à un CFO ou un CEO. On ne dit plus « on a décidé que 12 c’était le maximum ». On dit « au-delà de 12, nos données montrent que le risque de dépasser nos engagements clients devient inacceptable ». C’est une conversation différente.

Les Loops décisionnelles

Dans une Loop Portfolio classique, la décision de lancer ou d’arrêter une initiative repose sur des arguments qualitatifs : valeur stratégique, urgence, pression des sponsors. Ces arguments sont légitimes. Ils deviennent bien plus robustes quand ils sont complétés par une évaluation probabiliste du risque systémique.

Question Loop Portfolio classique :

→ Cette initiative est-elle prioritaire ?

Question Loop Portfolio enrichie :

→ Quelle est la probabilité que le lancement de cette initiative augmente notre lead time moyen de plus de 20% ce trimestre ?

[basée sur le WIP actuel, la capacité disponible, les dépendances connues]

Cette question n’est pas rhétorique. Elle est calculable approximativement, avec des données historiques de quelques trimestres. Et elle transforme le débat d’opinion en discussion de risque. Un CPO qui dit « je pense qu’on peut absorber ce projet » est challengeable. Un modèle qui dit « la probabilité de dégradation est de 73% » est discutable sur ses hypothèses … ce qui est une conversation bien plus productive.

La Scorecard comme instrument scientifique

C’est la transformation la plus visible. Une Scorecard classique affiche des valeurs ponctuelles. Une Scorecard enrichie par l’inférence affiche des distributions, des tendances statistiquement qualifiées, et des signaux d’alerte fondés sur des probabilités.

La différence n’est pas cosmétique. Elle change ce qu’on peut décider. La première ligne du tableau dit : « le lead time a augmenté ». La deuxième dit : « le lead time a augmenté et c’est statistiquement significatif la probabilité que ce soit du bruit est inférieure à 5% ». Ce n’est pas la même décision.

Les Playbooks à déclenchement statistique

Aujourd’hui, les Playbooks se déclenchent sur des règles de seuil absolues, par exemple une dépendance depuis N jours, un WIP au-dessus de M. Ces seuils sont utiles mais rigides. Ils ne s’adaptent pas à la variabilité historique du système.

Un Playbook à déclenchement statistique se déclenche quand une observation est statistiquement anormale par rapport à l’historique du système, pas par rapport à un seuil arbitraire. C’est plus robuste, moins émotionnel, et plus difficile à contourner politiquement.

Playbook Dépendance — version classique :

→ Déclenchement si durée > 10 jours

Playbook Dépendance — version statistique :

→ Déclenchement si durée > P95 historique des dépendances résolues

ET si control chart indique un point hors limites

[Le seuil se recalibre automatiquement chaque trimestre]

Ce que ça change philosophiquement

Les articles précédents de cette série posent une affirmation centrale :

Le flux ne se décrète pas. Il se pilote.

La couche probabiliste enrichit cette affirmation d’une précision fondamentale :

On ne pilote pas un système complexe avec des moyennes. On pilote avec des probabilités.

Ce n’est pas un détail technique. C’est un changement épistémologique. Un système complexe (et une organisation est un système complexe) ne se comporte pas de façon déterministe. Il se comporte de façon probabiliste. Ses métriques sont des distributions, pas des points. Ses tendances sont des signaux à qualifier, pas des faits à constater.

Ignorer cette réalité, c’est piloter un avion en regardant une photo de l’altitude plutôt qu’un altimètre avec une marge d’erreur. L’information est là. L’incertitude est masquée. Et c’est l’incertitude qui tue.

Par où commencer concrètement

Introduire l’inférence statistique dans un système de pilotage ne nécessite pas de refondre tout le dispositif. Voici une séquence progressive :

Étape 1 : Construire un control chart sur le lead time. C’est le ROI le plus rapide. Prenez vos données de lead time des 3 derniers mois, calculez la moyenne et l’écart-type, tracez les limites de contrôle à ±3σ. Regardez si des points en sortent. Si oui, vous avez votre premier signal statistique réel.

Étape 2 : Introduire les percentiles dans vos engagements. Remplacez « on livrera en moyenne en 10 semaines » par « on livre en moins de 13 semaines dans 85% des cas ». C’est plus honnête, plus utile pour les partenaires, et plus robuste quand vous êtes challengé.

Étape 3 : Ajouter les intervalles de confiance à la Scorecard. Une ligne de plus par métrique. L’impact sur la qualité des discussions en Loop Portfolio est immédiat.

Étape 4 : Recalibrer les seuils du Kernel sur données réelles. Remplacez vos seuils arbitraires par des seuils calculés à partir de votre historique de flux. C’est un travail d’une demi-journée par trimestre. C’est aussi la conversation la plus productive que vous aurez avec votre équipe de direction.

Aucune de ces étapes ne nécessite un data scientist. Elle nécessite un tableur, des données historiques, et une culture organisationnelle prête à piloter par les probabilités plutôt que par les certitudes confortables.

La vraie sophistication n’est pas de produire des modèles complexes. C’est d’avoir le courage institutionnel de dire : nous ne savons pas avec certitude … et voici ce que les données nous permettent de dire avec 80% de confiance.

Il est temps d’ouvrir le capot.

Le FOS repose sur quatre composantes. Elles ne sont pas des modules indépendants à activer à la carte : elles forment un système. Chacune a un rôle distinct, des exemples concrets, et des anti-patterns caractéristiques que j’ai observés dans des organisations qui tentent (souvent partiellement) de les mettre en place.

Un système de pilotage du flux n’est pas la somme de bonnes pratiques. C’est l’articulation de boucles, de règles et de métriques qui se tiennent mutuellement.

1. Le Kernel

Les principes non négociables, ce que le système garantit quelles que soient les pressions.

Le Kernel est le cœur invariant du FOS. C’est l’ensemble des règles que l’organisation s’engage à respecter même - et surtout - quand la pression est forte, quand les deadlines approchent, quand le comité de direction demande d’accélérer.

Sans Kernel, un système de pilotage du flux se déforme à la première contrainte. Les limites de WIP sautent dès qu’un projet est « prioritaire ». Les métriques sont contournées dès qu’elles montrent quelque chose d’inconfortable. Le système devient un décor.

Le Kernel n’est pas une liste de bonnes pratiques. C’est un contrat organisationnel. Il répond à une question simple : qu’est-ce que nous ne ferons jamais, quoi qu’il arrive ?

Exemples de principes Kernel

Limite de WIP systémique : aucune nouvelle initiative ne démarre si le portefeuille en cours dépasse un seuil défini. Pas d’exception pour les projets « stratégiques ».

Mesure du système avant la mesure des équipes : on ne pilote jamais la performance individuelle des équipes sans mesurer d’abord la performance du flux global. Une équipe rapide dans un système lent n’est pas une victoire.

Décision explicite sur les dépendances : toute dépendance entre équipes est documentée et fait l’objet d’un accord formel — délai, responsable, critère de résolution. Une dépendance non nommée est un risque caché.

Feedback loop minimale garantie : chaque initiative en cours dispose d’au moins une boucle de retour utilisateur active. Aucun développement ne dure plus de six semaines sans validation externe.

L’anti-pattern caractéristique

Le Kernel cosmétique. L’organisation affiche ses principes - souvent sur un mur, dans un wiki, en slide de onboarding. Mais ces principes ne sont jamais invoqués dans une vraie décision. Personne ne dit « on ne peut pas lancer ce projet, le WIP est au plafond ». Le Kernel n’a pas de dents. Il est décoratif.

Ce que j’observe fréquemment : les principes existent au niveau de l’équipe (Kanban, Definition of Done, WIP limits locales) mais disparaissent complètement au niveau du portefeuille. Le Kernel du FOS doit opérer aux deux niveaux simultanément.

2. Les Loops

Les boucles de décision et d’apprentissage — à la bonne fréquence, avec les bonnes personnes.

Les Loops sont le mécanisme vivant du FOS. Ce sont les moments organisés - à fréquences différentes - où le système se regarde, apprend, et décide. Sans Loops, le Kernel reste théorique et la Scorecard reste un dashboard que personne ne consulte vraiment.

La clé des Loops n’est pas leur fréquence. C’est leur articulation. Chaque boucle doit alimenter la suivante : ce que l’on apprend en hebdomadaire doit remonter en mensuel, ce que l’on arbitre en mensuel doit cadrer le trimestriel.

Les quatre Loops du FOS

Loop Portfolio (trimestrielle) : arbitrage des investissements au regard du flux réel. Quelles initiatives continuent ? Lesquelles s’arrêtent ? Où sont les goulots systémiques ? Cette boucle réunit les c-levels, les décideurs - CPO, CTO, CFO - avec des données de flux, pas des présentations de roadmap.

Loop Discovery/Delivery (hebdomadaire) : synchronisation entre l’exploration (ce qu’on apprend) et l’exécution (ce qu’on construit). Cette boucle détecte les désalignements avant qu’ils ne coûtent des semaines de retravailler.

Loop Run (continue / hebdomadaire) : surveillance des signaux faibles en production — incidents, dégradations, alertes de dette. Cette boucle permet d’agir avant que le problème ne remonte à la direction sous forme de crise.

Loop Apprentissage (mensuelle) : rétrospective systémique — pas au niveau équipe, mais au niveau organisation. Qu’est-ce que le flux nous a appris ce mois-ci ? Quels anti-patterns se répètent ? Quels Playbooks faut-il mettre à jour ?

L’anti-pattern caractéristique

Les Loops en silo. Chaque équipe a ses rituels (daily, sprint review, rétro). Le portfolio a son comité de pilotage trimestriel. Mais les deux ne se parlent pas. Ce que les équipes apprennent ne remonte pas. Ce que le portfolio décide ne descend pas avec le contexte nécessaire.

Le symptôme le plus visible : les équipes découvrent un changement de priorité par une réorganisation de backlog, pas par une décision expliquée. Les décideurs découvrent un blocage systémique au moment où il devient un retard de livraison, pas six semaines avant quand il était encore traitable.

Les Loops du FOS ne remplacent pas les rituels agiles des équipes. Elles créent le niveau au-dessus — le niveau systémique — qui manque presque toujours.

3. La Scorecard

Les métriques de flux — mesurer le système, pas les équipes.

La Scorecard est l’instrument de mesure du FOS. Elle répond à une question que la plupart des organisations ne savent pas poser correctement : est-ce que notre flux s’améliore ou se dégrade ?

La difficulté n’est pas technique. Elle est conceptuelle. La majorité des organisations mesurent la performance des équipes — velocity, taux de complétion, nombre de features livrées. Ce sont des métriques locales. Elles peuvent être excellentes pendant que le système se dégrade.

La Scorecard du FOS mesure le système.

Les métriques fondamentales

Lead Time end-to-end : le temps entre l’idée et la valeur en production. Pas le cycle time d’une équipe — le temps total, de la demande à l’impact. C’est la métrique mère du FOS.

Flow Efficiency : le ratio entre le temps actif (où quelqu’un travaille activement sur un sujet) et le temps total (lead time). Dans la plupart des organisations, ce ratio est inférieur à 20 %. 80 % du temps, le travail attend — une validation, une dépendance, une réunion.

WIP systémique : le nombre d’initiatives en cours au niveau du portefeuille. Pas par équipe — au niveau global. C’est l’indicateur avancé le plus fiable de la dégradation future du flux.

Taux de valeur livrée vs valeur engagée : ce qu’on avait prévu de livrer ce trimestre vs ce qui a réellement créé de la valeur mesurable. L’écart révèle la qualité des arbitrages, pas seulement l’efficacité de l’exécution.

L’anti-pattern caractéristique

Les proxy metrics. L’organisation mesure ce qui est facile à mesurer — story points, nombre de commits, taux de couverture de tests, vélocité des sprints — plutôt que ce qui compte vraiment. Ces métriques ne sont pas inutiles. Elles le deviennent quand elles remplacent les métriques systémiques au lieu de les compléter.

Le cas le plus fréquent : une direction qui pilote la transformation digitale avec un dashboard de velocity par équipe. La velocity monte. Le time-to-market, lui, ne bouge pas. Personne ne fait le lien — parce que personne ne mesure le lead time end-to-end.

La vanity agility — terme que j’emprunte aux praticiens du domaine — c’est exactement ça : des métriques qui donnent l’impression de progresser sans mesurer ce qui compte.

4. Les Playbooks

Les réponses documentées — décider vite et bien quand la situation se répète.

Les Playbooks sont la mémoire opérationnelle du FOS. Ce sont les réponses que l’organisation a documentées pour les situations récurrentes — les moments où le flux se bloque, où une décision s’impose, où un arbitrage doit être fait vite.

Sans Playbooks, chaque problème récurrent est traité comme s’il était nouveau. Les mêmes réunions ont lieu. Les mêmes débats s’ouvrent. Les mêmes décisions — souvent les mêmes mauvaises décisions — sont prises. L’organisation n’apprend pas. Elle répète.

Un Playbook n’est pas une procédure bureaucratique. C’est une décision prise à froid, quand on a le temps de bien réfléchir, pour ne pas avoir à la reprendre à chaud, quand on est sous pression.

Exemples de Playbooks FOS

Playbook Dépendance bloquante : que fait-on quand une équipe est bloquée par une dépendance externe depuis plus de N jours ? Qui est alerté ? Quel est le délai de résolution attendu ? Quand escalade-t-on ? Quelle est la règle de contournement si la dépendance ne peut pas être résolue à temps ?

Playbook WIP overflow : que se passe-t-il quand le WIP systémique dépasse le seuil du Kernel ? Qui décide quoi arrêter ? Selon quels critères ? Avec quel processus de communication vers les équipes impactées ?

Playbook Arbitrage d’urgence : une demande urgente arrive — incident client majeur, opportunité business inattendue. Comment l’intègre-t-on dans le flux sans tout désorganiser ? Quelle est la règle pour interrompre une équipe ? Quel est le coût de contexte accepté ?

Playbook Dette critique : quand la dette technique atteint un niveau qui menace la stabilité du flux, quel est le protocole ? Comment le signale-t-on à la direction ? Comment l’arbitre-t-on contre les initiatives produit en cours ?

L’anti-pattern caractéristique

Le Playbook qui n’est jamais activé. L’organisation a documenté des procédures — souvent dans Confluence, souvent bien écrites. Mais personne ne les consulte en situation réelle. Pourquoi ? Parce qu’elles n’ont pas été conçues comme des outils de décision, mais comme des livrables de transformation. Elles ont été produites pour montrer qu’on avait un process, pas pour être utilisées.

Un Playbook utile a trois caractéristiques : il est court (une page maximum), il contient une règle de déclenchement claire (si X alors Y), et il a été testé au moins une fois en situation réelle avant d’être considéré comme valide.

L’articulation qui fait le système

Ces quatre composantes ne valent rien isolément. Ce qui fait le FOS, c’est leur articulation :

Les Loops s’appuient sur la Scorecard pour prendre des décisions fondées sur des données de flux réelles, pas sur des impressions ou des rapports de status.

La Scorecard est cadrée par le Kernel pour éviter la dérive vers les proxy metrics et maintenir le focus sur ce qui compte vraiment.

Les Playbooks opérationnalisent les décisions des Loops pour que les bonnes décisions soient prises vite, de façon cohérente, sans rouvrir chaque débat.

Le Kernel garantit que les Playbooks restent alignés avec les principes fondateurs, même sous pression.

Un Kernel sans Loops, c’est une constitution sans gouvernement. Des Loops sans Scorecard, c’est une réunion sans données. Une Scorecard sans Playbooks, c’est un diagnostic sans traitement. Des Playbooks sans Kernel, c’est de la tactique sans stratégie.

Le FOS n’est pas un framework à adopter en bloc. C’est un système à construire progressivement — en commençant par le Kernel (poser les règles), en activant les Loops (créer les boucles), en instrumentant la Scorecard (mesurer le bon niveau), et en documentant les Playbooks au fur et à mesure que les situations récurrentes se présentent.

Dans les prochains articles, j’explorerai chaque composante en profondeur, avec des cas concrets et des templates opérationnels. Mais si vous ne deviez retenir qu’une chose : le flux ne se décrète pas. Il se pilote.

Ce paradoxe n’est pas une anomalie. C’est le symptôme d’un problème systémique que l’IA ne fait qu’amplifier : dans la plupart des organisations, ce n’est pas la vitesse d’exécution qui manque. C’est la capacité à faire circuler la valeur.

Autrement dit : on livre plus vite. Mais la valeur, elle, n’arrive toujours pas.

L’IA comme révélateur, pas comme solution

L’intelligence artificielle est en train de transformer profondément la façon dont les équipes travaillent. Elle augmente la productivité individuelle de manière spectaculaire : rédaction, analyse, génération de code, tests, documentation. Les gains mesurés sur les tâches discrètes sont réels. Ce ressenti est confirmé par le dernier rapport DORA sur les apports de l’intelligence artificielle dans l’IT.

Cependant, une organisation n’est pas une somme de tâches discrètes. C’est un système. Et un système a ses propres lois.

Quand vous accélérez chaque nœud d’un réseau engorgé, vous n’accélérez pas le réseau. Vous augmentez la pression aux points de rupture.

Ce que l’on observe concrètement dans les organisations qui déploient l’IA à grande échelle sans avoir résolu leur problème de flux :

Le WIP explose. Les équipes produisent plus d’artefacts que le système peut en absorber.

Les files d’attente s’allongent aux interfaces entre équipes - entre discovery et delivery, entre produit et architecture, entre tech et métier.

La dette technique s’accélère parce que la pression de livraison augmente sans que les garde-fous systémiques ne bougent.

Les feedback loops cassent — noyées sous le volume.

L’IA est un révélateur. Elle met en lumière, avec une brutalité inédite, ce que les organisations avaient réussi à dissimuler derrière la lenteur naturelle de l’exécution humaine : l’absence d’un système de pilotage du flux.

Le problème que tout le monde voit, et que personne ne nomme

Les symptômes sont universellement reconnus. Dans chaque organisation “qui vit du numérique” d’une certaine taille, vous trouverez : des roadmaps qui changent tous les trimestres sans que les équipes comprennent pourquoi ; des initiatives qui démarrent mais ne finissent pas ; des réunions de priorisation qui durent des heures et ne produisent pas de décision claire ; des métriques vertes partout, et pourtant une impression persistante que « ça n’avance pas » ; une dette technique qui s’accumule en silence jusqu’à devenir structurelle.

Ce que ces symptômes ont en commun ? Ils ne sont pas des problèmes de méthode. Ils ne sont pas des problèmes de talent. Ils sont des problèmes de flux : la valeur ne circule pas. Elle s’accumule, se perd, se réoriente, se dilue.

Et pourtant, la plupart des réponses organisationnelles restent au niveau structurel : on réorganise les équipes, on adopte un nouveau framework agile, on construit un product operating model, on nomme des chief product officers. Ces interventions sont nécessaires. Elles ne sont pas suffisantes.

Il manque une couche. Une couche opérationnelle et dynamique, qui ne définit pas comment l’organisation est structurée, mais comment la valeur circule dans cette structure.

POM et FOS : ce que l’un déclare, l’autre l’opérationnalise

Soyons précis sur les termes, parce que la confusion entre les deux nuit à l’action.

Le Product Operating Model (POM) - tel que Marty Cagan et le Silicon Valley Product Group le définissent dans Transformed - est un modèle conceptuel, pas une méthodologie ni un framework. Il rassemble un ensemble de premiers principes que les meilleures entreprises technologiques ont en commun : des équipes cross-fonctionnelles et responsabilisées, une stratégie orientée problèmes à résoudre plutôt que features à livrer, une culture de l’outcome plutôt que de l’output, une discovery continue pour valider avant de scaler.

Le POM est stratégique et culturel. Il répond à la question : dans quel état d’esprit et avec quelle structure l’organisation crée-t-elle de la valeur ? C’est un modèle de référence essentiel, fondateur, et probablement le cadre de pensée le plus rigoureux disponible pour les organisations produit aujourd’hui.

Mais le POM, par conception, ne répond pas à une question différente et complémentaire : comment la valeur circule-t-elle réellement dans cette organisation, au quotidien ?

Comment détecte-t-on les files d’attente avant qu’elles deviennent des blocages ? Comment synchronise-t-on les équipes sans créer de couplage excessif ? Comment mesure-t-on la performance du système - pas seulement celle des équipes individuelles ? Comment pilote-t-on les arbitrages en temps réel, entre ce qui est prévu et ce que le flux réel révèle ?

Ces questions sont opérationnelles. Elles supposent des boucles de décision, des métriques de flux, des règles explicites. Le POM les mentionne en filigrane - Cagan parle de CI/CD, de feedback loops, de releases fréquentes - mais il ne les outille pas. Il indique la direction. Il ne fournit pas le tableau de bord.

Le POM déclare les principes. Le FOS les rend opérables. L’un sans l’autre produit soit de la belle doctrine sans traction, soit de l’exécution sans cap.

Une autre façon de le dire : le POM est l’anatomie. Le FOS est la physiologie. Vous pouvez avoir une anatomie parfaite - de beaux organes, bien positionnés, des équipes empowered, un product leader légitime - et quand même avoir un corps qui dysfonctionne, parce que la circulation est mauvaise, les signaux ne passent pas, les engorgements s’accumulent sans être détectés.

Le FOS ne remplace pas le POM. Il le complète. Si vous n’avez pas encore de product operating model, commencez par là. Si vous en avez un (ou si vous êtes en train de le construire) le FOS est ce qui vous permettra de savoir s’il fonctionne vraiment, et d’agir quand ce n’est pas le cas.

Qu’est-ce que le FOS ?

Le Flow Operating System est un ensemble minimal et cohérent de boucles de pilotage, de métriques de flux, et de règles de décision qui rendent le passage « projet → produit » réellement opérable.

Le mot « système » est intentionnel. Le FOS n’est pas un framework à installer, ni une méthode de plus. C’est un operating system : un socle qui fait tourner le reste. Comme un OS informatique, il est invisible quand il fonctionne bien … et douloureux quand il est absent.

Il repose sur quatre composantes articulées :

Le Kernel — les principes non négociables et les contraintes du système. Ce que le FOS garantit quelles que soient les pressions. Par exemple : ne jamais lancer une nouvelle initiative si le WIP dépasse un seuil défini ; ne jamais mesurer la performance des équipes sans mesurer la performance du flux global.

Les Loops — les boucles de décision et d’apprentissage à différentes fréquences. Une boucle portfolio (trimestrielle) pour arbitrer les investissements au regard du flux réel. Une boucle discovery/delivery (hebdomadaire) pour synchroniser exploration et exécution. Une boucle run (continue) pour détecter les signaux faibles avant qu’ils ne deviennent des incidents.

La Scorecard — les métriques de flux, pas les métriques de proxy. Pas la velocity (une métrique d’équipe), mais le lead time end-to-end (une métrique de système). Pas le nombre de features livrées, mais le ratio valeur délivrée / valeur engagée.

Les Playbooks — les réponses documentées aux situations récurrentes. Que fait-on quand une dépendance bloque une équipe depuis plus de deux semaines ? Quel est le protocole quand le WIP dépasse le seuil d’alerte ? Comment arbitre-t-on entre deux initiatives en compétition pour les mêmes ressources ?

Ces quatre composantes ne fonctionnent pas en silo. Les Loops s’appuient sur la Scorecard pour décider. La Scorecard est cadrée par le Kernel pour éviter les dérives. Les Playbooks opérationnalisent les décisions des Loops. C’est leur articulation qui fait un système — pas leur simple coexistence.

Pourquoi maintenant ?

La question est légitime. Les problèmes de flux ne sont pas nouveaux. Lean, Kanban, Theory of Constraints… ces disciplines ont posé les fondations intellectuelles depuis des décennies. Alors pourquoi le FOS maintenant ?

Premièrement, la pression de l’IA crée une urgence nouvelle. Comme décrit plus haut, les organisations qui déploient l’IA sans résoudre leur flux n’accélèrent pas leur transformation. Elles accélèrent leur désordre. La fenêtre pour agir se réduit.

Deuxièmement, la maturité des approches produit crée un angle mort. De nombreuses organisations ont investi massivement dans leur Product Operating Model. Elles ont les principes. Elles n’ont pas les boucles opérationnelles pour les faire vivre. Le FOS est ce qui manque pour que le POM tienne ses promesses.

Troisièmement, la mesure devient enfin possible. Les outils de visualisation du flux, les plateformes de gestion de portefeuille modernes, les métriques DORA - tout cela crée une infrastructure de données qui n’existait pas il y a dix ans. On peut désormais instrumenter le flux de manière crédible et actionnable.

Ce que cela demande aux dirigeants

Le FOS n’est pas un sujet technique. C’est un sujet de direction.

Piloter par le flux, c’est accepter de mesurer ce que l’on préférait ne pas voir. C’est rendre visible le gaspillage, les dépendances cachées, les décisions qui ne se prennent pas. C’est arbitrer différemment - non plus en ajoutant des priorités, mais en choisissant ce qu’on arrête.

C’est aussi une question de langage. Quand le CFO demande « où en est-on ? », la réponse ne devrait pas être « nous avons livré 47 features ce trimestre ». Elle devrait être « notre lead time moyen est de 12 semaines, et voici les trois blocages systémiques qui l’expliquent ».

Le passage d’une organisation pilotée par les projets à une organisation pilotée par le flux est autant culturel que méthodologique. Il ne s’installe pas par décret. Il s’incube, se prouve sur des pilotes, se généralise progressivement.

La question n’est pas : « Êtes-vous agile ? » La question est : « Votre valeur circule-t-elle ? »

Et maintenant ?

Ce texte est le premier d’une série consacrée au Flow Operating System. Les prochains articles développeront les composantes du FOS en détail, documenteront des cas concrets, et proposeront des outils opérationnels - diagnostics, scorecards, canvas - pour cartographier et piloter votre flux.

Si vous vous reconnaissez dans les symptômes décrits ici : la lenteur malgré l’activité, les métriques vertes et les glissements de planning, la dette qui s’accumule en silence… alors la question du flux est probablement votre priorité numéro un. Avant l’IA. Avant la prochaine réorganisation. Avant le prochain framework.

Parce qu’un système sans flux n’accélère pas. Il s’emballe.

Imaginez une salle de classe ordinaire. Le professeur distribue à chaque élève trois mots mêlés, dont ils doivent reconstituer les anagrammes. Sans le savoir, deux groupes d’étudiants reçoivent des listes différentes. Le groupe A a deux premiers mots très faciles et un troisième mot abordable ; le groupe B a deux premiers mots impossibles (« WHIRLPOOL», « LEPRECHAUN») puis le même troisième mot abordable que le groupe A. Rapidement, la moitié de la classe (groupe A) trouve les deux premières anagrammes et lève la main, tandis que l’autre moitié (groupe B) reste perplexe et découragée. Lorsque tous passent au troisième mot, un étrange phénomène surgit : seuls les élèves du groupe A résolvent ce dernier mot, alors que personne du groupe B, qui avait échoué auparavant, n’y parvient.

Le professeur interroge alors les élèves du groupe B sur leur ressenti. Ils répondent tour à tour : « Je me suis senti stupide. J’avais envie de partir. J’ai perdu confiance en moi ». En bref, ils concluent, « Vous venez de faire l’expérience de l’impuissance apprise », comme l’explique la psychologue Charisse Nixon qui a mené cette expérience ludique. Cette anecdote simple illustre avec force le piège psychologique. Malgré un troisième exercice identique pour tous, ceux qui avaient cru échouer (groupe B) abandonnent d’emblée, convaincus que leurs efforts sont vains. Cette expérience pédagogique retrouve les fondements des travaux de Martin Seligman (1967-1975) : il avait observé que des chiens soumis à des chocs électriques incontrôlables finissaient par ne plus tenter d’échapper, même lorsqu’on leur en donnait l’occasion. En d’autres termes, après avoir appris qu’ils ne pouvaient rien changer, ils restaient passifs devant la solution.

Un autre exemple bien connu :

Quand un éléphanteau est petit, on l’attache avec une corde solide à un arbre.
Il tire, il lutte, il essaie de se libérer. Encore et encore.
Mais il est trop faible. Il finit par renoncer.

Les années passent.

Devenu adulte, il pèse plusieurs tonnes. Sa force pourrait arracher l’arbre sans effort.
Pourtant, une simple petite cordelette suffit à le retenir.

Pourquoi ?

Parce qu’il a appris, enfant, que tirer ne servait à rien.
Et cette croyance est devenue plus forte que sa puissance.

La corde ne le retient plus.
C’est son souvenir d’impuissance qui le retient.

Chronologie (après Seligman) :

• 1967 – Martin Seligman réalise ses fameuses expériences canines : des chiens reçoivent des décharges qu’ils ne peuvent éviter, et deviennent par la suite inertes, même quand on leur ouvre une issue de sortie.

• 1975 – Seligman consigne ces travaux dans son livre Helplessness, appliquant le concept à l’homme.

• 2015 – Charisse Nixon (Penn State) vulgarise ces mécanismes en classe avec l’anagramme : elle montre que l’absence de contrôle sur les deux premières épreuves plonge certains élèves dans la résignation.

• 2020s – Les concepts de “learned helplessness” et son contraire “learned optimism” s’invitent en psychologie de l’éducation et du management, à travers des expérimentations ou ateliers pour (re)donner confiance aux équipes.

Cette histoire d’anagrammes, aussi simple que marquante, résonne comme un défi pour tout leader : comment éviter de produire dans nos équipes des “élèves B” découragés ?

Mécanismes psychologiques clés

L’impuissance apprise se nourrit fondamentalement d’un sentiment de perte de contrôle. Lorsque des échecs répétés apparaissent hors de portée de nos actions, le cerveau assimile que « rien de ce que je fais n’y changera ». Pour Seligman, l’apprentissage de ce « je n’y arriverai jamais » induit trois déficits majeurs :

(1) cognitif – l’esprit n’arrive plus à discerner quand il pourrait en fait influencer les événements ;

(2) motivationnel – la personne cesse de produire toute réponse volontaire, préférant l’inaction ;

(3) émotionnel – un état dépressif apparaît, avec désespoir et chute d’estime de soi. Plus prosaïquement, nos élèves B avaient involontairement appris qu’ils étaient impuissants… et perdu toute énergie pour essayer.

D’après les recherches d’Abramson, Seligman et Teasdale, c’est aussi la façon d’expliquer les échecs qui importe. Un style d’explication pessimiste (attributions internes, stables et globales) rend vulnérable à la résignation. Par exemple, penser « J’ai échoué parce que je suis incompétent (interne), et ça ne changera pas (stable), et je rate tout dans ma vie (global) » favorise l’impuissance. À l’inverse, un style optimiste attribue les causes négatives à des facteurs externes, instables ou spécifiques (ex. « c’était juste exceptionnellement difficile aujourd’hui, cela ne veut pas dire que je ne vaux rien »). Cette vision optimiste protège : elle maintient l’idée qu’il existe un certain contrôle et que la situation peut s’améliorer. Ainsi, dans le monde pro, diagnostiquer et corriger le style attributionnel est crucial pour casser le cercle vicieux.

Un autre pilier est la perception du contrôle. Lorsque l’environnement semble imprévisible, chacun peut basculer vers la passivité. Dans les mots de Be and Become, si l’échec n’est ni accepté ni explicité, et que managers et collègues dirigent par la peur ou sans encouragement, l’enthousiasme initial des collaborateurs « tarit » pour céder à la « résignation et à l’impuissance apprise ». Autrement dit, nos cerveaux apprennent qu’ils sont impuissants et s’abandonnent à la passivité – même quand des issues sont disponibles (comme nos élèves B face au troisième mot). Seligman confirmait : l’effet typique d’une expérience incontrôlable est justement que l’animal (ou l’humain) devient passif, plus lent à apprendre de nouvelles actions, et développe un stress accru face à tout traumatisme future.

Pour conjurer cette spirale, on évoque aujourd’hui volontiers l’« état d’esprit de croissance » (« growth mindset »). Dans ce modèle, popularisé par la psychologue Carol Dweck, le défi et l’erreur ne sont pas vus comme des preuves d’incompétence, mais comme des opportunités d’apprentissage. Autrement dit, au lieu d’une croyance fixe « je n’y arriverai jamais », on peut cultiver une mentalité où l’effort mène à la maîtrise. L’une des clefs pour les managers est donc de favoriser les petites victoires. Célébrer des succès modestes (par exemple les progrès d’une tâche difficile) stimule le circuit de la récompense neurologique : cela renforce l’estime de soi, la confiance en ses capacités et la résilience de l’équipe. En pratique, instaurer des rituels pour signaler chaque accomplissement (même mineur) aide les individus à réassocier effort et succès, et construit patiemment un “capital confiance” qui prévient la frustration : chaque petite victoire rappelle que l’on peut agir sur les événements.

Parallèles concrets dans le contexte professionnel

Les mécanismes décrits ne s’arrêtent pas aux murs de la classe ; ils traversent les portes de notre travail, en particulier dans les équipes de développement logiciel. Voici quelques scénarios familiers où l’impuissance apprise guette :

• Onboarding d’un nouvel arrivant : Un développeur junior rejoint un projet legacy complexe, sans documentation ni pair pour l’aider. Face aux bugs qu’il ne parvient pas à résoudre seul, il peut rapidement se dire « je n’y arriverai pas » et refuser de tenter d’autres tâches. Comme les élèves B, il a peur d’échouer d’emblée. Un bon encadrement (“buddy system”, tâches graduées, premiers « petits succès » faciles à atteindre) lui donnerait le sentiment de contrôle et ferait pencher la balance vers le growth mindset.

• Revue de code (code review) : Lorsqu’un développeur reçoit systématiquement des commentaires négatifs sur son code (et presque jamais de compliments pour ce qui fonctionne), il finit par penser « mon code n’est bon à rien ». Ce feedback essentiellement punitif peut imiter un climat « jamais assez », renforcé par des formules comme « c’est pas pro, c’est mal fait, recommence ». Or, comme l’alerte l’article Sens & idées, les organisations qui accentuent le « jamais bien, jamais assez » sans retour constructif plongent leurs collaborateurs dans la démotivation et la croyance qu’ils ne valent rien. A contrario, un bon reviewer commence par reconnaître ce qui est correct avant de pointer les erreurs, formulant les critiques comme des pistes d’amélioration.

• Triage des bugs et dettes techniques : Une équipe submergée par un backlog de bugs et de dettes techniques peut développer la conviction que « ça ne s’en sortira jamais ». Chaque ticket rejeté ou repoussé à un sprint suivant renforce l’idée d’un fléau insurmontable. Si, de surcroît, les échecs s’enchaînent et qu’aucun changement de démarche n’est apporté, on observe souvent un désengagement : les développeurs traitent alors les bugs en « mode survie », sans chercher à s’améliorer (procrastination, passivité). Les signaux de cette impuissance sont clairs : baisse de motivation, fatalisme (« on a déjà tout essayé »), augmentation des retards ou de l’absentéisme. En revanche, introduire des « petits sprints de victoires » (notion d’A/B testing de tâches où on alterne par exemple 80% de maintenance pour 20% de développement innovant, ou des défis corrigés en pair-programming) permet de restaurer la confiance et la solidarité.

• Planificaiton de sprint et échecs cycliques : Si chaque sprint se termine par un échec (retards, livrables buggués) et que personne ne semble tiré de leçons, l’équipe risque de développer un « apathie collective ». Elle attendra passivement les instructions et évitera de proposer des solutions, même face aux problèmes qu’elle connaît bien. Un manager aveugle à ce phénomène peut s’étonner du silence résigné de ses développeurs, de leur manque d’initiative ou d’un cynisme croissant. Cela peut s’amplifier en télétravail ou équipes distribuées, où le lien social est plus faible : l’absence d’échanges réguliers accroît le sentiment de dérive hors contrôle.

• Feedback managérial et culture d’entreprise : Les pratiques de management ont un impact direct. Comme le décrit Olivier Viné (2025), un management autoritaire qui change tout le temps de cap, punit les erreurs, ne valide jamais les succès, et impose un contrôle rigide, construit un cercle vicieux d’impuissance. Au contraire, un style basé sur la confiance et la sécurité psychologique (où l’on admet l’erreur, où tout le monde peut poser des questions sans crainte) brise ce cycle. Par exemple, partager la charge émotionnelle (« on ne va pas se décourager, voici comment on compte procéder différemment cette fois ») et donner de l’autonomie à l’équipe les aide à retrouver le sentiment de contrôle sur leurs résultats.

• Diversité et inclusion : Dans un groupe homogène ou hétérogène, les micro-agressions ou stéréotypes peuvent amplifier l’impuissance apprise. Un membre issu d’une minorité ou dont les idées sont écartées peut internaliser les échecs comme une preuve de non-appartenance et, plus encore, étendre ce sentiment à l’équipe entière. Au contraire, un environnement inclusif où chacun valorise l’autre, écoute les suggestions (sans en rire ni les rejeter) contribue à la résilience collective. La prise en compte de perspectives variées et le fait de corriger les biais cognitifs (ex. organiser des revues de code en binôme mixte, encourager le feedback constructif et équitable) font figure de remèdes implicites à l’impression de “ne pas avoir sa place” ou “n’y connaître rien au code”.

Agir : interventions pratiques pour leaders et développeurs

Pour ne pas vous laisser piéger par l’apprentissage de l’impuissance, il existe quelques astuces. En voici quelques-unes :

• Concevoir des mini-expériences internes (A/B testing des tâches). Par exemple, testez deux approches sur une tâche complexe : l’une dans un cadre plus structuré (guidage progressif, séances de coaching) et l’autre en autonomie. Mesurez ensuite l’engagement et la réussite. Ce genre d’expérimentation permet de déceler si les blocages sont liés au processus ou au sentiment de compétence. Des métriques simples comme le taux de complétion des tickets ou l’investissement personnel renseignent sur la motivation retrouvée.

• Mettre en place des indicateurs-clés (KPIs) détecteurs d’impuissance : taux d’achèvement des tâches planifiées, niveau de participation aux réunions (par ex. nombre de nouvelles propositions dans le sprint retro), ou bien baromètres réguliers de satisfaction/anxiété. Par exemple, surveillez tout plancher soudain du « burn-down chart » non dû à un changement réel de charge (signal d’arrêt d’effort). Une chute brutale de feedback positif (enquêtes anonymes ou NPS interne) peut alerter sur un malaise latent. L’idée est de pouvoir réagir dès qu’un symptôme (désengagement, turnover qui monte, index d’« épuisement » interne) apparaît.

• Rituels de célébration et micro-victoires. Organiser chaque semaine un moment pour mettre en avant non seulement les grands succès, mais aussi les petites réussites (un bug complexe trié, une refactorisation légère, un nouveau concept appris). Un mur des succès, un kanban de taches accomplies, ou un partage d’apprentissages en fin de sprint renforce le sentiment de progrès. Comme l’explique Manager-Go, célébrer même les « plus petites victoires » soutient l’estime de soi et la cohésion d’équipe. Des rituels simples peuvent être instaurés : un « brag meeting » où chacun décrit un petit succès de la semaine, ou des points de jauge (« C’est noté ! ») dans les pull requests.

• Feedback reformulé et orienté solutions. Plutôt que de pointer uniquement ce qui ne va pas, un feedback bien formulé valorise d’abord les points positifs avant d’indiquer un axe d’amélioration. Par exemple, au lieu de dire « ton code est non respectueux des standards, recommence », on dira « ton algorithme respecte bien le principe X, super ! Pour la lisibilité, voyons comment appliquer la convention Y… ». Ce simple cadrage soutient la motivation : les développeurs perçoivent qu’ils ont progressé et que leur travail est pris en compte. De plus, inciter les managers à expliciter les tâches (objectifs clairs, périmètre défini) élimine l’anxiété liée au flou et prévient l’impuissance due au manque d’orientation.

• Pair-programming et mentorat. Le travail en binôme ou en petits groupes fournit un « filet de sécurité » psychologique. Un novice face à un challenge difficile est moins prompt à abandonner s’il est accompagné ; chaque jalon validé ensemble est une petite victoire partagée. Ce soutien renforce la confiance mutuelle (capital de sécurité psychologique) et incite à persister plutôt qu’à s’isoler. Le mentorat systématique des nouveaux par des vétérans expérimentés, avec des feedbacks réguliers, fait office de dérivation positive pour éviter l’apprentissage de la passivité.

• A/B testing de politique managériale. Pourquoi ne pas tester deux styles de leadership (par exemple, transparence totale vs communication mesurée) sur deux sous-équipes similaires et mesurer la différence d’engagement ou de turnover après quelques mois ? Ou encore « gamifier » le remontée de problèmes : proposer anonyme une solution contre une récompense symbolique (chocolat, badge) pour ceux qui rapportent des dysfonctionnements cachés. Ces interventions mesurables (design d’expériences, M&E) permettent de formaliser les intuitions managériales et d’identifier objectivement ce qui marche.

• Micro-succès et chantiers « en vase clos ». Quand un projet fait face à un obstacle apparemment insurmontable (une intégration UI ratée, par exemple), diviser le problème en sous-challenges étape par étape permet de multipler les petits succès. Par exemple, consacrer une journée à déminer juste l’environnement de test, puis une journée à créer un mock data, puis une journée à intégrer un composant isolé. Chaque mini-pilier achevé ravive la confiance. Cette approche d’« agilité tributaire » évite au développeur de voir tout l’édifice crasher en même temps.

• Rituels de soutien mutuel. Mettre en place des code pairing réguliers, des réunions d’équipe où chacun peut exposer un blocage sans jugement, ou des « retours d’expérience bienveillants » après chaque sortie de version aide à démystifier l’échec. Le manager encourageant les questions absurdes (« Qu’est-ce qui vous bloque, même si ça vous semble idiot ? ») instaure une zone de sécurité psychologique. Peu à peu, l’équipe apprend qu’aucun problème n’est insurmontable collectivement.

Chaque action s’accompagne naturellement de mesures simples : taux d’échec de sprint, nombre de commits/test fusionnés, issues closes, présence aux réunions, feedback 360°, enquêtes sur la climat, etc. Et surtout : le dialogue continu. Il s’agit de repérer les signaux faibles énoncés plus haut pour ajuster les actions rapidement.

Renouer avec le pouvoir d’agir

En conclusion, l’impuissance apprise est un « mal silencieux » qui ronge les équipes quand on ne lui apporte pas de remède. Comme dans la légende de Sisyphe, rouler la pierre en vain jusqu’à l’épuisement ne mène à rien. Au contraire, les enseignements de la psychologie positive et de la pratique agile nous rappellent que chaque individu (et chaque équipe) dispose d’une marge de manœuvre insoupçonnée. Un management avisé et humain consiste donc à exposer les collaborateurs aux bonnes doses de contrôle et de réussite, et à cultiver un environnement où l’effort est récompensé, où l’erreur enseigne, et où la solidarité prime sur la compétition.

Honnêtement, toutes les recommandations n’ont pas toujours été adoptées à la première écoute – loin de là ! Mais la plupart ont fini par faire leur chemin, et j’espère que vous saurez en tirer un peu de valeur, pour les glisser rapidement dans votre quotidien.

1. Cartographie : ne la négligez pas, même si elle est toujours imparfaite.
   Avant de vous lancer dans la moindre manœuvre de Conway inversée, prenez le temps de “visualiser l’état des choses”. La cartographie d’un système, de vos équipes, des flux de communication… tout cela est “toujours faux”, mais cet exercice reste fondamental pour prendre conscience de la complexité et poser les bases du changement. Au final, ce n’est pas tant le résultat de la cartographie qui compte, mais le processus et le dialogue que cette démarche enclenche.

2. Ne tombez pas dans la prescription magique.
   Croire que vous pouvez “prescrire les rapports sociaux dans l’entreprise” comme s’il suffisait d’aligner votre organigramme sur votre architecture technique revient à sous-estimer la dimension humaine (et les risques associés !). Les transformations organisationnelles ne suivent pas des lois universelles applicables à tous – et comme Robin et Garance l’ont répété, il est essentiel d’accepter la part d’incertitude et d’expérimentation. Essayez, observez, ajustez... mais ne vous attendez pas à des résultats garantis sur contrat.

3. L’humain se pilote mal : respectez la souffrance et la résistance.
   Dans chaque pivot, chaque restructuration, chaque changement, il n’y a pas que de la technique ou des process – il y a surtout des humains. Sous-estimer la “casse humaine” qui peut accompagner une transformation, c’est courir droit à la catastrophe. Les arrêts maladie, les résistances et la souffrance peuvent être le baromètre du changement – ne les considérez jamais comme de simples variables d’ajustement. Votre défi consiste à “embarquer” les gens autant que possible dans le projet, à donner du sens, à ouvrir le débat, à reconnaître et traiter les peurs.

4. Impliquer, oui ; tout déléguer, non.
   Même si l’idéal de l’équipe auto-organisée fait rêver, n’oubliez pas le rôle crucial de la coordination globale et d’un cadre explicite posé par le management. “Traiter les gens comme des adultes”, c’est leur faire confiance – mais aussi leur donner des règles du jeu claires, des objectifs et des limites. Comme Jean-Pierre et Robin en ont discuté, c’est en traçant le terrain et en clarifiant les rôles qu’on permet à chacun d’être acteur sans tomber dans l’anarchie ou l’ambiguïté paralysante.

5. N’oubliez jamais le pourquoi : créez le sentiment d’urgence avant d’agir.
   Changer pour changer n’a aucun sens. Vous devez d’abord répondre franchement à la question du “pourquoi” – pourquoi ce pivot, pourquoi cette transformation ? Est-ce une vraie “burning platform” ou juste une envie de réorganiser pour réorganiser ? Comme l’a rappelé Jean-Pierre, la première étape c’est bien de créer le sentiment d’urgence, de partager les enjeux et les limites actuelles, avant de se lancer dans l’action.

Voilà, cinq conseils sincères puisés dans la réalité et les discussions du live – sans prétendre posséder la formule miracle, mais en espérant que l’un ou l’autre saura faire écho à vos propres expériences. À vous d’expérimenter et d’ajuster, comme toute bonne équipe agile qui se respecte !

Derrière le désir de « bien faire » et de tout maîtriser se cachent souvent des craintes inavouées : peur de l’échec, de ne plus être légitime ou de perdre la main. Plutôt que de les ignorer, pourquoi ne pas les regarder en face ? C’est le pari d’un atelier innovant, inspiré des movings motivators, de Jean-Christophe Pagès. Le serious game baptisé Managers Fears : mettre les peurs managériales sur la table pour mieux les apprivoiser et libérer un leadership plus authentique.

Mais avant d’aller plus loin :

• Télécharge le deck ici.

• Télécharge le guide de facilitation là.

Les peurs invisibles qui freinent les managers

Chaque humain a ses fantômes intérieurs. L’atelier Managers Fears en a identifié dix, issues de situations courantes où le rôle du manager est remis en question. Parmi les plus répandues figurent notamment :

• la crainte de devenir inutile aux yeux de son équipe ;

• la peur que l’équipe parte dans tous les sens sans cadre ;

• la peur de ne plus être écouté ni respecté ;

• la crainte d’être tenu pour responsable en cas d’échec ;

• la peur de ne pas savoir manager autrement, etc.

En somme, ces peurs traduisent l’angoisse de perdre la maîtrise et de voir son rôle remis en cause. Ce sont souvent des freins invisibles qui expliquent la difficulté à déléguer et à faire confiance à son équipe. Tant qu’elles restent tabou, ces craintes continuent de saboter inconsciemment les initiatives du manager d’aider l’équipe à aller vers plus d’agilité… d’où l’importance de les reconnaître pour avancer.

Mettre des mots sur les craintes pour avancer

Parler ouvertement de ses peurs en milieu professionnel, surtout quand on est censé montrer l’exemple, n’a rien d’aisé. Pourtant, créer un espace de dialogue sans jugement autour de ces peurs peut se révéler libérateur. C’est exactement ce que propose l’atelier Managers Fears : un cadre bienveillant où les dirigeants peuvent exprimer, sans honte, ce qu’ils taisent d’ordinaire. L’objectif est double : d’une part diagnostiquer les inquiétudes qui entravent chaque manager (et à quel point), d’autre part amorcer un travail de développement de la posture managériale. En effet, simplement nommer ses peurs constitue déjà un premier pas vers une attitude de leadership plus ouverte et confiante.

Mettre des mots sur ces craintes secrètes aide à briser le non-dit. On sort les peurs de l’ombre, on les regarde en face et – pourquoi pas – on peut même en sourire une fois qu’elles sont étalées sur la table. Le simple fait de verbaliser, de formaliser ses doutes enlève déjà une part de leur pouvoir. Soudain, le manager réalise qu’il n’est pas seul à douter. Ce soulagement partagé est souvent le début d’une vraie prise de conscience collective. Chacun voit bien que ses collègues éprouvent, eux aussi, la peur de « perdre le contrôle »… et mettre des mots communs sur ces inquiétudes communes, c’est le début de la confiance.

La vulnérabilité : un catalyseur de confiance

Lorsqu’un leader ose abattre le masque et confier ce qui l’inquiète à l’équipe, c’est tout le groupe qui progresse. J’ai pu voir, au cours d’une session Managers Fears, un dirigeant avouer sa crainte de devenir inutile si son équipe fonctionnait sans lui. Sa voix tremblait en exprimant cela. En quelques secondes, l’atmosphère a totalement changé : on est passés d’un exercice un peu formel à une discussion profondément authentique entre êtres humains. Le courage de l’un a créé un appel d’air pour tous les autres, qui se sont sentis autorisés à parler vrai. Ce moment de vulnérabilité partagée a soudé l’équipe managériale bien plus qu’aucune réunion stratégique ne l’aurait fait.

Loin d’affaiblir l’autorité, cette vulnérabilité a agi comme un catalyseur de confiance. Chaque aveu a ouvert la porte à plus de compréhension mutuelle et de solidarité au sein du groupe. A l’heure de l’IA … on découvre qu’il est permis d’être humain, imparfait, et d’en discuter ensemble pour progresser. C’est ainsi que peu à peu, on passe d’une culture du contrôle à une culture de la confiance, un ingrédient indispensable de l’autogestion. En exposant ses doutes, le manager fait aussi preuve de transparence et de courage, deux qualités au cœur du leadership agile. Il amorce une transition du micro-management vers un accompagnement plus ouvert, où il fixe une vision et des limites claires plutôt que de tout surveiller au quotidien. Souvent, ces conversations franches débouchent sur des engagements concrets : par exemple, décider de laisser plus d’autonomie à l’équipe sur un prochain projet, même si elle emprunte une voie différente de celle du manager. Ces petites expérimentations, nées de la confiance, permettent de transformer la peur en action progressive vers davantage de lâcher-prise.

Cette démarche s’inscrit d’ailleurs parfaitement dans l’esprit du Management 3.0 qui promeut des outils pour aborder des sujets sérieux comme, par exemple, les Moving Motivators (pour explorer les sources de motivation) ou le Delegation Poker (pour clarifier le partage du pouvoir décisionnel) popularisés par Management 3.0. De même, l’atelier Managers Fears rappelle que la vulnérabilité peut être une force : en osant poser cartes sur table, ces managers ont commencé à apprivoiser leurs peurs au lieu de les subir. C’est un pas de plus vers un leadership agile, fondé sur la confiance, l’autonomie et l’humain.

En fin de compte, reconnaître ses propres limites ne diminue en rien un leader – bien au contraire : En acceptant d’être vulnérable, un manager ouvre la voie à un leadership plus authentique, résilient et partagé avec son équipe. Alors, êtes-vous prêt, vous aussi, à transformer vos peurs en moteur de confiance et de croissance pour votre équipe ?

Laissez un commentaire.

Au fait ! Nous ouvrons une nouvelle session de notre Formation Management 3.0 ! La prochaine session (officielle et certifiante) aura lieu les 2 et 3 mars 2026 en ligne (tarif 399 €, places limitées à 12 participants). Durant ces deux jours, vous découvrirez les principes du Management 3.0 et repartirez avec des outils concrets pour encourager la collaboration, motiver vos équipes et créer une culture d’amélioration continue et d’innovation au sein de votre organisation. N’attendez plus : inscrivez-vous dès maintenant pour transformer votre management et libérer le potentiel de vos équipes !

On découvrira les movings motivators mais aussi delegation poker, meddlers game, manager fears et beaucoup d’autres ateliers !

Qu’est-ce que la Developer Experience (DX) ?

La Developer Experience (DX) – ou Expérience Développeur – désigne la manière dont les développeurs vivent leur travail au quotidien, englobant tout ce qui impacte leur activité : l’environnement de travail, les outils, la culture d’entreprise, les collègues, les processus, ... en somme, c’est l’équivalent de l’expérience utilisateur (UX)… appliquée cette fois aux “créateurs” du code. Une DX de qualité se reflète par des développeurs motivés, efficaces et peu frustrés par des obstacles inutiles. À l’inverse, une mauvaise DX se traduit souvent par de la confusion, des pertes de temps, du stress et in fine une baisse de qualité et de valeur livrée.

Il est important de noter que l’expérience développeur ne se limite pas aux outils mis à disposition. C’est un ensemble holistique comprenant diverses choses en partant de la clarté des objectifs fixés en allant jusqu’à la simplicité des workflows, la culture de collaboration ou encore la qualité de la documentation interne.

Être développeur, c’est un peu comme être chirurgien. Avant même d’entrer dans le bloc opératoire, tout doit être prêt : les bons outils stérilisés à portée de main, les écrans bien configurés, l’équipe parfaitement coordonnée. Si le chirurgien devait perdre du temps à chercher un scalpel ou à configurer son moniteur en pleine opération, ce serait non seulement inefficace, mais aussi risqué. La Developer Experience, c’est justement ça : s’assurer que les développeurs ont tout ce qu’il leur faut — outils, environnement, information — au bon moment, pour pouvoir se concentrer pleinement sur leur mission principale : créer un produit robuste, utile, et maintenable.

Pourquoi s’intéresser à l’expérience développeur ?

Bien qu’étant un concept relativement ancien (on trouve des articles de 2012 mentionnant déjà ce concept) on évoque encore trop peu la DX... même si elle est devenue (sans porter ce nom) un enjeu stratégique pour les entreprises technologiques modernes.

Nous en parlions déjà dans nos vidéos sur DORA, SPACE ou encore Accelerate : Des recherches menées par GitHub ont montré qu’une meilleure DX entraîne une hausse de la valeur livrée par les équipes de développeurs. Dans un sondage effectué mi 2025 dans la DORA community (bon pas tout à fait le reflet de ce qu’il se passe en France mais prenons), 89 % des managers interrogés ont lancé des initiatives pour améliorer la vie de leurs développeurs. En clair, un développeur qui vit une bonne expérience au travail ... travail mieux, plus vite, avec moins d’erreurs, et contribue à livrer de la valeur plus fréquemment.

Pourquoi un tel impact ? Parce que le travail de développement logiciel est avant tout un travail cognitif et collaboratif. Un environnement qui minimise les frustrations et les distractions permet d’être plus efficace... ça coule de source.

À l’inverse, une DX médiocre dilapide le temps et l’énergie : par exemple, des études montrent que la multiplication des outils et des tâches “hors-code” grignote des heures chaque semaine. Une enquête Port, Inc. a révélé que 75 % des développeurs perdent entre 6 et 15 heures par semaine en raison des frictions et du contexte-switching liés à une profusion d’outils hétérogènes. Jusqu’à 2 jours par semaine donc... presque 50%... c’est autant de temps non passé à développer de nouvelles fonctionnalités ou à améliorer la qualité du produit. Sur une année, ces pertes de productivité se chiffrent en semaines de travail gaspillées, sans parler du risque de burn-out lorsque les développeurs sont constamment interrompus ou bloqués par des problèmes d’environnement.

En somme, s’intéresser à la DX n’est pas un caprice de développeur gâté : c’est devenu un impératif pour toute organisation qui souhaite innover rapidement tout en préservant la qualité logicielle et la satisfaction des équipes. C’est ici qu’entre en scène le Platform Engineering, une approche qui vise justement à améliorer structurellement l’expérience développeur.

Platform Engineering : une réponse aux défis modernes

Allez, il faut bien que je le dise quelque part, autant que ça soit ici, on va évoquer le plateform engineering dans nos formations sur UnFix (la prochaine session est complète mais nous allons en ouvrir d’autres !).

Reprenons.

Comment atténuer la complexité et les frictions que subissent les équipes de développement ? Au fil des années, de nombreuses entreprises ont convergé vers une solution : créer une plateforme interne pensée pour et par les développeurs. C’est tout l’enjeu du Platform Engineering. Cette discipline consiste à concevoir et construire les chaînes d’outils et les workflows qui permettent aux développeurs de bénéficier de capacités en self-service, le tout dans l’ère du cloud. Dit autrement, les équipes de platform engineering fournissent un produit intégré – souvent appelé Internal Developer Platform (IDP) – regroupant l’ensemble des outils et services nécessaires au cycle de vie d’une application, de façon cohérente et automatisée.

L’objectif principal ? Réduire la charge cognitive des développeurs face à une stack technique toujours plus complexe : Plutôt que de laisser chaque équipe réinventer la roue pour mettre en place son CI/CD, son monitoring, son hosting, etc., la plateforme interne offre ces capacités prêtes à l’emploi, via des interfaces simples (portail, CLI, APIs). Idéalement, toutes les tâches récurrentes et transverses deviennent ainsi des services self-service : créer un nouveau dépôt de code, provisionner un environnement de test, déployer une application, consulter les métriques de performance… tout cela doit être faisable rapidement, de manière standard et sécurisée, sans avoir à naviguer dans dix outils différents ni remplir un énième ticket Jira.

En pratique, le Platform Engineering fournit aux développeurs des « Golden Paths » (voies dorées) ou « paved roads » (routes goudronnées) sur lesquelles avancer. Un Golden Path est un parcours de développement optimisé et officiellement supporté pour accomplir une tâche courante – par exemple créer un nouveau microservice ou déployer une application en production. Ce parcours vient avec toutes les bonnes pratiques intégrées (sécurité, observabilité, conformité) de sorte que si l’équipe l’emprunte, elle avance vite en toute confiance, sans avoir à faire des choix techniques à chaque étape. Bien sûr, les développeurs gardent la liberté de sortir de la voie tracée (pour expérimenter de nouvelles technologies par exemple), mais s’ils suivent le chemin “pavé” par la plateforme, ils bénéficient d’un environnement clé en main où beaucoup de pièges sont évités d’emblée.

Au-delà de l’aspect technologique, le platform engineering apporte aussi un changement culturel majeur : il pousse l’organisation à considérer ses développeurs comme des clients internes et la plateforme comme un produit à part entière. L’équipe plateforme adopte une posture de product team vis-à-vis des devs : réalisation d’études utilisateurs (quels sont les pain points des développeurs ?), définition d’une roadmap produit pour y répondre, mesure de l’adoption et de la satisfaction, amélioration continue… On n’est plus dans une logique de simples “support IT” ou d’équipe outillage isolée : la plateforme est gérée comme un produit dont la réussite se mesure à l’aune de l’expérience de ses utilisateurs développeurs. Cette philosophie est cruciale pour réellement améliorer la DX : il ne suffit pas d’empiler des outils, il faut une approche cohérente et centrée sur l’utilisateur-développeur.

Notons que ce mouvement du platform engineering prend de l’ampleur. Le cabinet Gartner prévoit qu’en 2026, 80 % des grandes organisations logicielles auront mis en place des équipes dédiées au platform engineering. Cela témoigne d’une prise de conscience générale : les géants du Web comme les entreprises plus traditionnelles investissent pour rationaliser et améliorer l’environnement de développement, conscients que c’est un facteur déterminant de succès.

Comment améliorer la Developer Experience dans votre organisation ?

Chaque entreprise a ses spécificités, mais quelques axes d’action généraux se dégagent pour booster l’expérience de vos développeurs (Nicole Forsgren en parle d’ailleurs assez bien dans une interview que je relayerai en commentaire) :

• Mesurer et écouter régulièrement : On ne peut améliorer que ce qu’on mesure. Mettez en place des indicateurs de DX (par ex. temps de build, durée d’onboarding, fréquence des déploiements, satisfaction des devs via des surveys internes…) et suivez-les dans le temps. Interrogez les développeurs sur ce qui les freine le plus (via des sondages anonymes, des rétrospectives DevEx). Ces feedbacks permettront d’identifier les points douloureux à adresser.

• Désigner un “champion” de la DevEx : Idéalement, nommez ou recrutez une personne (ou une petite équipe) dédiée à l’expérience développeur. Ce Developer Experience Engineer aura pour rôle de centraliser les retours, proposer des améliorations, et évangéliser en interne sur les bonnes pratiques. C’est l’équivalent d’un Product Manager, mais dont les “clients” sont les développeurs interne. Dans les plus petites structures, cette casquette peut être portée par un Tech Lead ou un DevOps expérimenté ayant le goût du mentoring.

• Réduire le tool sprawl : Faites le tri dans la galaxie d’outils utilisée en interne. Trop d’outils tue l’outil. S’il y a 5 solutions de CI/CD, 4 frameworks frontend et 3 systèmes de tickets en parallèle, essayez de converger vers moins d’options supportées. Standardisez ce qui peut l’être (sans brider complètement la liberté, bien sûr). L’objectif n’est pas de tout imposer, mais d’offrir une voie par défaut simple et efficace (le “paved road”), afin que la majorité des équipes n’aient pas à se poser sans cesse les mêmes questions d’intégration. Moins de fragmentation = moins de complexité cognitive.

• Automatiser et outiller intelligemment : Identifiez les tâches répétitives ou chronophages qui pourraient être automatisées ou rendues self-service. Par exemple, la mise à disposition d’environnements de développement homogènes (via des conteneurs Docker préconfigurés, ou des environnements sur le cloud), la création de templates de projet, l’intégration d’une CI/CD clef en main… Investir du temps de dev maintenant pour éliminer du toil plus tard est un calcul gagnant. De même, documentez clairement les workflows communs et assurez-vous que la documentation est facile à trouver à un seul endroit central.

• Traiter l’environnement dev comme un produit : Inspirez-vous de l’approche Platform Engineering en considérant vos outils internes non pas comme de simples ressources IT, mais comme un produit dont les développeurs sont les utilisateurs. Cela implique d’itérer en fonction de leurs retours, d’améliorer l’UX des outils internes (parfois, un petit script ou une interface simplifiée peut résoudre un irritant quotidien), et de faire de la veille sur les nouveaux outils ou pratiques qui pourraient bénéficier à vos équipes.

Conclusion : l’expérience développeur, un investissement d’avenir

Longtemps reléguée au second plan derrière l’expérience utilisateur finale, l’expérience développeur émerge aujourd’hui comme un facteur clé de succès des entreprises logicielles. Comme le disait déjà Accelerate, Un développeur heureux et efficace, c’est un produit mieux construit, livré plus vite, avec moins d’erreurs et plus de valeur – et au bout du compte, ce sont vos clients finaux qui en ressentent les bénéfices. Des pionniers comme Netflix ou Spotify l’ont compris en bâtissant des plateformes internes robustes et en cultivant une culture du feedback développeur. Le mouvement s’accélère dans l’industrie, porté par la complexité croissante des stacks techniques et la pénurie de talents (il est vital de fidéliser vos meilleurs ingénieurs en leur offrant un environnement de travail optimal).

En améliorant la Developer Experience, on enclenche un cercle vertueux : les équipes dev sont moins freinées, donc plus productives et créatives, ce qui permet d’innover davantage et plus rapidement, ce qui contribue à la réussite de l’entreprise – et un développeur qui voit son impact concret est d’autant plus motivé à continuer dans cette voie. Au final, s’occuper de l’expérience de vos développeurs n’est pas qu’une question de bien-être au travail : c’est un choix stratégique pour rester performant et compétitif. Il ne s’agit pas de céder à un énième mot à la mode, mais de reconnaître que derrière chaque logiciel innovant se trouvent des humains – et que prendre soin de l’expérience de ces humains, c’est multiplier les chances de succès de vos projets et/ou produits.

Pendant des années, managers et équipes ont cherché le bon indicateur, souvent en vain. Faut-il compter les lignes de code, le nombre de commits, la vélocité ?

En réalité, aucune mesure unique ne peut résumer la performance d’une équipe de développement. Le framework SPACE a été conçu précisément pour résoudre ce dilemme. Issu de travaux récents, SPACE propose une approche multidimensionnelle qui prend en compte à la fois les résultats, l’activité, la collaboration, l’efficacité et, surtout, le facteur humain. SPACE offre ainsi une vision plus complète et plus juste de la performance des équipes de développement qu’une simple métrique unidimensionnelle.

Cerise sur le gâteau (en tout cas pour moi), à l’origine de SPACE il y a aussi Nicole Forsgren, co-autrice d’Accelerate dont j’ai tant pu parler sur Scrum Life.

Origine du framework SPACE

Le framework SPACE a vu le jour en 2021 sous l’impulsion d’un groupe de chercheurs de GitHub, Microsoft Research et l’Université de Victoria, parmi lesquels, comme je viens de le mentionner, Nicole Forsgren et la professeure Margaret-Anne Storey.

Ce collectif de chercheurs s’est penché sur LA question que j’ai personnellement croisée tout au long de ma carrière : la difficulté persistante à définir et mesurer la “productivité” et l’efficacité (on parlera d’impact et de valeur plus tard) des développeurs malgré des décennies de recherches et d’essais pratiques.

Dans “The SPACE of Developer Productivity”, papier originel de SPACE, les auteurs partent d’un constat simple mais souvent oublié : la productivité des développeurs est un concept complexe, multidimensionnel, et profondément contextuel. Chercher à la résumer avec un seul indicateur conduit presque toujours à des effets pervers.

SPACE ne propose donc pas une nouvelle “métrique miracle”, mais un cadre de réflexion pour observer la performance des équipes sous plusieurs angles complémentaires, en assumant les tensions naturelles entre vitesse, qualité, collaboration et bien-être.

C’est dans ce contexte que SPACE a été conçu, avec l’ambition de combiner plusieurs dimensions en tension afin de mieux comprendre ce qui rend les développeurs et les équipes productifs.

Objectifs et problèmes adressés par SPACE

L’objectif premier de SPACE est de permettre une évaluation plus équilibrée de la performance des équipes de développement. Plutôt que de se focaliser sur un indicateur unique (qui risque de donner une vision biaisée), SPACE invite à considérer plusieurs axes complémentaires. Ce framework cherche ainsi à résoudre plusieurs problèmes classiques dans l’évaluation de la productivité logicielle :

• Éviter la myopie des métriques uniques : Un des constats à l’origine de SPACE est qu’aucune métrique isolée ne peut refléter toute la complexité du travail des développeurs. Par exemple, mesurer uniquement l’activité (commits, tâches terminées, etc.) ne dit rien de la qualité du code ni de la satisfaction de l’équipe. De même, se concentrer uniquement sur la performance individuelle peut nuire à la dynamique de groupe. SPACE répond à cela en combinant plusieurs dimensions, évitant de tout réduire à un seul chiffre.

• Réhabiliter le facteur humain : Bien souvent, les mesures de productivité traditionnelles ignoraient le ressenti des développeurs, leur satisfaction ou les aspects culturels. SPACE intègre explicitement le bien-être et la collaboration dans la mesure de la performance. L’idée est de valoriser ce qui est souvent invisible dans les chiffres bruts (comme le mentorat, le partage de connaissances ou la cohésion de l’équipe) mais qui est crucial pour la réussite sur le long terme. En ce sens, SPACE souligne que les indicateurs ne sont pas réservés aux managers : ils doivent aussi servir aux développeurs eux-mêmes, pour améliorer leurs flux de travail et éviter l’épuisement professionnel.

• Encourager les bonnes pratiques : En privilégiant une approche multi-indicateurs, SPACE démystifie plusieurs conceptions erronées. Par exemple, il rappelle que plus d’activité n’est pas synonyme de plus de valeur produite, ou que la productivité ne se résume pas à des outils et processus techniques. En mesurant également la satisfaction et la collaboration, on incite les organisations à créer un environnement propice au bien-être, ce qui en retour influence positivement la productivité. L’usage du framework vise donc à équilibrer les priorités : livrer du logiciel efficacement, tout en maintenant des équipes heureuses, en bonne santé et engagées sur la durée.

En somme, le framework SPACE sert à mieux comprendre ce qui fait qu’une équipe de développement est performante. Ses concepteurs le résument comme un moyen de « penser rationnellement la productivité dans un espace beaucoup plus grand », afin de prendre de meilleures décisions pour les projets comme pour les individus.

Les cinq dimensions du framework SPACE

Le nom SPACE est un acronyme formé des cinq dimensions clés que le framework propose d’observer en parallèle :

Satisfaction & bien-être – Correspond à l’épanouissement professionnel des développeurs : à quel point ils se sentent satisfaits de leur travail, de l’équipe, des outils, et comment ils se portent sur le plan du stress et de la santé mentale. C’est la dimension humaine du cadre. L’idée est que des développeurs heureux et en bonne santé seront plus créatifs, plus motivés et donc plus productifs sur la durée. Exemple : on peut évaluer cette dimension via des sondages de satisfaction, des enquêtes de climat d’équipe, ou en surveillant les signes de burnout.

Performance – Il s’agit des résultats obtenus par l’équipe, plutôt que du simple effort fourni. Concrètement, la performance répond à la question : le travail accompli apporte-t-il de la valeur ? Il ne s’agit pas de produire beaucoup de code, mais du code de qualité qui fonctionne et satisfait les utilisateurs. La performance se mesure donc en termes d’impact (satisfaction client, adoption d’une fonctionnalité, valeur métier générée) et de qualité (fiabilité du logiciel, absence de bugs) plutôt qu’en quantité brute. Exemple : on peut suivre des indicateurs tels que le taux de défauts en production, la satisfaction utilisateur, ou des métriques DevOps de qualité (taux de réussite des déploiements, etc.).

Activité – Cette dimension reflète le volume d’actions accomplies par les développeurs pendant leur travail. Cela inclut des données comme le nombre de commits, le nombre de pull requests créées ou revues, le nombre de tâches terminées, etc. L’activité est la mesure la plus instinctive (et historiquement la plus utilisée) de la “productivité” car elle est facile à quantifier. Cependant, SPACE insiste sur le fait que l’activité brute n’est qu’une vue partielle : une activité élevée peut tout aussi bien refléter un travail efficace que du bruteforce dû à des obstacles ou une mauvaise planification. Il faut donc toujours l’interpréter aux côtés des autres dimensions. Exemple : des métriques d’activité typiques sont le nombre de commits par jour, le volume de code produit, le nombre de déploiements effectués sur une période donnée, etc.

Communication & collaboration – Cette dimension couvre la façon dont les individus et les équipes travaillent ensemble. Le développement logiciel est un effort collectif, nécessitant coordination, échanges d’information et feedbacks permanents. Une équipe qui communique bien et où la collaboration est fluide aura moins de doublons, moins d’erreurs de compréhension et intègrera plus rapidement le travail de chacun. À l’inverse, de mauvais canaux de communication peuvent provoquer retards et frustrations. Exemple : on peut regarder la qualité des revues de code (est-ce que les revues sont constructives ?), le taux de participation aux discussions techniques, le temps nécessaire pour onboarder un nouveau membre dans l’équipe, ou même cartographier les réseaux de collaboration (qui travaille avec qui) au sein du projet.

Efficacité & flux – La dernière dimension évalue la capacité de l’équipe à avancer sans friction. Il s’agit de mesurer à quel point le travail progresse avec un minimum d’interruptions, de délais ou de gâchis d’efforts. On parle parfois de flow : cet état de concentration maximale où le développeur est pleinement productif sur une tâche, ou de flux de valeur dans le pipeline de delivery (parcours des tâches depuis l’idée jusqu’en production). Un bon score en efficacité/flux signifie que les processus sont bien huilés, avec peu de goulets d’étranglement, et que les développeurs peuvent régulièrement se mettre en flux sur des tâches complexes. Exemple : des indicateurs concrets incluent le temps de cycle (temps moyen pour qu’une fonctionnalité ou un changement de code aille du développement à la production), le nombre d’interruptions ou de changements de priorité subis en cours de travail, le nombre de passages de relais entre équipes (qui peut ralentir la livraison), etc. Une organisation très efficiente cherchera par exemple à réduire le temps d’attente à chaque étape du processus de développement et déploiement..

Ces cinq dimensions forment ensemble la « constellation » SPACE. L’idée forte est qu’il faut jongler entre elles : améliorer une dimension ne doit pas se faire au détriment total d’une autre. Par exemple, maximiser la vitesse de livraison (efficacité) ne sert à rien si la qualité s’effondre derrière (performance), ou si les développeurs se démoralisent en cours de route (satisfaction). SPACE permet justement de visualiser ces arbitrages et de chercher un équilibre adapté à chaque contexte.

Application concrète du framework SPACE

Comment une organisation agile peut-elle utiliser SPACE au quotidien ? La mise en œuvre du framework se fait en plusieurs étapes : définir des métriques pertinentes pour chaque dimension, collecter ces données, puis ajuster les pratiques en conséquence. Voici quelques recommandations et exemples d’indicateurs typiques pour chaque dimension :

• Choisir plusieurs métriques, sur plusieurs axes : Il est conseillé de combiner au moins trois indicateurs couvrant des dimensions différentes de SPACE pour éviter une vision biaisée. Par exemple, une équipe pourrait suivre en parallèle le moral de l’équipe (Satisfaction), le taux d’échec des déploiements (Performance) et le temps de cycle (Efficacité). L’essentiel est de ne pas se focaliser sur un seul chiffre, mais de croiser les enseignements. En pratique, on observe souvent qu’un indicateur seul peut être trompeur : une hausse du nombre de commits (activité) pourrait sembler positive, mais si parallèlement la satisfaction plonge et que les bugs augmentent, on comprend qu’il y a un problème de fond. SPACE invite donc à suivre un panel équilibré de métriques pour avoir le contexte global.

• Intégrer les métriques dans la vie de l’équipe : Une fois les indicateurs définis, il est important de les suivre régulièrement et d’en faire un outil de pilotage agile. Par exemple, les résultats SPACE peuvent être discutés lors des rétrospectives de sprint, des réunions d’équipe ou des one-on-one hebdomadaires. L’organisation doit créer un climat de confiance autour de ces mesures : l’objectif n’est pas de fliquer individuellement les développeurs, mais de détecter des axes d’amélioration collectifs. Si un indicateur se dégrade (par ex. une baisse de satisfaction dans l’équipe), cela devient un sujet d’action à part entière pour le Scrum Master, le Product Owner ou le manager, au même titre qu’un impediment technique. En agile, on peut ainsi intégrer les métriques SPACE au processus d’inspection et d’adaptation continue de l’équipe.

• Utiliser des indicateurs adaptés à son contexte : SPACE ne fournit pas une liste figée de KPI universels – chaque organisation doit choisir les métriques précises qui ont du sens pour elle. Cela peut dépendre de la culture, des outils en place, du type de produit développé, etc. Par exemple, dans une équipe DevOps, on utilisera naturellement les quatre métriques DORA (voir section suivante) comme indicateurs de Performance/Efficacité. Une équipe applicative grand public pourra ajouter un indicateur d’engagement utilisateur (p. ex. taux d’utilisation active d’une fonctionnalité) pour la dimension Performance. L’important est de couvrir les cinq dimensions autant que possible, avec des métriques actionnables (sur lesquelles l’équipe peut agir). Souvent, on conseille de sélectionner 1 à 3 métriques par dimension jugée critique, plutôt que de tout mesurer en vrac.

Exemples d’indicateurs par dimension : Pour illustrer concrètement, voici quelques métriques souvent utilisées dans chaque catégorie SPACE :

• Satisfaction & bien-être : résultats de sondages de satisfaction interne (score de bonheur de l’équipe), eNPS (Employee Net Promoter Score, recommandation de l’entreprise par les employés), taux d’utilisation des congés (pour s’assurer que l’équipe prend du repos), taux de rétention des développeurs, etc.

• Performance : qualité du code (densité de bugs, incidents en production, couverture de tests), impact client (feedback utilisateurs, taux de churn ou de rétention client, nombre de tickets support), respect des engagements (fonctionnalités livrées dans les délais, objectifs produit atteints).

• Activité : fréquence des commits (commits par jour/sprint), nombre de pull requests créées et mergées, vélocité Agile (points terminés par itération), taux de participation aux revues de code, répartition du temps entre dev et tâches transverses, etc.

• Communication & collaboration : nombre de réunions et temps passé en réunion, taux de participation aux outils collaboratifs (ex : messages sur Slack, commentaires dans les tickets), temps d’intégration du code (combien de temps une pull request reste ouverte avant d’être intégrée – reflet de la coordination), feedback 360° sur la cohésion d’équipe, durée d’onboarding des nouveaux développeurs.

• Efficacité & flux : temps de cycle complet (du premier commit au déploiement en prod), fréquence de déploiement (combien de releases par jour/semaine), MTTR – Mean Time to Restore (temps de rétablissement du service après un incident), nombre d’interruptions subies (par ex. support, changements de priorités en cours de sprint), nombre de handoffs entre équipes sur une même initiative, etc.

En appliquant ces métriques, une organisation agile peut visualiser ses points forts et faibles sous différents angles. Par exemple, si l’activité est élevée mais que l’efficacité est faible (beaucoup de travail en cours mais des délais longs pour livrer), le framework pointera vers un problème potentiel dans le processus (goulots d’étranglement, blocages techniques…). De même, si la performance technique est bonne mais que la satisfaction des développeurs est en baisse, l’entreprise saura qu’elle doit agir sur la charge de travail ou la culture d’équipe pour éviter le burn-out. L’approche SPACE s’inscrit ainsi parfaitement dans une démarche d’amélioration continue : on mesure régulièrement, on détecte les goulots d’étranglement ou les risques (motivation, fatigue) et on ajuste avant que cela n’affecte lourdement le produit ou l’équipe.

Combinaison avec d’autres frameworks (DORA, OKR…)

Il existe évidemment d’autres frameworks et outils pour évaluer la performance en développement logiciel. Comment SPACE se situe-t-il par rapport à ceux-ci ? Intéressons-nous à deux références populaires et à la manière dont elles peuvent se compléter avec SPACE.

DORA : focus sur la performance DevOps

Le framework DORA (pour DevOps Research & Assessment) dont j’ai beaucoup parlé (Tu peux voir toutes nos vidéos sur Scrum Life) est très répandu dans les équipes qui adoptent DevOps. Il se concentre sur quatre métriques clés liées aux performances de livraison logicielle : le délai de changement (lead time for changes), la fréquence de déploiement, le temps de rétablissement en cas d’incident (MTTR) et le taux d’échec des changements. Ces indicateurs DORA mesurent principalement la vitesse et la stabilité du pipeline de déploiement. Par rapport à SPACE, on voit que DORA ne couvre qu’une partie des dimensions (principalement l’Efficacité/Flux et un aspect de Performance technique). DORA n’intègre pas directement des notions comme la satisfaction des développeurs ou la collaboration d’équipe. Cependant, loin d’être en concurrence, les deux approches sont jugées complémentaires. En pratique, beaucoup d’organisations commencent par suivre les métriques DORA pour améliorer leur pipeline, puis élargissent ensuite le périmètre avec SPACE afin d’avoir une vue plus holistique sur l’efficacité et la santé de leurs équipes. Utilisés conjointement, DORA et SPACE fournissent un véritable balanced scorecard (tableau de bord équilibré) : on s’assure de ne pas optimiser la vitesse de livraison au détriment de la qualité du code ou du bien-être de l’équipe, et vice-versa.

OKR : aligner les métriques sur les objectifs

Un résumé très rapide : Les OKR (Objectives and Key Results) forment un cadre de gestion des objectifs, largement employé pour aligner les efforts d’une équipe sur la stratégie d’entreprise. OKR n’est pas un système de métriques en soi, mais plutôt une manière de fixer des objectifs et de mesurer les résultats clés qui y sont associés. Dans ce sens, OKR et SPACE peuvent aussi se compléter. En effet, on peut très bien définir des OKR liés à l’amélioration de certaines dimensions SPACE. Par exemple, un objectif trimestriel pourrait être « Améliorer la satisfaction de l’équipe », avec comme résultats clés d’atteindre un score de satisfaction interne de X/10 et de réduire le taux de rotation du personnel de Y% (liés à la dimension Satisfaction). De même, un OKR « Améliorer la qualité de livraison » pourrait utiliser des KPI DORA/SPACE comme réduire le taux d’échecs de déploiement en dessous de Z% (Performance) et le délai moyen de livraison à N jours (Efficacité). L’idée est que les OKR donnent le cadre d’objectifs, et des frameworks comme SPACE fournissent les mesures concrètes pour suivre ces objectifs. En combinant les deux, une entreprise agile s’assure que ses objectifs stratégiques incluent des composantes techniques et humaines, et que les améliorations de productivité recherchées sont bien alignées avec la création de valeur et la santé de l’organisation.

En conclusion

En définitive, le framework SPACE apporte aux leaders agiles et aux équipes de développement un outil précieux pour naviguer dans la complexité de la productivité logicielle. En embrassant à la fois la satisfaction des développeurs, la performance produit, l’activité réalisée, la collaboration d’équipe et l’efficacité des processus, SPACE offre une vision équilibrée et multidimensionnelle de la performance. Ce faisant, il aide à repérer plus facilement les points de friction (techniques ou humains), à préserver le moral de l’équipe, et à optimiser en continu les façons de travailler. Plutôt que de piloter « à l’aveugle » ou avec un seul indicateur, les organisations peuvent grâce à SPACE ajuster leurs actions avec finesse – par exemple en allouant du temps pour améliorer l’expérience développeur autant que pour accélérer le pipeline. En complément d’autres cadres comme DORA ou OKR, SPACE contribue à bâtir des équipes plus efficaces, heureuses et résilientes. Et comme on le dit souvent en agile : « On obtient ce que l’on mesure ». En mesurant ce qui compte vraiment sous plusieurs angles, le framework SPACE aide à obtenir ce qu’il y a de meilleur d’une équipe de développement – à la fois en termes de résultats et de bien-être collectif.

Pour aller plus loin : ressources de référence sur le SPACE framework

Le framework SPACE s’appuie sur des travaux de recherche solides, mais il a surtout été largement vulgarisé et enrichi par des praticiens du monde Dev, DevOps et Engineering Management. Voici une sélection de ressources de référence pour approfondir le sujet, selon que tu préfères lire, écouter ou regarder.

Articles de vulgarisation et d’application

• LinearB – SPACE Framework Explained
  https://linearb.io/blog/space-framework
  Un très bon article pour comprendre comment SPACE est utilisé aujourd’hui dans les organisations produit et comment il se combine naturellement avec DORA.

• Jellyfish – Understanding the SPACE Framework
  https://jellyfish.co/library/space-framework/
  Clair, structuré, orienté leadership et pilotage d’équipes tech.

• Swarmia – A Practical Guide to the SPACE Framework
  https://www.swarmia.com/blog/space-framework/
  Intéressant pour la vision organisationnelle et les pièges à éviter (sur-mesure des métriques, effets pervers).

• GetDX – SPACE Framework Primer
  https://getdx.com/blog/space-framework-primer/
  Bon complément avec une approche “Developer Experience”.

Ce bestiaire moderne met en lumière 10 anti-patterns comportementaux fréquents dans la prise de décision, et propose pour chacun une piste d’amélioration, inspirée (ou non) de nos expériences “data-driven”.

1. HiPPO – Highest Paid Person’s Opinion

Le boss parle, les autres se taisent.

Quand la personne la mieux payée ou la plus haut placée impose son opinion en réunion, tout le monde acquiesce. Même si les données racontent une autre histoire. Le pouvoir hiérarchique écrase la nuance.

Comment l’embarquer ? Présentez les alternatives avec des données factuelles (tests utilisateurs, résultats d’A/B test, étude marché) avant qu’il donne son avis. Préemptez l’espace.

2. CAMEL – Changes Approach Monthly, Everyone Lost

Une nouvelle méthode chaque mois, un nouveau chaos chaque semaine.

Ce manager est fasciné par les nouveautés : un jour c’est l’OKR, le lendemain SAFe, puis NoCode, puis DevOps, puis Holacracy. Résultat ? L’équipe s’épuise, rien n’est stabilisé, les priorités changent en boucle.

Comment l’embarquer ? Créez un backlog d’innovations. Cette approche comporte de très nombreux défauts mais pour le CAMEL cela peut aider. Cadrer, prioriser, avec un évènement mensuel pour décider quoi tester, quand et pourquoi. Montrez-lui qu’innover sans structuration, c’est dilapider son capital d’équipe.

3. La MULE – Manager Unwilling to Listen to Evidence

“Je sais ce que je fais.” Même quand tout indique l’inverse.

Têtu, ce profil reste sur ses positions, même face à des faits contraires. Il rejette toute remise en question, par fierté, par fatigue ou par inertie.

Comment l’embarquer ? Proposez une expérimentation encadrée : “Juste 2 semaines, pour voir.” Le convaincre passera plus par l’expérience vécue que par les chiffres.

4. SHEEP – Scared Human Emulating Every Peer

Tout le monde le fait, alors on doit le faire aussi.

Il suit la tendance, jamais en avance, rarement en recul. La peur de déplaire, de se tromper, ou de sortir du cadre l’empêche de challenger le statu quo.

Comment l’embarquer ? Valorisez la pensée divergente. Faites un atelier “Et si on faisait l’inverse ?”. Appuyez-vous sur des exemples d’entreprises inspirantes qui ont osé une autre voie. Cela crée un effet miroir rassurant.

Expliquez pourquoi être suiveur vous empêchera par définition d’être Leader.

5. RABBIT – Reluctant Analyst Blocked By Information Tension

Trop d’infos tue l’info… et l’action.

Ce profil attend la donnée parfaite pour agir. Il veut tout valider, tout vérifier, jusqu’à ce que la fenêtre d’action soit refermée.

Comment l’embarquer ? Encouragez une logique MVP + boucle de feedback rapide : “Lançons une première version, apprenons vite, ajustons.” Le rassurer passe par la progression incrémentale.

6. Le PEACOCK – Proud Executive Avoiding Counter Opinion or Knowledge

Brillant, mais sourd.

Ce décideur aime briller. Il est fier, souvent compétent, mais n’écoute pas les alertes, ni les signaux faibles. Il survalorise son intuition.

Comment l’embarquer ? Flattez l’ego… intelligemment : “Ce serait encore plus impressionnant si on validait ça avec une analyse terrain.” Et introduisez la contradiction via une voix externe (coach, benchmark, client VIP).

7. CHICKEN – Cautious Human Ignoring Change, Keeping Everything Normal

Trop prudent pour oser.

Le changement lui fait peur. Il préfère l’échec lent au risque rapide. Il joue la sécurité, même quand l’immobilisme devient dangereux.

Comment l’embarquer ? Proposez une expérimentation sécurisée : “On teste sur 5% du périmètre.” Mettez en balance le coût du risque… et le coût de l’inaction.

8. MAGPIE – Manager Attracted to Gadgets, Projects, Ideas Endlessly

Tout ce qui brille attire son attention.

Il saute d’une idée à l’autre, jamais rassasié. Il a 12 projets lancés, mais aucun de terminé. Son énergie est précieuse… mais dispersée.

Comment l’embarquer ? Cadrez une priorisation objective avec impact business et effort estimé. Offrez-lui un espace “bac à sable” pour canaliser les idées sans polluer l’exécution.

9. WOLF – Works Only Like a Free-agent

Solitaire, il décide sans consulter.

Il pense gagner du temps en décidant seul. En réalité, il isole, il fragilise, et perd la force du collectif.

Comment l’embarquer ? Montrez-lui que la co-construction génère de l’adhésion. Organisez des mini-ateliers de co-décision où il reste maître du choix final, mais enrichi par le groupe.

10. OSTRICH – Overlooking Situations That Require Immediate Courageous Handling

Il évite le sujet… en espérant qu’il disparaisse.

L’autruche enfouie la tête quand les problèmes arrivent. Le conflit ? Tabou. La décision difficile ? Reportée. Le désalignement ? Ignoré.

Comment l’embarquer ? Créez un cadre où dire les choses n’est pas dangereux. Utilisez des astuces comme le ROTI, le feedback canvas ou les rétrospectives pour normaliser les conversations courageuses. Mettez en place un cadre d’expression pour favoriser la sécurité psychologique.

bonus

11. BULL – Boss Using Loud Leadership Trop énergique pour écouter.

Il fonce sans écouter ni regarder.

Il impose sa volonté par la voix, l’urgence, le rythme. Il coupe la parole, tranche vite, et laisse peu de place à la réflexion collective. Sous couvert d’efficacité, il écrase les idées et court-circuite la co-construction.

Comment l’embarquer ?

• Cadrez le rythme : introduisez des temps de respiration dans la décision (“On fait un tour de table, puis on tranche”).

• Offrez-lui un rôle de clôture, pas d’ouverture : il parle en dernier, après avoir entendu les autres.

• Mettez en lumière les décisions ratées par précipitation, avec bienveillance. Montrez que ralentir, parfois, c’est décider plus vite.

En bref :

• 

  HiPPO – Highest Paid Person’s Opinion

  • Anti-pattern : Le chef qui impose son avis

  • Description : Il entre dans la salle, parle, et tout le monde s’écrase. L’avis du HiPPO écrase les données, les débats, et parfois… la logique.

• 

  MULE – Manager Unwilling to Listen to Evidence

  • Anti-pattern : Le têtu borné

  • Description : Rien à faire, même avec 10 dashboards : il reste campé sur sa première intuition. C’est « comme ça », parce qu’il l’a décidé.

• 

  SHEEP – Scared Human Emulating Every Peer

  • Anti-pattern : Le suiveur conformiste

  • Description : Il ne réfléchit pas, il imite. Si tout le monde va à droite, il suit. Même si la falaise est à droite.

• 

  RABBIT – Reluctant Analyst Blocked By Information Tension

  • Anti-pattern : Paralysé par trop d’infos

  • Description : Il veut toutes les données, toutes les certitudes. Mais il n’agit jamais. Figé, il attend… encore un peu plus de data.

• 

  PEACOCK – Proud Executive Avoiding Counter Opinion or Knowledge

  • Anti-pattern : Trop fier pour être challengé

  • Description : Il parade, il brille, mais il ne veut surtout pas entendre que son idée pourrait être mauvaise. Le paon a toujours raison.

• 

  CHICKEN – Cautious Human Ignoring Change, Keeping Everything Normal

  • Anti-pattern : Refus du risque

  • Description : Rien ne doit bouger. Surtout pas. Le changement fait peur. Il préfère sécuriser le connu, même si ça coule doucement.

• 

  MAGPIE – Manager Attracted to Gadgets, Projects, Ideas Endlessly

  • Anti-pattern : Dispersé par les nouveautés

  • Description : Il voit une nouvelle techno, il fonce. Un nouveau buzzword ? Il veut un proof-of-concept. Mais rien ne dure, rien ne se termine.

• 

  WOLF – Works Only Like a Free-agent

  • Anti-pattern : Le loup solitaire

  • Description : Il prend ses décisions seul. Il consulte rarement, car il croit aller plus vite sans la meute. Mais il s’égare souvent.

• 

  CAMEL – Changes Approach Monthly, Everyone Lost

  • Anti-pattern : Girouette stratégique

  • Description : Il change de direction dès qu’il entend un nouveau mot à la mode. Un jour data mesh, le lendemain SAFe, après-demain lean UX…

• 

  OSTRICH – Overlooking Situations That Require Immediate Courageous Handling

  • Anti-pattern : L’autruche qui évite les problèmes

  • Description : Tant qu’il ne regarde pas le problème, il n’existe pas. Il enterre la tête, repousse, minimise, espérant que ça passe.

• 

  BULL – Boss Using Loud Leadership

  • Anti-pattern : Il impose par la force et le volume

  • Description : Il charge, il parle fort, et pousse à décider trop vite. Il confond autorité et clarté, et prend de la place plus qu’il ne partage la réflexion.

En conclusion : la data n’est qu’un levier parmi d’autres

Tous ces profils ont une part de peur, d’ego ou de culture derrière leur comportement. Ce n’est pas la donnée seule qui les convaincra, mais la confiance, l’écoute et le cadre de sécurité dans lequel elle est partagée.

Utilisez ce bestiaire avec bienveillance. Pas pour pointer du doigt… mais pour initier la discussion. Car reconnaître un anti-pattern, c’est déjà faire le premier pas vers une meilleure décision.

The post 10 anti-patterns de prise de décision en entreprise … et comment les transformer en alliés pour l’action appeared first on Coach agile.

J’ai longtemps hésité avant d’écrire ces mots. Parce que ce que j’observe dans vos organisations, jour après jour, me laisse un goût d’inachevé. Des ambitions sincères, des talents brillants… et pourtant.

“On veut innover, être agile, maximiser notre impact business.”

Je vous crois sur parole. Mais le même obstacle se dresse invariablement lorsque j’analyse vos structures décisionnelles :

Vous ambitionnez les résultats et les profits des licornes tout en pilotant obstinément votre équipe tech comme un simple centre de coût.

Ce n’est pas une subtilité sémantique. C’est une contradiction fondamentale qui sabote silencieusement vos initiatives de transformation avant même qu’elles ne prennent leur envol.

Une question de structure, pas de moyens

Régulièrement McKinsey se penche sur la question de performance des entreprises. Et meme si je suis tres éloignée de la philosophie de ce grand cabinet, forcee de contaster que leurs études et leur findings sont souvent suivies comme paroles dévangiles parles dirigeants que j’accompagne.

Leur étude “Developer Velocity” est formelle : les entreprises du premier quartile en matière de connaissent une croissance 4 à 5 fois plus rapide que celles du dernier quartile. Elles affichent des rendements pour les actionnaires supérieurs de 60% et des marges opérationnelles meilleures de 20%. Ce qui fait vraiment la différence ? Ni la taille, ni le budget, ni même la culture d’entreprise déclarée. C’est fondamentalement structurel.

Prenez Amazon et Spotify. On les cite en exemple, parfois jusqu’à l’indigestion. Mais ce qui fait leur force n’est pas un slogan inspirant sur un mur – c’est un choix fondamental d’organisation:

• AWS n’est pas né d’une illumination stratégique soudaine. Une simple règle organisationnelle – exiger que chaque service interne soit accessible par API – a façonné méthodiquement une architecture modulaire exploitable à l’échelle mondiale. Ce n’était pas un “moonshot” visionnaire. C’était une discipline quotidienne, ancrée dans les structures décisionnelles.

• Chez Spotify, quand une équipe prend en charge un domaine, elle en devient véritablement propriétaire. Sa mission n’est pas de livrer des fonctionnalités mais de créer de l’impact. L’expérimentation n’est pas une faveur qu’on lui accorde – c’est sa responsabilité fondamentale.

Ces entreprises n’ont pas simplement déclaré que “la tech est importante”. Elles ont construit leur organisation entière autour d’une conviction: la tech n’est pas là pour exécuter une stratégie, elle est la stratégie en action.

L’illusion du contrôle qui vous paralyse

Je l’ai vu trop souvent. Dans cette salle de réunion feutrée où l’on transmet à la tech “les besoins du business”. Comme si ces deux mondes devaient rester étrangers l’un à l’autre.

La tech hoche poliment la tête. On lui demande des délais, des estimations. On la jugera sur sa capacité à livrer… quelque chose qui a été pensé ailleurs, par d’autres.
Je me demande alors: livrer vite… quoi exactement? Et pour résoudre quel problème fondamental?

Dans une organisation centrée produit, la question est différente: quelles sont les souffrances, les attentes, les désirs inassouvis de nos clients? Quelles frictions essentielles devons-nous éliminer pour nos clients ? Et la tech devient alors co-auteure des solutions, pas simplement leur fabricante.

Cette nuance change tout: le niveau de responsabilité n’est plus le même.

Et ça, vous ne le transformerez pas avec un séminaire inspirant ou une formation éclair. Ça se construit dans les fondations mêmes: comment vous financez, comment vous décidez, comment vous mesurez le succès.

Ne blâmez pas la culture quand c’est le système qui étouffe

J’entends souvent: “c’est un problème de culture”. Mais la culture n’est que le reflet des structures que vous avez mises en place.
Si vous construisez un monde où:

• Les décisions importantes se prennent loin du terrain,

• L’argent est attribué projet par projet, sans flexibilité,

• Le succès se mesure à la conformité au planning initial,

…alors ne soyez pas surpris que vos équipes s’installent confortablement dans un rôle d’exécutant. Elles ne font que s’adapter intelligemment au système que vous avez créé pour elles.

L’étude McKinsey révèle que la sécurité psychologique constitue l’élément culturel fondamental pour catalyser l’innovation. Un environnement où l’expérimentation – et même l’échec – sont valorisés comme sources d’apprentissage. Pourtant, seuls 20% des dirigeants estiment avoir instauré ce type d’environnement.

Les organisations performantes ne se contentent pas d’encourager l’initiative – elles l’institutionnalisent par des systèmes qui absorbent et valorisent les échecs instructifs : déploiements progressifs, tests automatisés, rituels de rétrospective constructifs.

Je repense souvent à cette phrase de Deming, qui m’a fait comprendre tant de choses: “Un mauvais système battra toujours une bonne personne.“

Vous voulez changer votre culture tech? Commencez par changer les règles du jeu.

Le financement par projet : un héritage toxique de l’ère industrielle

Le financement par projet: cette prison dorée qui procure l’illusion réconfortante de la maîtrise. Cette approche, héritée de contextes stables et prévisibles, génère trois handicaps majeurs dans l’économie d’aujourdhui :

1. Elle cristallise les décisions prématurément, quand la compréhension du problème est encore embryonnaire et vous empêche donc de pivoter quand le monde change (et il change toujours).

2. Elle pénalise l’apprentissage en estimant que tout peut être planifié à l’avance

3. Elle incite à livrer des solutions conformes aux spécifications initiales, même quand celles-ci ne répondent plus au besoin réel – livrer pour livrer, même quand il n’y a aucun rationnel économique le justifiant.

Mais son défaut le plus pernicieux est qu’elle institutionnalise la position subalterne de la tech. Les projets sont conceptualisés ailleurs, puis “commandés” aux équipes techniques. Ces dernières n’étant responsable ni du quoi, ni du pourquoi – uniquement du comment. Ce n’est pas un partenariat stratégique. C’est une relation client-fournisseur interne – une sous-traitance a peine déguisée.

Les données sont sans appel : l’étude “Developer Velocity Index” démontre que les entreprises finançant leurs équipes par capacité continue – plutôt que par projet – génèrent jusqu’à 5 fois plus d’innovation et de croissance.

Centre de cout vs Centre de profit

Un centre de coût, c’est comme un puits sans fond qu’il faut sans cesse combler. On cherche naturellement à: réduire ce qui sort, justifier chaque euro dépensé, et contrôler l’exécution dans les moindres détails.

Un centre de profit, c’est un jardin qu’on cultive pour qu’il fleurisse. On y investit pour créer de nouvelles formes de valeur, explorer des territoires inconnus, mesurer non pas l’effort, mais la récolte.

Cette distinction fondamentale transforme intégralement votre approche :

comparaison centre de cout vs centre de profit

J’observe constamment des organisations qui espèrent les bénéfices de la colonne de droite tout en s’enfermant résolument dans les pratiques de la colonne de gauche.

Cette incohérence n’est pas juste inefficace – elle est structurellement vouée à l’échec.

L’avantage concurrentiel négligé : l’habilitation des développeurs

Un résultat particulièrement éloquent de l’étude McKinsey concerne l’impact des outils et des pratiques mis à disposition des équipes techniques. Les entreprises du premier quartile en Developer Velocity sont 65% plus innovantes que leurs concurrentes, simplement grâce à des outils de qualité pour la planification, le développement et la collaboration.

Plus significatif encore : ces organisations affichent des taux de rétention des talents supérieurs de 47%. Elles accordent aux développeurs un degré d’autonomie dans le choix des outils – typiquement entre deux et cinq options pour répondre à différents besoins.

Traiter vos développeurs comme des artisans à qui l’on fournit les meilleurs instruments, plutôt que comme des ressources interchangeables, n’est pas un coût – c’est un investissement à rendement exponentiel.

Le mode Produit : votre avantage stratégique inexploité

McKinsey souligne que les entreprises performantes ont développé une fonction de gestion de produit complète et équilibrée. Cette capacité dépasse largement la livraison de projets dans les délais impartis.

Ce dont on parle ici est la mise en oeuvre d’un Product Operating Model – dans le sens Marty Cagan du terme : s’assurer que les bonnes solutions aux problèmes de nos clients sont construites pour leur offrir une expérience client supérieure. Les équipes les plus efficaces combinent une compréhension approfondie du marché avec des compétences techniques solides.

Les données montrent que les organisations maîtrisant les six dimensions clés du POM – expérience client, compétences stratégiques, acumen business, compétences techniques, leadership et facilitateurs organisationnels – obtiennent des scores 1,5 fois plus élevés que celles excellant dans seulement une ou deux dimensions.

La décision stratégique incontournable

“On n’a pas les moyens de Google ou d’Amazon” – j’entends cela presque chaque semaine.

Mais le véritable avantage de ces entreprises n’est pas leur trésor de guerre. C’est leur capacité à apprendre vite. À essayer. À se tromper. À recommencer, différemment.

Et cela, je vous le promets, n’est pas une question de budget. C’est une question de courage organisationnel:

• Financer des équipes pour leur impact, pas pour leurs tâches,

• Construire des équipes stables autour de missions durables, pas de projets éphémères,

• Mesurer les résultats qui comptent, pas l’activité qui rassure.

Tout cela est à votre portée. Mais cela demande de faire un choix fondamental : considérer réellement la tech comme un moteur de création de valeur, pas comme une ligne de dépense à optimiser.

Les transformations agiles / produit échouent massivement pour une raison fondamentale : on ne peut exiger d’une équipe qu’elle innove, soit agile et crée de la valeur lorsqu’on la structure comme un centre de coût, l’organise en silos et la juge comme un simple exécutant.

Si votre avenir stratégique dépend de votre capacité technologique – ce qui est désormais le cas dans tous presque tous les secteurs by the way – alors votre fonction Tech n’est pas “un département parmi d’autres”. Elle est le tissu même de votre entreprise, le coeur de votre succés business.

La question n’est donc pas de savoir si vous devez imiter les méthodes d’Amazon ou de Spotify. La vraie question stratégique est :

Êtes-vous prêt à transformer fondamentalement vos structures décisionnelles et financières pour considérer votre tech comme un véritable centre de profit ?

Cette décision semble simple en théorie. Sa mise en œuvre implique de reconsidérer intégralement vos mécanismes d’allocation des ressources, vos structures de gouvernance et vos critères d’évaluation de la performance.

Les données McKinsey sont formelles : les entreprises qui franchissent ce pas surpassent systématiquement leurs concurrents en termes de croissance, de rendement pour les actionnaires, de marges opérationnelles, d’innovation, de satisfaction client et d’attraction des talents.

La question n’est donc plus de savoir si vous pouvez vous permettre cette transformation. La question est : pouvez-vous vous permettre de l’éviter ?

ON EN PARLE ENSEMBLE ?

The post Votre équipe tech est un centre de coût ? Le vrai prix de cette erreur stratégique appeared first on Coach agile.

Cependant tu n’es pas satisfait, au fond de toi, tu sens qu’un truc cloche.

Sont-ce les mêmes idées qui tournent en boucle ? Les décisions prises par un petit cercle toujours identique ? Tu n’es pas certain d’arriver à mettre le doigt sur ton malaise.

Maintenant, imagine une équipe où les échanges fusent, où les angles morts sont challengés, où chaque membre apporte une perspective qui fait évoluer les débats.

La différence majeure entre ces deux équipes ? La diversité.

Et si tu pouvais mesurer cette diversité et en faire un véritable levier de performance ? C’est exactement ce que permet l’atelier Diversity Index.

Diversity Index : Un Miroir Impitoyable

De nombreuses études convergent et annoncent qu’une équipe diversifiée est plus performante.
Par exemple, le livre Accelerate, dont nous parlons beaucoup sur la chaîne, met en lumière un paradoxe inquiétant : malgré les nombreuses études et preuves, les entreprises technologiques peinent à recruter et surtout à retenir des femmes et des minorités dans les rôles techniques. Parmi les raisons évoquées :

• Des croyances culturelles limitantes : L’idée fausse que certains groupes sont naturellement plus doués pour les activités intellectuelles freine la diversité​

• Des environnements peu inclusifs : Harcèlement, micro-agressions, inégalités salariales… autant de facteurs qui rendent l’intégration et la progression difficiles.

• Une représentation insuffisante : 33 % des équipes tech étudiées dans Accelerate ne comptaient aucune femme, et 81 % en comptaient moins de 25 %

Etude accelerate

Pourtant, le livre mentionne très clairement que la diversité des équipes améliore leur performance. L’ouvrage cite plusieurs études démontrant que les équipes diversifiées, notamment en termes de genre et de représentation des minorités, sont plus “intelligentes”, obtiennent de meilleures performances et génèrent de meilleurs résultats commerciaux​.

Et Chez Toi ?

Et le truc… c’est qu’on croit toujours que notre équipe est diversifiée. Mais… est-ce vraiment le cas ?
L’atelier Diversity Index va te donner la réponse, sans filtre.

Comment Ça Se Passe ?

On pose les cartes sur la table. Façon de dire : L’équipe définit ensemble les critères de diversité qui comptent pour elle : parcours, compétences, origines, façons de travailler…
On met les chiffres en face des croyances. Chaque membre complète le tableau Diversity Index. On calcule. Et là, surprise : souvent, la diversité est bien plus faible qu’on ne le pensait.
On prend conscience du manque. C’est le moment “OK, on a un problème”. On identifie où on tourne en rond et ce qu’on rate en restant dans notre bulle.
On passe à l’action. On ne fait pas cet atelier juste pour le fun. On cherche des solutions concrètes :

• Qui manque à l’équipe et pourquoi ?

• Quels points de vue ne sont pas représentés ?

• Comment recruter ou intégrer plus de diversité ?

Pourquoi Ça Va Transformer Ton Équipe

Cet atelier est un atelier vraiment sous-côté du Management 3.0. Tu peux d’ailleurs télécharger le template en suivant ce lien, c’est cadeau :

TÉLÉCHARGEZ LE KIT DE FACILITATION DE L’ATELIER DIVERSITY INDEX

Les impacts que j’ai pu obtenir grâce à cet atelier :

• Des décisions plus intelligentes : Quand tout le monde pense pareil, on manque des opportunités. La diversité permet de voir les risques cachés et d’anticiper l’imprévu.

  • Comme chez Cdiscount, où j’ai pu intervenir : Une équipe de développement produit travaillait sur la fonctionnalité de recommandations d’achat basées sur l’historique des utilisateurs. L’équipe, composée majoritairement d’ingénieurs “hommes- blancs”, n’avait pas identifié un biais important : les recommandations excluaient involontairement certains profils de consommateurs aux habitudes d’achat différentes. L’intégration d’un data scientist d’origine asiatique a permis de repérer ce problème et d’ajuster l’algorithme. Résultat : une augmentation de 12% du taux de conversion sur ces segments de clientèle.

• Un boost de créativité : Les idées disruptives naissent du mélange des perspectives. Une équipe diverse, c’est une équipe qui innove.

  • Une anecdote que j’ai pu vivre chez Betclic : l’équipe marketing cherchait à attirer une nouvelle génération de parieurs. Nous cherchions des idées pour y parvenir lorsqu’un UX designer issu du monde du gaming a rejoint l’entreprise. Il a pu proposer quelque chose d’inenvisagé (à l’époque) : Intégrer le e-sport aux paris sportifs. Résultat ? Une explosion de plus de 10% des inscriptions.

• Une culture plus inclusive (et attractive) : Les talents d’aujourd’hui veulent travailler dans des environnements où chacun a sa place. La diversité, c’est un atout pour attirer et garder les meilleurs.

• Un impact business prouvé (tu trouveras quelques liens en fin d’article) : Les entreprises avec des équipes diverses sont 35% plus performantes . Ce n’est pas juste un concept sympa, c’est un moteur de succès.

Au-delà de l’impact; comment mesurer les progrès dus à la diversification ?

Tu veux plus de concret ? Voilà mes astuces pour savoir si cet atelier a vraiment changé quelque chose :

• Refais le test dans 6 mois : ton score Diversity Index a-t-il évolué ?

• Analyse et mesure les dynamiques des réunions AVANT et APRES l’atelier : La répartition du temps de parole ? Qui est écouté ? Qui décide ?

• Regarde les résultats : plus de créativité, moins de décisions ratées, une meilleure dynamique d’équipe… ça se voit vite:

  • Pour la créativité, tu peux par exemple mesurer le nombre de solutions proposées face à un problème utilisateur ainsi que le nombre de personnes proposant des solutions.

  • Pour des décisions “ratées”, je t’invite à, par exemple, mesurer le taux d’usage des fonctionnalités ou le taux de feedbacks négatifs. Si ces indicateurs ne collent pas à ton contexte, tu peux en trouver d’autres dans l’Evidence Based Management.

  • Pour la dynamique d’équipe, mesure la satisfaction des équipiers, par exemple avec un Niko-Niko. A grande échelle, tu peux aussi mesurer le turnover en le voyant sans doute baisser.

• Mesure l’engagement, par exemple en complétant avec les moving motivators : une équipe qui se sent écoutée et reconnue, c’est une équipe qui s’investit à 100 %.

La Place des Femmes dans l’IT : Un Enjeu Crucial

Historiquement, les femmes ont joué un rôle absolument majeur dans l’informatique. Des pionnières comme Ada Lovelace ou Grace Hopper ont jeté les bases de la programmation moderne. Pourtant, aujourd’hui, les femmes ne représentent que 25% des salariés du secteur informatique en France.

C’est vraiment dommage, d’autant plus que, comme nous venons de le dire, la diversité de genre est un vecteur essentiel d’innovation et de performance. Je le répète : les études scientifiques convergent vers ce fait, la diversité de genre est un vecteur essentiel d’innovation et de performance. Les équipes mixtes apportent des perspectives variées, favorisent la créativité et améliorent la prise de décision.

Alors… que peux-TU faire ? TOI ! Concrètement ?

Nous devons réfléchir ensemble à des actions concrètes pour promouvoir l’égalité dans le secteur IT. L’enjeu de sensibiliser ton équipe ou ton organisation à la diversité ? Ne pas s’arrêter à une simple prise de conscience, mais enclencher un véritable changement durable.
Intégrer l’atelier Diversity Index dans ton équipe à cette date peut-etre, au delà d’une démarche forte, une première étape pour mesurer la situation actuelle et identifier des leviers d’action concrets dans ton contexte. Et surtout, surtout, cela peut permettre d’inscrire la diversité dans une dynamique continue, bien au-delà du 8 mars, pas juste un truc que l’on fait une fois pour se donner bonne conscience.

SOURCES

Pour aller plus loin

• McKinsey & Company a mené une étude révélant que les entreprises les plus diversifiées sur le plan ethnique et culturel ont 35 % plus de chances de surpasser leurs concurrents en termes de rentabilité. ​

• Une étude réalisée par Goodwill Management pour IMS-Entreprendre pour la Cité, impliquant des entreprises comme AXA, L’Oréal, Orange et Vinci, indique que la diversité, lorsqu’elle est bien gérée, peut augmenter la rentabilité de 5 à 15 %, selon les secteurs d’activité. ​

• Une étude publiée dans la revue Management & Avenir souligne que la diversité, en influençant les processus managériaux, informationnels, communicationnels, productifs et créatifs, apparaît comme un levier potentiel et conditionnel de performance pour les organisations. ​

• Selon une étude de Harvard Business Review, les organisations inclusives et diversifiées sont 70 % plus susceptibles de conquérir de nouveaux marchés et d’atteindre de nouveaux publics.

The post Diversity Index : L’atelier M3K qui va bousculer ton équipe (et c’est tant mieux) appeared first on Coach agile.

Scrum a plus de 30 ans, les principes de l’Agile ont plus de 20 ans, et nous entrons maintenant dans l’Âge de l’IA, un nouveau monde étrange où l’intelligence est disponible en tant que service. Comment l’IA impacte-t-elle l’agilité ou les frameworks populaires comme Scrum ?

La plupart des pratiques et principes Agile sont basés sur des suppositions concernant le comportement humain et la productivité des équipes. Certaines de ces suppositions sont toujours vraies, mais certaines doivent être remises en question et réévaluées, ce qui impactera les pratiques.
Cet article est un mélange d’observation et de prédiction – ce que j’ai déjà vu se produire, et quelques spéculations sur ce que je pense qu’il va se passer dans un avenir proche.

En tant que lecteur, le principal à retenir est ceci : soyez prêt pour le changement. Je ne sais pas exactement comment les choses vont changer (cet article n’est que certaines de mes suppositions), mais je suis assez confiant que l’Agile à l’Âge de l’IA sera différent d’avant. Alors, prenez du recul, regardez attentivement comment vous travaillez aujourd’hui, et commencez à tout remettre en question.

Les équipes pluridisciplinaires

Lorsqu’on parle d’équipes et d’agilité, on imagine du travail effectué par de petites équipes auto-organisées et pluridisciplinaires. Pluridisciplinaire signifie que les membres de l’équipe possèdent différentes compétences qui se complètent. Le dessin ci-dessous utilise des cercles pour symboliser les connaissances et compétences qui se chevauchent de chaque membre de l’équipe.

Mais pourquoi avons-nous réellement besoin d’équipes pluridisciplinaires ?

L’hypothèse sous-jacente ici est que l’équipe a besoin d’un mélange de compétences complémentaires, sinon elle ne peut pas construire ce qu’elle est censée construire. Une équipe pluridisciplinaire possède toutes les compétences nécessaires pour construire de manière autonome un produit expédiable par incrément, avec un minimum de dépendances vis-à-vis des autres équipes. Les compétences complémentaires qui se chevauchent sont nécessaires à cela.

Mais avec l’IA générative, chaque personne a effectivement un collègue IA qui est incroyablement rapide et connaît tous les langages de programmation, tous les frameworks, tous les modèles, et possède bien plus de connaissances que n’importe quelle personne. En utilisant la même métaphore visuelle, ajouter un membre de l’équipe IA signifie ajouter un cercle de connaissances bien plus grand que n’importe lequel des cercles humains (bien qu’il y ait encore des connaissances humaines que le modèle d’IA n’a pas).

Les modèles d’IA ne sont pas encore parfaits, ils nécessitent une supervision humaine, mais une ou deux personnes possédant de solides compétences en ingénierie de prompts et ayant accès à un modèle d’IA générative de pointe seront plus performantes qu’une équipe agile pluridisciplinaire traditionnelle – tant en termes de vitesse que de qualité. Je le vis régulièrement moi-même – avec un collègue IA, je peux construire en heures ce qui aurait pris des jours, et construire en jours ce qui aurait pris des semaines.

Ainsi, les équipes pluridisciplinaires sont excellentes, mais elles ne sont pas aussi importantes qu’auparavant, puisque la connaissance n’est vraiment plus le goulot d’étranglement. Une équipe de 1-2 personnes + IA a accès à la plupart des connaissances dont elle a besoin.

Pourquoi 2 personnes ? Pourquoi pas 1 ? Parce qu’il est agréable d’avoir un autre humain avec qui parler, et plus facile de gérer des choses comme les vacances et les congés maladie.

Alors, que se passe-t-il réellement lorsque la taille de l’équipe se réduit à 2 personnes ? Licencie-t-on tous les autres membres de l’équipe ? Non, je pense que les entreprises intelligentes vont doter tout le monde de pouvoirs IA, au lieu de n’en doter que quelques-uns et de licencier les autres. Licencier un grand nombre de personnes pour cette raison risque de créer une culture de peur et un manque d’innovation – les gens ne seront pas incités à explorer davantage cette technologie, puisque l’efficacité accrue signifie plus de licenciements.

Prenons donc l’exemple où nous avions initialement 2 équipes pluridisciplinaires de 5 personnes chacune. Cela pourrait maintenant être divisé en 5 équipes de 2 personnes + IA.

Sur quoi ces équipes plus petites travaillent-elles ? Cela dépend du contexte. C’est un problème de luxe : “nous avons maintenant augmenté notre capacité de développement, que devons-nous en faire ?”.

Disons que les deux équipes plus grandes travaillaient ensemble sur un seul produit, en se concentrant sur différentes zones de fonctionnalités. Maintenant, nous avons 5 équipes plus petites, chacune étant plus productive qu’une équipe plus grande précédente. Nous pourrions faire en sorte que les 5 équipes travaillent sur le même produit, en se concentrant sur différentes zones de fonctionnalités comme avant. Le résultat est que nous ferons plus de choses sur ce produit. Ou peut-être que nous laissons 3 équipes se concentrer sur le produit existant, et 2 équipes travailler sur un nouveau produit, amplifiant ainsi la productivité globale de l’entreprise.

Équipes plus petites = Plus d’équipes

Une conséquence des équipes renforcées par l’IA est que nous aurons probablement des équipes plus petites, et plus nombreuses.
Des équipes plus petites signifient moins besoin de réunions et d’autres rituels de coordination interne. Si elles sont assises l’une à côté de l’autre (physiquement ou numériquement) et parlent informellement chaque fois que nécessaire, alors elles n’ont guère besoin de réunions formelles au sein de l’équipe – par exemple, il y a moins besoin d’une réunion quotidienne debout quand elles peuvent simplement parler à tout moment. Bien qu’elles puissent le faire de toute façon pour des raisons sociales.

D’autre part, nous avons plus d’équipes qu’avant. Donc, nous aurons un besoin accru de coordination entre les équipes, au moins si les équipes travaillent sur le même produit et ont des dépendances. En fait, si elles travaillent sur le même produit, peut-être que chaque équipe peut être vue comme un seul membre d’équipe dans une plus grande “super équipe” ou quelque chose du genre, et alors nous faisons des rituels comme les rétrospectives et les réunions de planification de sprint à un niveau équipe-des-équipes ?

Quoi qu’il en soit, je suspecte que la plupart des entreprises finiront par organiser une sorte de réunion quotidienne de synchronisation et une sorte de session de planification toutes les quelques semaines. Mais la structure des réunions sera différente des pratiques agiles traditionnelles, par exemple, elles seront probablement des réunions inter-équipes plutôt qu’internes à l’équipe, et les sessions de planification se concentreront probablement davantage sur le grand tableau plutôt que sur des éléments spécifiques du backlog.

Pour être clair : je ne sais pas où nous atterrirons. Mais je suis assez sûr que les choses changeront, car les hypothèses sous-jacentes à de nombreuses pratiques agiles sont renversées par l’avènement de l’IA Générative.

La principale compétence des développeurs n’est plus de coder

Une tendance claire est que les modèles d’IA deviennent vraiment bons pour écrire du code. Pas encore parfaits, mais suffisamment bons pour qu’il soit logique de laisser votre collègue IA écrire la majorité du code. Cela change fondamentalement le rôle. En tant qu’ingénieur logiciel, vous devez toujours être aux commandes, réfléchir à l’architecture, écrire les prompts, examiner les résultats et prendre la responsabilité de la qualité du code. Mais l’artisanat réel de l’écriture du code – pour la plupart, l’IA le fera plus rapidement et mieux que vous. C’est en partie vrai déjà aujourd’hui, et dans un an, cela sera probablement vrai 90% du temps. Un développeur logiciel qui insiste pour écrire tout le code manuellement à l’ère de l’IA risque de devenir un goulot d’étranglement et une source de bugs.

Donc, les développeurs deviennent essentiellement des mini-product owners, si j’utilise la terminologie Scrum. Leur travail est de décider quel code doit être écrit, non de l’écrire. C’est comparable à quand vous écrivez du code de haut niveau en utilisant un langage de programmation moderne, et que le compilateur le transforme en code machine – sauf que maintenant nous élevons cela d’un niveau et le modèle d’IA écrit également le code de haut niveau.

Votre collègue IA peut même travailler en arrière-plan. Imaginez cette conversation entre Bob, Lisa et leur collègue IA MrFixit autour d’un café le matin :

• MrFixit : “Bonjour tout le monde ! Quelques rapports de bugs sont arrivés la nuit dernière, deux d’entre eux étaient assez simples donc je les ai corrigés et mis en PR (pull requests)”

• Lisa : “Super, je vais le revoir dans un moment. Des trucs risqués là-dedans ?”

• MrFixit : “Eh bien, j’ai dû changer un peu la connexion. J’ai ajouté plus de tests donc c’est probablement bon, mais cette partie pourrait mériter un examen supplémentaire.”

• Lisa : “OK, je m’en occupe”.

• Bob : “Hé MrFixit, tu as vu cette discussion sur Slack concernant les failles de sécurité ?”

• MrFixit : “Oui, tu veux que je regarde ? J’ai quelques idées.”

• Bob : “Oui, s’il te plaît.”

• MrFixit : “OK, attends……. Voilà ! J’ai mis en place trois PRs, avec trois approches différentes pour résoudre le problème. Voir la description des PR pour les détails. Jetez un œil et faites-moi signe si vous voulez discuter de l’une de ces solutions.”

• Bob : “Génial !”.

Cela peut sembler assez exotique maintenant, mais dans un an, je pense que cela sera la norme pour de nombreuses équipes.

Le résultat : le codage n’est plus le goulot d’étranglement. Alors, que signifie cela pour des concepts comme les Sprints Scrum, une période limitée dans le temps (généralement 2-3 semaines) pour permettre à l’équipe de se concentrer sur le développement ? Eh bien, si le travail qui prenait normalement une semaine prend maintenant un jour, et le travail qui prenait normalement un jour prend maintenant une heure, avons-nous besoin de sprints ?

Des sprints d’1 journée ?

Je suppose que les sprints deviendront progressivement beaucoup plus courts, ou disparaîtront entièrement. Peut-être des sprints d’1 journée. Commencer la journée par une rapide synchronisation avec votre collègue humain et IA, décider sur quoi se concentrer aujourd’hui, puis terminer et publier avant la fin de la journée, et faire une rapide révision avant de rentrer chez soi. Le Daily Standup et la planification de Sprint deviennent essentiellement la même chose.

Avec plusieurs équipes travaillant ensemble, il y aura toujours besoin d’une réunion de synchronisation de niveau supérieur, peut-être une fois par semaine, pour s’assurer qu’elles sont alignées. Cela est vrai avec ou sans IA, mais le besoin s’accroît à mesure que nous évoluons vers plus d’équipes plus petites plutôt que quelques équipes plus grandes.

Comme je l’ai mentionné, je pense qu’il y a toujours un besoin humain pour une sorte de réunion de synchronisation et de planification toutes les quelques semaines. Mais le but et la structure de cette réunion changeront lorsque nous passerons à des cycles de développement plus rapides et plus courts, quand il n’y aura plus besoin de regrouper le travail en plusieurs semaines de travail juste parce que coder prend du temps.

Des spécialistes itinérants ou partagés ?

Et qu’en est-il des spécialistes ? Disons que nos équipes doivent traiter des bases de données et de la persistance, et ont besoin de connaissances spécialisées pour cela.

Traditionnellement, nous nous assurerions que chaque équipe pluridisciplinaire avait au moins une personne avec des compétences en base de données. Dans une équipe de 2 personnes renforcée par l’IA, les humains manqueront de certaines compétences et devront compter sur leur collègue IA. Est-ce que cela suffira ? Pour les tâches routinières, probablement oui. Mais parfois, pour des tâches plus avancées, un spécialiste humain sera nécessaire, par exemple pour formuler le prompt ou évaluer le résultat, ou peut-être pour construire des outils. Le spécialiste humain peut également aider à déterminer quels modèles et outils d’IA sont adaptés à la tâche en cours, ou même affiner les modèles pour les rendre meilleurs dans ce domaine de connaissance spécialisé.

Je suppose que nous aurons soit des spécialistes itinérants, soit des spécialistes partagés. Ce n’est pas une approche nouvelle, certaines équipes agiles le font de toute manière. Mais je pense que cela deviendra plus commun.

Par exemple, avec les 5 équipes ci-dessus, disons qu’elles utilisent toutes des bases de données. Peut-être qu’une ou deux des équipes ont réellement un spécialiste en base de données, parce qu’elles sont les équipes qui font le plus de travail sur les bases de données. Mais ce sont des spécialistes partagés qui parfois aident aussi les autres équipes.

Une alternative est d’avoir des spécialistes itinérants qui n’appartiennent à aucune équipe spécifique, mais qui vont là où leur besoin est le plus grand. Pour être clair, les modèles d’IA devraient posséder la plupart des connaissances spécialisées nécessaires, mais le spécialiste humain est là en complément pour lorsque nous atteignons les limites de l’IA, ou avons besoin d’une paire supplémentaire d’yeux de spécialiste humain pour évaluer le résultat.

Le rôle du Scrum Master ou du Coach Agile

Si vous avez un rôle comme Scrum Master ou Coach Agile ou similaire, cela inclut traditionnellement l’enseignement et le mentorat de l’équipe sur des sujets comme comment diviser efficacement une user story, comment mener efficacement une rétrospective, et comment travailler efficacement en équipe.

Une équipe renforcée par l’IA possède déjà toutes ces connaissances, si l’équipe choisit de les rechercher. Ainsi, votre rôle devient plus celui d’un coach et moins celui d’un mentor/enseignant. Si l’équipe veut savoir comment diviser une histoire, asseyez-vous avec eux et écrivez un prompt pour chatGPT (ou autre modèle). Vous connaissez cet adage populaire : « Donne un poisson à un homme, et tu le nourris pour un jour. Apprends à un homme à pêcher, et tu le nourris pour toute la vie ». Maintenant que les équipes pêchent leurs propres poissons, vous avez le temps de coacher et d’assister plus d’équipes, et de les aider à comprendre comment utiliser ces cannes à pêche.

La boucle de feedback des utilisateurs

Le retour d’information des utilisateurs reste une partie critique du développement agile, même à l’Ère de l’IA. Cependant, les pratiques changent. Nous serons en mesure de publier plus souvent, donc nos clients et utilisateurs devraient être prêts à recevoir de petites mises à jour fréquemment, au lieu de grandes mises à jour rarement. En conséquence, les utilisateurs peuvent prendre une part plus active dans le développement. Certains apprécieront cela, d’autres peut-être pas.

Si l’utilisateur n’est pas disponible aussi souvent que nécessaire, nous pouvons créer des utilisateurs fictifs en demandant à un modèle d’IA de jouer le rôle d’un type particulier d’utilisateur. Nous pourrions réaliser des recherches et des entretiens avec des utilisateurs fictifs en utilisant cela, et bientôt nous pourrons probablement aussi demander à l’utilisateur fictif d’essayer directement notre système et de nous donner son retour. L’utilisateur fictif ne sera pas aussi utile que le véritable retour des vrais utilisateurs, mais d’un autre côté, nous pouvons obtenir le retour plus rapidement et plus fréquemment, donc cela pourrait être un bon complément. Cela pourrait aider l’équipe à découvrir les problèmes de conception les plus évidents et importants.

Points supplémentaires à considérer

Juste pour le plaisir, j’ai donné l’intégralité de l’article ci-dessus à Claude Opus (le dernier modèle d’IA Générative d’Anthropic) et lui ai demandé de suggérer des points additionnels à ajouter. Voici la réponse non éditée, que j’ai trouvée plutôt bonne :

• Impact sur le backlog produit et la priorisation : Avec des équipes renforcées par l’IA livrant plus rapidement, le backlog produit pourrait nécessiter d’être mis à jour plus fréquemment. Le rôle du Product Owner pourrait évoluer pour se concentrer davantage sur la priorisation stratégique et la gestion des parties prenantes.

• Changements dans l’estimation et la planification : Les techniques traditionnelles d’estimation, telles que les points de story ou les jours idéaux, pourraient devenir moins pertinentes lorsque l’IA peut accélérer significativement le développement. Les équipes pourraient devoir adopter de nouvelles approches pour la planification et la prévision.

• Adaptations dans les cadres Agile : Des cadres Agile populaires comme Scrum, Kanban ou SAFe pourraient devoir être adaptés pour accommoder les changements apportés par l’IA. Par exemple, la durée et la fréquence des événements comme la Planification de Sprint, le Scrum Quotidien et la Revue de Sprint pourraient devoir être ajustées.

• Impact sur la dynamique d’équipe et la collaboration : Bien que l’IA puisse améliorer la productivité, il est essentiel de considérer son impact sur la dynamique d’équipe et la collaboration. Les équipes pourraient devoir trouver de nouvelles manières de favoriser la connexion humaine, la créativité et l’innovation dans un environnement piloté par l’IA.

• Apprentissage continu et développement des compétences : À mesure que l’IA prend en charge certaines tâches, les membres de l’équipe pourraient devoir se concentrer sur le développement de nouvelles compétences, telles que l’ingénierie de prompts, la sélection de modèles d’IA et l’évaluation des résultats. L’apprentissage continu et l’amélioration des compétences deviendront encore plus cruciaux à l’Ère de l’IA.

• Considérations éthiques et transparence : Les équipes devront naviguer à travers les considérations éthiques entourant l’IA, telles que les biais, l’équité et la transparence. Les pratiques Agile pourraient devoir évoluer pour assurer un développement et un déploiement responsables de l’IA.

Recalibrage

(D’accord, c’est moi l’humain qui écris à nouveau)
Mon ami Kent Beck a tweeté ceci :

Je pense que Kent saisit l’essence de ce à quoi nous sommes confrontés maintenant, dans tous les rôles et professions. Nous devons recalibrer ce sur quoi nous passons notre temps. Qu’est-ce que cela signifie d’être un Ingénieur, un Scrum Master, un Product Owner, un Directeur technique, etc. ?

Il en va de même pour l’Agile : nous devons recalibrer nos pratiques agiles. Cela commence par l’auto-réflexion. Sur quoi passons-nous du temps ? Quels sont nos rituels, rôles, artefacts ? Qu’est-ce qui doit être remis en question, changé ou réévalué alors que nous entrons dans l’Ère de l’IA ?

Partagez le post avec vos pensées !

Pour aller plus loin

• Are developers needed in the age of AI?

• Generative AI in a Nutshell – how to survive and thrive in the age of AI

The post Être agile à l’ère de l’IA appeared first on Coach agile.

Il peut être parfois difficile pour le PO d’évaluer certains éléments. C’est pour cette raison qu’il est souvent plus efficace d’organiser un atelier de valorisation à plusieurs : PO, clients, métiers, Business Owner, experts…

J’avais besoin d’un format de workshop permettant d’estimer rapidement la valeur des éléments du backlog (en moins de 3 heures), sur la base de plusieurs critères d’évaluation et en groupe.

Cet atelier, que j’ai mis au point et expérimenté avec succès, est le pendant de l’eXtreme Quotation. Je l’ai donc appelé eXtreme Valorization (oui je sais, je n’ai pas été très original).

Voici le déroulement de l’atelier.

Avant l’atelier

Le PO définit les critères principaux (idéalement entre 3 et 7) de notation de la valeur.

Par exemple :

• Satisfaction client si l’élément est réalisé

• Manque / déception / insatisfaction client si l’élément n’est pas réalisé

• Améliore l’image du produit ou de la marque si l’élément est réalisé

• Dégrade l’image du produit ou de la marque si l’élément n’est pas réalisé

• Donne un coup d’avance sur la concurrence

• Apporte un gain financier ou une optimisation des coûts

• Répond à une obligation légale ou diminue un risque

• Etc.

Vous pouvez en trouvez d’autres, certainement plus adaptés à votre activité.

NB : j’utilise abusivement le mot “client” pour désigner le client ou l’utilisateur.

Notez les critères retenus sur des post-it (1 par post-it). Ensuite, écrivez les éléments du backlog à valoriser, sur des post-it (1 par post-it).

Sur un grand brown paper, tracez 8 colonnes avec la suite de Fibonacci (1, 2, 3, 5, 8, 13, 21, 34…) en entête. Il s’agit des notes.

J’utilise la suite de Fibonacci pour que les notes soient plus clivantes, mais vous pouvez aussi tracer 10 colonnes et y inscrire les chiffres de 1 à 10 en entête.

Une note de 1 signifie que l’élément ne répond pas du tout au critère et une note de 34 signifie qu’il répond parfaitement au critère.

Exemple :

• Pour le critère “satisfaction client si l’élément est réalisé”, une note de 34 signifie que l’élément donnera une satisfaction élevée au client s’il est réalisé.

• Pour le critère “manque / déception / insatisfaction client si l’élément n’est pas réalisé”, une note de 34 signifie que le client sera extrêmement déçu ou insatisfait si l’élément n’est pas réalisé.

Vous êtes prêt pour l’atelier.

Le jour J

Collez le brown paper au mur et disposez les post-it des critères sur le côté.

Présentez l’objectif de l’atelier et son déroulement aux participants.

Puis, le PO présente brièvement chaque élément du backlog.

Collez une flèche à côté du premier critère, c’est celui que nous allons évaluer en premier, puis l’expliquer aux participants.

Distribuez un tas de post-it “éléments du backlog” à chaque participant, y compris le PO.

Puis, chacun colle en silence ses post-it dans la colonne de la note qu’il attribue à l’élément marqué sur le post-it, pour le critère évalué.

Le PO se tient disponible pour éclaircir un élément, au besoin

A la fin, chacun prend du recul et fait une passe sur l’ensemble des post-it collés. C’est le moment d’échanger s’il y a des désaccords dans les notes. En fonction du rôle du PO, celui-ci sera certainement amené à prendre la décision finale en cas de désaccord.

N’oubliez pas, ce qui fait la richesse de l’atelier, ce sont les échanges et les différents points de vue des participants.

Une fois les participants en accord, écrire la note sur chaque post-it (attention à laisser un peu de place, il faudra faire la même chose pour les autres critères)

Prendre une photo et décoller tous les post-it “éléments du backlog” du tableau.

Descendre la flèche sur le critère de notation suivant, l’expliquer aux participants et leur redistribuer les post-it “éléments du backlog”. Ils devront à présent évaluer les éléments sur ce nouveau critère.

Et ainsi de suite.

Il y aura donc autant de tours de notation qu’il y a de critères.

N’oubliez pas de marquer les notes attribuées à chaque élément sur son post-it.

À la fin, faites la somme des notes pour chaque post-it. Cela donne la valeur de chaque élément, sur l’intégralité des critères de notation.

Vous pouvez tout à fait appliquer des coefficients à certains critères s’ils sont plus ou moins importants que d’autres.

Les éléments ayant les notes les plus élevées sont ceux ayant la plus forte valeur.

Le PO dispose maintenant d’une aide précieuse pour prioriser son backlog. D’autres éléments rentreront certainement en compte dans cette priorisation, comme l’estimation de la complexité, les dépendances métier (qu’il faudra tout de même éliminer au maximum), etc.

Vous pouvez faire le même exercice avec un Product Manager sur les fonctionnalités de son Program Backlog

J’ai trouvé que cet exercice donnait de bons résultats, permettant d’établir une première liste de priorités au démarrage d’un projet.

A vous de jouer !

The post Comment estimer rapidement la valeur des éléments du backlog ? appeared first on Coach agile.

“Un utilisateur de Reddit m’a demandé : ‘Est-il acceptable de ne pas utiliser de Sprint Goals lorsque l’on pratique Scrum ?'”.

sprint goal question

C’est une très mauvaise question.

Lorsque vous êtes incapable de définir un Objectif de Sprint, la question de savoir si un Objectif de Sprint est vraiment nécessaire n’est pas une bonne question.

Le problème n’est jamais le conflit avec le Scrum Guide et même parler de l’Objectif de Sprint est sans importance pour répondre à cette question.

Une équipe est un groupe de personnes travaillant vers un objectif commun. Lorsque vous n’avez pas d’objectif commun, alors vous n’avez pas d’équipe.

Le problème est que vous n’avez pas d’équipe, et non que vous n’avez pas d’Objectif de Sprint.

Le conflit avec le Guide Scrum n’est pas ce que vous devriez résoudre car cela n’est JAMAIS ce qui importe. Ce qui importe, c’est le problème réel que vous rencontrez.

Au lieu de demander pourquoi vous êtes en conflit avec le Scrum Guide ou si c’est acceptable d’être en conflit avec le Scrum Guide, prenez le temps de réfléchir à quel est le véritable problème.

Et au moment où vous ne pouvez répondre à cette question qu’avec “Le Guide Scrum dit…”, alors vous ne comprenez pas le problème réel.

La bonne question à poser : pourquoi sommes-nous incapables de travailler en équipe ?

La règle dans le Scrum Guide n’est jamais ce qui importe, c’est ce qu’elle rend possible ou empêche qui importe, et c’est cela dont vous devriez vous soucier : la réalité au lieu de l’adhésion à un guide écrit par des humains faillibles comme vous et moi.

Il est toujours acceptable de ne pas faire quelque chose si cela fonctionne pour vous, car c’est cela qui importe.

The post Est-il acceptable de ne pas utiliser d’Objectifs de Sprint ? appeared first on Coach agile.

8 Problèmes Clés dans le Scrum Guide 2020 : Une Évaluation Critique

La semaine dernière, j’ai terminé ma série “Scrum résiste-t-il à une analyse critique ?“. Je voulais évaluer chaque ligne et chaque mot du Guide Scrum 2020 pour voir s’ils ont du sens pour moi. Globalement, je peux confirmer que le Guide Scrum est solide et cohérent. Je l’aime bien.

Cependant, il y a des passages dans le Guide Scrum qui m’ont fait froncer les sourcils. Des choses qui n’avaient pas de sens pour moi ou qui n’étaient pas en ligne avec la prémisse de Scrum. Voici 8 des choses les plus problématiques pour moi dans le Guide Scrum.

Livre blanc de Gunther Verheyen : « A Brief History of a Long-Lived Hype »

Les valeurs Scrum

Les valeurs : l’engagement, le focus , l’ouverture, le respect et le courage sont clés dans Scrum. Ils donnent vie aux piliers de l’empirisme (transparence, inspection, adaptation). Tout dans Scrum implique l’empirisme.

Mais à quel point est-il réaliste pour l’équipe et les parties prenantes de respecter les valeurs Scrum ? Dès que l’équipe Scrum doit faire face (pour ne citer que quelques exemples) au micro-management, aux silos, à l’évitement des conflits ou à la politique : que reste-t-il des valeurs Scrum ? Et dans une plus large mesure, que reste-t-il de Scrum ?

Pas de hiérarchies

Les équipes Scrum ne devraient pas avoir de hiérarchies. Mais à quel point cela est-il réaliste ? Parmi les trois responsabilités de Scrum (Développeurs, Product Owner, Scrum Master), deux ont un aspect de leadership.

Le Scrum Master est “un véritable leader” de l’équipe Scrum, responsable de l’efficacité de l’équipe. Le Product Owner décide de l’ordre du Product Backlog. Je peux voir comment ces responsabilités peuvent entrer en conflit avec l’idée de “pas de hiérarchies”. Cela peut entraîner des problèmes dans les équipes Scrum.

Je ne dis pas qu’un rôle de leadership mène automatiquement à des hiérarchies. Mais avec un Scrum Master responsable de l’efficacité et un Product Owner pour maximiser la valeur, il est facile pour moi de voir comment cela peut conduire à des hiérarchies.

Le Product Owner est uniquement responsable du travail lié à Scrum

Un Product Owner est responsable du travail effectué par l’équipe Scrum. À première vue, cela semble logique… comme nous parlons de Scrum. Mais lorsque une grande partie ou même la majorité du travail sur un produit est effectué par d’autres que l’équipe Scrum, que reste-t-il du Product Owner ? Le nom n’est-il pas très trompeur dans ces cas ?

Un produit est généralement plus que la fonctionnalité de base seule. Pensez à des aspects tels que le support produit, les ventes ou les systèmes de support externes. Dans presque toutes les situations que j’ai observées, ces responsabilités étaient en dehors des équipes Scrum. Cela signifie que des parties importantes de ce qui fait le produit ne font pas partie des responsabilités du Product Owner. Comment le Product Owner peut-il maximiser la valeur du produit sans avoir une compréhension globale du produit ?

Le Product Owner est une seule personne

Pourquoi un Product Owner devrait-il toujours être une seule personne ? Quel est le problème à avoir une équipe de Product Owner ou une équipe Scrum qui a absorbé les responsabilités du Product Owner et n’a donc personne pour assumer ce rôle ?

Je comprends que le Product Owner a été introduit pour avoir “une seule paire de cordes vocales” (Alistair Cockburn). La raison était de protéger l’équipe Scrum de la réception de différentes demandes de différentes personnes. Je peux confirmer que c’est non seulement ennuyeux et déroutant, mais peut-être même nuisible pour la santé des personnes de l’équipe.

Mais je pense qu’il y a de meilleures façons de résoudre le problème d’une équipe qui est bousculée. Pour commencer, respectons l’autonomie de l’équipe Scrum pour déterminer ce qu’elle va faire, comment elle va le faire et quand. Reconnaissons que l’équipe Scrum est autogérée. Avec cela en place, la règle de la personne unique n’est plus nécessaire. Tant que l’équipe Scrum indique clairement comment elle assume la responsabilité du Product Owner.

Le Scrum Master est une seule personne

Comme le Product Owner, le Guide Scrum stipule qu’il ne devrait y avoir qu’un seul Scrum Master. Je ne vois pas pourquoi cela devrait toujours être le cas. Il y a tellement à faire pour un Scrum Master et cela nécessite tellement de compétences, il est difficile et peut-être même utopique de trouver tout cela en une seule personne.

Je ne vois pas pourquoi Scrum doit être aussi prescriptif. Ils ne peuvent pas me convaincre qu’une équipe Scrum qui fait tout selon la lettre et l’intention de Scrum mais qui a deux Scrum Masters ne fait pas de Scrum.

Le rôle du Product Owner et du Scrum Master lors du Daily Scrum

Le Daily Scrum est pour les Développeurs pour replanifier leurs efforts afin d’atteindre l’objectif du Sprint. La section donne l’impression que le Product Owner et le Scrum Master n’ont pas de rôle à jouer. Je suis d’accord qu’ils ne devraient pas diriger la discussion et que les Développeurs possèdent le Sprint Backlog.

Mais un Scrum Master peut aider les Développeurs à rester dans les 15 minutes et à assurer un suivi positif et quotidien. Je pense que cela mérite une certaine attention. Il en va de même pour le Product Owner, qui peut aider à discuter et -si nécessaire- à ajuster la portée du Sprint Backlog.

Pourquoi le Guide Scrum n’exprime-t-il pas le rôle potentiel du Product Owner et du Scrum Master dans le Daily Scrum ? Comme il est maintenant, la section Daily Scrum du Guide Scrum est quelque peu déroutante et même apparemment contradictoire.

Présenter le résultat du Sprint lors de la Revue de Sprint

Les précédents Guides Scrum indiquaient que l’équipe Scrum et les parties prenantes inspecteraient l’Incrément lors de la Revue de Sprint. Maintenant, c’est changé en “résultat du Sprint” et “résultats de leur travail”. Je pense que c’est un changement pour le pire.

Je comprends que les rédacteurs voulaient éviter la confusion lorsqu’une équipe peut terminer et libérer plusieurs incréments dans un Sprint. Mais les incréments sont “additifs à tous les incréments précédents” (Guide Scrum 2020). Ainsi, l’équipe Scrum peut toujours présenter un incrément lors de la Revue de Sprint : la somme de tous les incréments d’avant le Sprint et tous les incréments (Fait) du Sprint. Ils pourraient appeler cela quelque chose comme “la somme de tous les incréments”.

Maintenant, le Guide Scrum ne fait que créer de la confusion en parlant du résultat du Sprint ou des résultats de leur travail. Cela pose la question : une présentation Powerpoint est-elle un résultat du Sprint ? Je dirais non à cela.

Scrum a toujours consisté à inspecter l’incrément lors de la Revue de Sprint. Je ne comprends pas pourquoi cette ligne a disparu. À d’autres endroits du Guide Scrum, vous pouvez encore trouver cette information, mais pourquoi manque-t-elle dans la section Revue de Sprint ? Cela me laisse perplexe. Et, à mon humble avis, je pense que cela nuit à la compréhension des gens de ce qu’une Revue de Sprint devrait être.

Les développeurs négocient avec le Product Owner pour modifier le Backlog de Sprint

Les développeurs sont propriétaires du Backlog de Sprint. Dans la section Planification de Sprint, nous pouvons lire que les développeurs sélectionnent les éléments du Backlog de produit qui les mèneront à l’Objectif du Sprint. Ils déterminent également comment le travail sera effectué. C’est un changement par rapport au précédent Guide Scrum, où les développeurs se contentaient de déterminer combien d’éléments ils sélectionneraient du Backlog de Sprint. J’ai été à la fois surpris et heureux des changements.

Alors, pourquoi est-ce différent pendant le Sprint ? Lorsque les développeurs apprennent de nouvelles choses pendant le Sprint, ce qui les oblige à changer le Backlog de Sprint (pour atteindre encore l’Objectif du Sprint), ils doivent d’abord négocier avec le Product Owner. Tout d’un coup, les développeurs ne sont plus propriétaires du Backlog de Sprint ?

Je pense que les développeurs ne devraient pas négocier avec le Product Owner. Ils devraient plutôt le consulter ou l’informer. De cette façon, ils incluent toujours le Product Owner dans l’équation tout en étant propriétaires du Backlog de Sprint.

Note de fin

J’aime beaucoup de choses dans le Guide Scrum, mais je lutte aussi avec certaines parties. Êtes-vous d’accord ? Pensez-vous que Scrum est bon tel qu’il est ? Avez-vous d’autres problèmes ? Je suis certainement intéressé à apprendre de vous !.. alors n’hésitez pas à laisser un commentaire !

The post 8 Problèmes Clés dans le Scrum Guide 2020 : Une Évaluation Critique appeared first on Coach agile.

Aujourd’hui, je voulais prendre quelques minutes pour écrire un article, sans doute moins long et moins travaillé que d’habitude afin de poser sur le papier (vous me passerez l’expression) quelques remarques que je me suis faites en regardant la série.

Ted Lasso, le personnage principal de la série éponyme, incarne un entraîneur de football américain qui est embauché pour coacher une équipe de football en Angleterre. À travers son approche unique et inspirante du coaching, Ted Lasso offre de précieuses leçons qui peuvent être appliquées dans le domaine du coaching en général et du coaching agile en particulier. Dans cet article, nous explorerons les parallèles entre les méthodes de coaching de Ted Lasso et les principes agiles pour aider les équipes de réalisation logicielle à atteindre des résultats exceptionnels.

Leçon I. Créer un environnement positif et encourageant

“Be curious, not judgmental.” – “Soyez curieux, pas critique.”

Un coach agile doit créer un environnement de confiance et d’encouragement, favorisant la collaboration, la prise de risques et l’apprentissage continu.

Dans la série, Ted Lasso crée une atmosphère positive et encourageante pour son équipe de football, en instillant confiance et motivation. Son approche curieuse, où il favorise l’apprentissage plutôt que les jugements, ouvre la voie à une communication ouverte et à la créativité. De la même manière, un coach agile doit cultiver un environnement où les membres de l’équipe se sentent en sécurité pour partager leurs idées, poser des questions et explorer de nouvelles solutions. En encourageant la curiosité et en évitant les jugements hâtifs, un coach agile peut stimuler la créativité et la collaboration au sein de l’équipe de réalisation logicielle.

Leçon II. Comprendre les besoins individuels et collectifs

“I believe in hope. I believe in believe.” – “Je crois en l’espoir. Je crois en la croyance.”

Un coach agile doit avoir une compréhension profonde des besoins individuels et collectifs des équipes qu’il accompagne, afin de les soutenir dans leur développement et de les aider à atteindre leurs objectifs.

Dans la série, Ted Lasso prend le temps de connaître chaque joueur de son équipe, comprendre leurs motivations et les aider à s’épanouir sur le terrain. Il croit en l’espoir et en la capacité de ses joueurs à se surpasser. De la même manière, un coach agile doit être empathique et attentif aux besoins individuels des membres de l’équipe de réalisation logicielle. En comprenant les aspirations des équipiers, leurs forces et leurs faiblesses, un coach agile peut les soutenir dans leur développement professionnel et les aider à réaliser leur plein potentiel.

Leçon III. Favoriser la collaboration et l’esprit d’équipe

“There’s two buttons I never like to hit: panic and snooze.” – “Il y a deux boutons sur lesquels je n’aime jamais appuyer : la panique et la snooze.”

Un coach agile doit promouvoir la collaboration et l’esprit d’équipe au sein de celle-ci, en encourageant la communication ouverte, le partage de connaissances et la résolution collective des problèmes.

Dans la série, Ted Lasso met l’accent sur la collaboration et l’esprit d’équipe, encourageant ses joueurs à travailler ensemble et à se soutenir mutuellement. Il refuse de céder à la panique et encourage l’équipe à trouver des solutions ensemble. En favorisant une culture de communication ouverte, de partage de connaissances et de résolution collective des problèmes, un coach agile peut améliorer la cohésion d’équipe et favoriser une culture de confiance et de soutien mutuel.

Leçon IV. Encourager l’apprentissage continu et l’amélioration

“You’re gonna make mistakes. The question is: What next?” – “Tu vas faire des erreurs. La question est : et après ?”

Comment favoriser une culture de remise en question et d’innovation ?

Dans la série, Ted Lasso pousse constamment son équipe à s’améliorer, à apprendre de leurs erreurs et à se développer en tant que joueurs. Il les encourage à voir les erreurs comme des opportunités d’apprentissage et à se concentrer sur la manière de rebondir. De la même manière, un coach agile doit encourager l’apprentissage continu au sein de l’équipe. De manière simple, en mettant en place des rétrospectives régulières, des boucles de feedback… Il encourage également la prise de risques et l’innovation, en incitant l’équipe à sortir de sa zone de confort pour atteindre de nouveaux sommets.

Quelque citations issues de la série que j’aime bien

1. “Be curious, not judgmental.” – “Soyez curieux, pas critique.”

2. “I believe in hope. I believe in believe.” – “Je crois en l’espoir. Je crois en la croyance.”

3. “There’s two buttons I never like to hit: panic and snooze.” – “Il y a deux boutons que je n’aime jamais appuyer : la panique et la snooze.”

4. “Success is not about the wins and losses. It’s about helping these young fellas be the best versions of themselves on and off the field.” – “Le succès ne se résume pas aux victoires et aux défaites. C’est aider ces jeunes à devenir la meilleure version d’eux-mêmes sur et en dehors du terrain.”

5. “Sometimes, a tie feels like a win, and sometimes, a loss feels like a win.” – “Parfois, un match nul peut se sentir comme une victoire, et parfois, une défaite peut se sentir comme une victoire.”

6. “Be a goldfish.” – “Sois un poisson rouge.”

7. “You’re gonna make mistakes. The question is: What next?” – “Tu vas faire des erreurs. La question est : et après ?”

8. “It’s the little things, the inches, that make the difference between winning and losing.” – “Ce sont les petites choses, les centimètres, les détails qui font la différence entre gagner et perdre.”

9. “The happiest animal in the world isn’t one that’s lying on its back waiting for someone to rub its belly. The happiest animal in the world is one that’s busy building something.” – “L’animal le plus heureux du monde n’est pas celui qui est allongé sur le dos en attendant qu’on lui gratte le ventre. L’animal le plus heureux du monde est celui qui est occupé à construire quelque chose.”

10. “Believe in yourselves, believe in each other, and when you do that, it doesn’t matter who doubts you, it doesn’t matter who’s against you, it doesn’t matter who thinks they’re better than you.” – “Croyez en vous, croyez en vos coéquipiers, et lorsque vous faites cela, peu importe qui doute de vous, peu importe qui est contre vous, peu importe qui pense être meilleur que vous.”

11. “Takin’ on a challenge is a lot like riding a horse. If you’re comfortable while you’re doin’ it, you’re probably doin’ it wrong.” – “Relever un défi, c’est un peu comme monter à cheval. Si vous êtes à l’aise pendant que vous le faites, vous le faites probablement mal.”

12. “I’d rather believe in something and be wrong than believe in nothing and be right.” – “Je préfère croire en quelque chose et avoir tort que de croire en rien et avoir raison.”

13. “Success is not about the destination. It’s about the journey.” – “Le succès ne réside pas dans la destination. Il réside dans le voyage.”

14. “When you love something, you want to fight for it. You want to defend it. You want to do right by it.” – “Quand on aime quelque chose, on veut se battre pour elle. On veut la défendre. On veut lui faire honneur.”

15. “The happiest people don’t have the best of everything, they just make the best of everything.” – “Les personnes les plus heureuses n’ont pas forcément le meilleur de tout, elles font simplement de leur mieux avec ce qu’elles ont.”

16. “I think that we all have to have a little bit of faith in ourselves, even when we’re playing the hardest opponent that we’ve ever faced… ourselves.” – “Je pense que nous devons tous avoir un peu de foi en nous-mêmes, même lorsque nous affrontons le plus dur des adversaires… nous-mêmes.”

17. “It’s like Earl Nightingale once said, ‘Don’t let the fear of striking out keep you from playing the game.'” – “Comme l’a dit Earl Nightingale : ‘Ne laissez pas la peur de rater vous empêcher de jouer.'”

Conclusion

En adoptant une approche positive, en comprenant les besoins individuels et collectifs, en favorisant la collaboration et l’apprentissage continu, les coachs agiles peuvent aider leurs équipes.

J’avais prévenu hein ! Cet article est bien moins travaillé que d’habitude, sans doute très bête et critiquable mais s’il peut vous donner envie de regarder ne serait-ce que le premier épisode de cette belle série, vous ferez de moi un homme heureux !

The post Leçons inspirantes de TED LASSO utiles dans mon coaching agile appeared first on Coach agile.

Bien que les DORA metrics soient couramment utilisées pour mesurer la productivité, il n’est pas toujours facile de les interpréter.

La mesure et l’amélioration de la productivité des développeurs ont longtemps été un défi de taille. Des métriques purement techniques à celles plus orientées business, le choix des métriques reste souvent un sujet préoccupant, surtout qu’il peut finir par des choix totalement obsolètes.

À l’ère de la généralisation des pratiques DevOps, des standards prennent place dans le domaine du développement, et c’est le cas des DORA metrics !

Ces métriques se popularisent et deviennent un refuge pour ceux à la recherche d’une approche de quantification de la productivité. Alors la question devient inévitable : pouvons-nous compter sur les DORA metrics, et comment interpréter et mettre en place ces métriques ?

Qu’est-ce que les DORA metrics ?

Popularisé par le framework SPACE, les DORA (DevOps Research and Assessment) metrics sont un ensemble de métriques clés de performance (Key Performance Indactors – KPI) utilisées pour évaluer et mesurer les pratiques DevOps.

Si les pratiques DevOps sont multiples et méritent à elles seules plus d’un article, ce qu’il faut en retenir c’est avant tout leur capacité à encourager la collaboration entre les développeurs et les équipes opérationnelles. Et c’est ainsi qu’on leur reconnaît une capacité d’amélioration de la vitesse, de la qualité et de la fiabilité des déploiements logiciels.

Pour traduire ces avantages du DevOps, les DORA metrics se concentrent sur quatre dimensions :

• Change Failure Rate

• Deployment Frequency

• Lead Time For Changes

• Time To Restore Service

Une histoire de subtilité et d’interprétation

Bien que les DORA metrics mettent en évidence que les approches simplistes basées sur une seule métrique globale ne suffisent plus, l’interprétation concrète de ces métriques dans les différents contextes reste un sujet de complexité et met en évidence les nuances qui doivent être prises en compte lors de leur utilisation et de leur interprétation.

Ce point m’oblige à m’arrêter afin de vous partager les interprétations que j’ai observées durant ces dernières années pour chacune de ces métriques.

Change Failure Rate :

Le taux d’échec peut être attribué à la fois aux bugs et aux incidents. Par conséquent, il est possible de calculer cette métrique en utilisant l’une ou l’autre de ces définitions, voire en les incluant toutes les deux, c’est-à-dire en prenant en compte à la fois le nombre de bugs et d’incidents.

Cependant, il est important de reconnaître que dans un environnement peu mature en ce qui concerne les processus d’escalade et de déclaration d’incident, la distinction entre ces deux notions peut devenir floue. En d’autres termes, certains incidents peuvent être considérés comme des bugs et vice versa.

Alors le choix de calculer cette métrique sur la notion de bugs versus celle des incidents devient non seulement subtil mais nécessaire à clarifier afin de garantir la fiabilité de la métrique et pouvoir évaluer la réelle maturité des processus.

Deployment Frequency :

La fréquence de déploiement peut englober à la fois les nouvelles fonctionnalités et les correctifs (hot fixes). Tout comme le taux d’échec des changements, cette métrique peut être calculée selon différentes interprétations.

Si l’objectif initial de cette métrique est de suivre la capacité à innover, inclure le nombre de correctifs dans le calcul peut donner une perspective peu claire. En effet, si la fréquence des déploiements reflète principalement une augmentation des correctifs plutôt que des nouvelles fonctionnalités, cela peut indiquer un problème majeur de qualité.

Cependant, l’inclusion du nombre de correctifs peut également démontrer la capacité à résoudre continuellement et de manière proactive les problèmes. Cela met en évidence la capacité de l’équipe à prendre des mesures rapides et à garantir la stabilité et la fiabilité du système.

Lead Time for Changes :

La mesure du délai de mise en œuvre des changements peut englober différentes étapes telles que le temps du cycle (cycle time), le temps de mise en production (release time) et le délai de mise sur le marché (time-to-market – TTM).

Chacune de ces dimensions apporte une perspective différente sur l’efficacité des processus de développement, plus ou moins étendue dans l’organisation.

Le choix de partir, par exemple, sur le TTM peut offrir une vision d’ensemble des délais de mise sur le marché, permettant ainsi de comprendre les éventuels ralentissements dans les processus de production. Cela peut aider à identifier les goulots d’étranglement et à améliorer l’efficacité des opérations.

Cependant, il convient de noter que le TTM peut également être trop large pour cibler des problématiques de productivité précises. En se concentrant uniquement sur cette métrique, il est donc possible de passer à côté d’autres KPIs spécifiques à chaque étape du processus de développement.

Time To Restore Service :

Le temps de résolution peut être mesuré à travers le temps moyen de réparation (Mean Time to Repair) ou le temps moyen de récupération (Mean Time to Recovery). Ces deux notions peuvent prêter à confusion.

Si la première définit une réparation des causes fondamentales ayant produit le problème, la seconde notion s’arrête sur la remise en marche. Cela veut dire une réparation des symptômes et non forcément des causes.

Toute la subtilité réside dans ce point.

Si le Time to Recovery est une traduction unique de la récupération, son efficacité peut ne pas forcément traduire uniquement la réactivité, mais également le nombre de problèmes non traités à la source, et cela peut nous amener à poser la question de l’accumulation de dette technique, des solutions de contournement, etc.

Ces subtilités d’interprétation influencent le calcul et la mise en place des DORA metrics. Bien que ces dernières soient aujourd’hui des standards du marché, leur définition exacte l’est moins.

Cela rend l’exercice complexe et intéressant, car la quête aux chiffres se fait à travers la compréhension du contexte et des besoins.

Relever le défi de compréhension des DORA metrics

Pour une meilleure compréhension de l’environnement, il est souvent intéressant d’examiner les différentes interprétations de ces métriques et de les recalculer pour chaque variation.

Les subtilités peuvent dissimuler des incohérences, mettant ainsi en évidence les difficultés à résoudre. Si l’environnement dispose déjà de ces métriques, cela nécessite de comprendre la logique qui a conduit à faire certains choix et d’être prêt à les remettre en question.

La recherche des métriques dépasse souvent le simple aspect quantitatif, elle est avant tout une réflexion profonde visant à donner du sens à ce qui compte pour votre organisation, en établissant des normes internes qui servent de guide dans une approche mesurable. Il est donc primordial de mener une réflexion approfondie avant de se lancer dans l’action et de généraliser l’utilisation des métriques. Il est également essentiel d’examiner attentivement leur signification et leur pertinence dans un contexte spécifique.

Enfin, cette étape préliminaire de réflexion est d’une importance cruciale, car elle garantit que les métriques sélectionnées sont en adéquation avec les objectifs, permettant de prendre des décisions éclairées et d’engager les équipes vers la bonne direction.

Quelques références pour aller plus loin

• DevEx: What Actually Drives Productivity

• DevOps Research and Assessment (DORA) metrics

• Tracking DORA Metrics Won’t Help You (unless you do this)

• Are you an Elite DevOps performer? Find out with the Four Keys Project

The post DORA metrics : une approche nuancée pour évaluer la productivité appeared first on Coach agile.

Début de l’article

• “Je veux arrêter d’utiliser les story points.”

• “Quoi ?”

• “C’est une blague, non ?”

• “Mais, pouvons-nous vraiment faire ça ?”

• “Mais cela ne va-t-il pas complètement à l’encontre de Scrum ?”

• “C’est vraiment la dernière chose que je m’attendais à entendre de la part d’un Scrum Master !”

Voilà une conversation que j’ai eue récemment avec mon équipe. J’avais passé des mois à leur montrer à quoi servent les story points : vélocité, affinement, prévisions sur un sprint, mais en vain. Ils n’étaient tout simplement pas intéressés.

L’Abandon des Story Points

J’ai donc estimé qu’il était enfin temps d’arrêter de perdre du temps et de se débarrasser complètement des story points. Pourquoi passer du temps sur quelque chose que vous n’utilisez pas ?

L’équipe était sous le choc. Ils ne pouvaient pas imaginer faire du Scrum sans story points. Je suppose qu’ils craignaient aussi qu’un manager vienne leur faire des reproches.

J’ai donc proposé que nous le fassions à titre expérimental : l’essayer pour un Sprint et ensuite se reposer cette question si nécessaire. Mais bien sûr, à la fin du Sprint, tout le monde avait oublié les story points et c’était la fin de l’histoire.

Les Story Points

Au cas où vous ne seriez pas familier avec les story points, je vous recommande de consulter cet article de Maarten Dalmijn. Sa description correspond parfaitement à ma vision des choses :

En termes simples, les story points sont une technique pour faire une estimation relative de l’effort nécessaire pour livrer un élément de travail donné, ou comme nous le disons en Scrum, un élément du Backlog Produit (PBI). En d’autres termes, les story points sont un outil avec un objectif très spécifique. Efficace si vous l’utilisez correctement. Un triste gaspillage de temps sinon.

Une incompréhension de ce fait simple a conduit à beaucoup de négativité envers les story points. Une simple recherche illustre cela : https://medium.com/search?q=story+point. C’est assez malheureux car comme je l’ai dit, si utilisés correctement, les story points peuvent être un outil précieux.

La Valeur des Story Points

Pour moi, les story points sont un moyen très efficace d’apprendre à préparer le travail en le décomposant en morceaux gérables. C’est une compétence inestimable pour les développeurs. C’est le moyen le plus efficace d’obtenir une compréhension claire du travail. Comme le souligne Maarten Dalmijn dans son article, plus un élément de travail est petit, plus le niveau d’incertitude est faible.

Cette compétence a diverses conséquences. Par exemple, elle facilite la planification d’un Sprint, car l’équipe peut estimer plus précisément la quantité de travail qu’elle peut gérer. Cela est important car cela soutient le flux de travail. Fini le stress à la fin du Sprint pour tout terminer !

Cela aide même avec, oserais-je le dire, la planification. Aussi tentant que soit de croire que nous pouvons tous simplement nous plonger dans le travail avec les mots “ce sera fait quand ce sera fait”, ce n’est tout simplement pas réaliste. Même d’un point de vue Agile, il est pratique de pouvoir au moins avoir une idée de ce qui peut être fait quand. Si quelque chose prend des années à construire, même s’il s’agit d’une estimation très approximative, vous y réfléchirez certainement différemment que quelque chose qui prend des jours à livrer.

L’important à accepter ici est que les estimations ne donnent qu’une idée très approximative. J’aime bien dire que nous tentons le globalement juste plus que le précisément faux. Dans ce sens, l’estimation n’est pas un outil de planification, mais un outil de priorisation. C’est une distinction importante. C’est la différence entre un diagramme de Gantt où tout est question de délais et de leur respect, et une feuille de route qui montre dans quel ordre les choses seront livrées. Cela conduit à deux conversations complètement différentes :

“Si cette chose va prendre quelques mois, alors commençons par cette autre chose d’abord, car nous n’avons besoin de la première chose que dans un an ou plus et il y aura suffisamment de marge pour la réaliser à temps.”

au lieu de :

“La date limite pour cette chose est dans 61 jours, mais les progrès indiquent que nous ne pourrons pas respecter la date limite de 22 jours pour pouvoir commencer cette autre chose, donc nous devons commencer à penser aux heures supplémentaires.”

Enfin et surtout, apprendre à préparer leur travail permet à une équipe de collaborer plus facilement. Travailler ensemble sur un seul PBI est un défi, souvent limité à la programmation en binôme, quelque chose à quoi il y a souvent une certaine aversion et qui n’est pas nécessairement efficace. Diviser un PBI en parties plus petites permet à plusieurs développeurs de travailler sur les différentes parties en parallèle, favorisant la concentration et forçant l’alignement continu entre les développeurs. Voilà : un chemin vers une collaboration efficace !

Les Story Points comme Outil d’Apprentissage

Alors, comment les story points aident-ils à apprendre à préparer votre travail ? Eh bien, ils nous donnent un moyen simple de visualiser la taille d’un élément de travail, fournissant la boucle de rétroaction parfaite pour apprendre à décomposer le travail.

Mais, comment est-ce possible, vous pourriez vous demander, considérant que les story points sont relatifs et que personne n’a aucune idée de comment ils se traduisent en temps absolu ? Eh bien, c’est en fait assez facile. Une équipe s’engage à livrer un certain nombre de story points pendant un Sprint. Si elle n’y parvient pas, alors ses estimations étaient trop optimistes. Si elle y parvient et a du temps en plus, alors ses estimations étaient trop conservatrices. Faites cela quelques Sprints et l’équipe commencera automatiquement à développer une sensation pour ce qu’est un story point.

Mais à mon avis, c’est en fait encore plus facile que ça. À la fin d’un Sprint, et surtout s’ils n’ont pas atteint leur engagement, une équipe pointera automatiquement le PBI qui a pris plus de temps que prévu. C’est une question de fierté, le désir naturel d’un développeur d’exceller dans son travail.

Et oui, c’est une intuition, et c’est parfaitement bien. L’essentiel est que c’est l’erreur, et non la précision, qui compte. Plus une équipe est mauvaise en estimation, plus grande sera la marge par laquelle elle ne respectera pas son engagement, et donc plus l’apprentissage sera efficace.

Si vous vous inquiétez de la gravité pour une équipe de manquer à son engagement, réalisez que c’est une façon de penser axée sur les résultats. Le succès du Sprint est déterminé par un résultat : atteindre l’objectif du Sprint, et non une quantité de travail spécifique. Se concentrer sur l’objectif rend automatiquement la portée flexible, donnant à l’équipe beaucoup de marge pour apprendre cette compétence utile.

Les Story Points ne sont pas une question de justesse, mais d’apprentissage. Et c’est génial parce que cela signifie que nous n’avons pas besoin de prendre tout cela trop au sérieux ! Qui se soucie de savoir si c’est un 3 ou un 5 ? Des discussions sans fin pour parvenir à un consensus ? La vraie conversation a lieu après, quand nous parlons de savoir si nous avons atteint notre engagement ou non.

Sachant que l’apprentissage se fait le mieux lorsque nous le gamifions, cela devient soudainement une opportunité. Moi-même, je ne fais plus jamais de sessions de poker, je fais de l’estimation avec de l’extrem quotation. Ce jeu est simple : mettez en place une table avec la séquence de Fibonacci dans la ligne de titre, et demandez à l’équipe de déplacer individuellement les PBIs vers la colonne qu’ils pensent être juste. Dites quelque chose de stupide comme “celui qui déplace le plus d’éléments gagne un prix” pour bien montrer que c’est un jeu. Assurez-vous simplement que les gens s’amusent. Si vous avez une équipe qui s’inquiète de la fiabilité des estimations, dites-leur qu’ils pourront discuter des estimations avec lesquelles ils ne sont pas d’accord après le jeu.

Ce que vous obtiendrez, c’est une estimation éclair où tout le monde participe. J’ai eu des équipes qui estimaient 40 éléments en 10 à 20 minutes. Et cela inclut les discussions après.

Conclusion

Voilà donc la vraie valeur des Story Points. Un outil simple qui repose sur l’intuition et l’instinct de votre équipe. Juste sur cette base et la boucle de rétroaction que le Sprint fournit, les équipes apprennent progressivement à décomposer leurs histoires en moins de 5 story points chacune.

Et une fois que vous arrivez à ce point – 1, 2 ou 3 story points – l’apprentissage est terminé et vous pouvez vous débarrasser des story points et de l’engagement. Vous voyez, vous avez résolu la seule hypothèse de la loi de Little qui rend son utilisation avec Scrum si difficile, à savoir que tous les PBIs devraient avoir des tailles similaires. Félicitations, vous pouvez maintenant commencer à utiliser les métriques Kanban pour faire tout ce travail d’estimation : Cycle Times, Lead Times et Service Level Expectations (SLEs).

Mais attendez, ça devient encore mieux que ça. La beauté est que cette nouvelle compétence que les développeurs ont apprise signifie non seulement qu’ils peuvent décomposer le travail de manière fiable, mais aussi qu’ils seront capables d’estimer n’importe quoi pour vous !

J’ai eu des équipes où le Product Owner demandait simplement combien de temps prendrait une certaine fonctionnalité, voire un projet entier, et l’équipe donnait tout aussi simplement une estimation en Sprints. La clé est une règle simple sur laquelle nous devons tous nous mettre d’accord :

“Plus l’élément à estimer est grand, plus la marge d’erreur est grande”

Le résultat est que ces équipes ne font plus de ‘raffinements classiques’, elles font des sessions de brainstorming dans lesquelles elles décomposent le travail et vous donnent ensuite une estimation encore meilleure.

Qui l’aurait cru, les Story Points sont un outil utile et amusant, que vous pouvez mieux mettre en place comme un jeu, et qui est motivé par la propre motivation de l’équipe à ‘gagner’ : que ce soit pour atteindre leur engagement, leur objectif de Sprint, ou tout ce qui titille leur ego.

Et imaginez juste ce moment où vous dites à votre équipe :

“Félicitations les gars, vous n’avez plus besoin de Story Points, d’Engagement ou de Vélocité. Vous êtes tellement cool que vous faites ce que beaucoup de gens pensent être impossible !”

The post Nouvelle Perspective sur les Story Points appeared first on Coach agile.