​Salut Reader,​

Ton manager t'a peut-être jamais posé cette question à voix haute. Mais il l'a pensée.

"T'as stoppé un bug non priorisé au daily. Un dev attentif aurait fait pareil, non ?"

Le truc c'est qu'il a pas tort. Stopper le bug, c'est de la mécanique. Ce que t'as fait après, c'est autre chose.

Concrètement, ça ressemble à quoi ?

Ce matin, au daily un dev mentionne qu'il travaille sur un bug. Quelqu'un hors de l'équipe lui a écrit directement et bypass la priorisation pour aller plus vite. Le dev a dit oui parce qu'il voulait rendre service. C'est réactif, humain, quoi.

Mais t'avais l'oreille attentive et t'as stoppé, validé la priorisation entre le dev et le PO en 10min. Finalement, c'est pas critique, le sprint est intact. Good job !

Jusque là, oui, n'importe quel dev attentif pouvait faire ça. Un bon "ticket manager" aussi.

Ce qui se passe dans l'heure qui suit, par contre ça, c'est ton boulot :

Tu vas voir le dev, PAS pour lui faire la leçon, mais pour valider si il connaît l'impact :

"Tu sais combien ça coûte à l'équipe quand quelqu'un bypass la priorisation, même avec les meilleures intentions ?"

Vous calculez ensemble. Une interruption non planifiée en cours de sprint, c'est genre une demi-journée perdue entre le context switching et le rattrapage. Sur une équipe de 5, si ça arrive 4 fois par sprint, t'as 4 jours de capacité qui partent en fumée. Sans apparaître nulle part dans les chiffres. Dans le vide...

Le dev n'avait pas fait le lien. Maintenant si.

Au daily suivant, tu partages l'observation à l'équipe (pas le nom, pas l'incident, juste le chiffre et l'impact). Et tu proposes un sujet pour la prochaine retro : comment on gère les demandes externes qui arrivent directement sur les devs ?

L'équipe décide du process. Pas toi.

C'est ça le coaching. T'as pas résolu le problème à leur place. T'as créé la condition pour qu'ils le résolvent eux-mêmes.

Ce que tu mesures maintenant : les interruptions non planifiées par sprint.

Ce sprint, t'en avais 4. Dans 6 semaines, tu veux savoir si c'est descendu.

C'est ça que tu rapportes à ton manager. L'évolution sur 3 sprints. Pas le bug de ce matin. Par exemple :

"Ce sprint, j'ai compté 4 interruptions non planifiées sur l'équipe, des demandes externes qui bypassaient la priorisation. J'ai coaché les devs sur l'impact business de ces interruptions, on a ouvert le sujet en rétro, l'équipe a défini son propre process de filtre. Je mesure les interruptions par sprint. Dans 6 semaines je te montre où on en est."

Encore un truc : si ton équipe est là depuis 2 ans et qu'elle gère pas encore ça seule, c'est un autre problème. On en reparlera. Ici on parle d'une équipe qui apprend encore à se protéger...

Ton expérimentation 48h :

Compte les interruptions non planifiées de ce sprint. Pas besoin de process encore. La mesure, c'est ton point de départ.

Vous êtes à combien ?