# Collaboration Solved > Les rôles agile disparaissent en silence. Chaque semaine, un outil concret pour construire tes preuves de Scrum Master. Commence par le SM Survival Score, gratuit. Public Ghost content for AI and LLM tooling. This file includes a bounded export of public pages first, then recent public posts. Append `.md` to any post or page URL to get the content in Markdown (for example, `/example-post.md`). ## Pages ### BIS4 : Des événements Scrum qui montrent ton impact. URL: https://collaborationsolved.com/bis4-methode-scrum-master/ Last updated: 2026-08-24T01:17:37.000Z ## Tes réunions Scrum ne servent à rien ? Ta crédibilité en paie le prix. Chaque réunion qui ne produit rien renforce l'idée que ton rôle est un luxe. Ce guide te montre comment renverser ça. [Acheter sur LeanPub](https://leanpub.com/BIS4?ref=collaborationsolved.com) ### Renverser le point de vue. Ton Daily ressemble à un tour de table que personne n'écoute. Ta Rétro produit des post-its que personne ne relit. Ton Planning finit en négociation de story points. Ta Review ? Ton boss n'y vient même plus. Et le problème, c'est que chaque réunion ratée confirme exactement ce qu'on pense déjà de toi : "Le Scrum Master, c'est l'animateur de meetings." > Personne ne t'a filé un cadre simple pour que tes réunions produisent quelque chose de montrable (quelque chose que ton manager remarque). ### Tes réunions sont ta plus grosse source de preuves inexploitée. Pas pour "mieux faciliter." Pour montrer que tu sers à quelque chose. - Une rétro qui identifie un vrai blocage et le résout en une semaine (c'est une preuve). - Un daily qui expose un risque avant qu'il explose (c'est une preuve). - Un planning qui donne une date fiable au management (c'est une preuve). > Le format de tes réunions n'a jamais été le problème. > Ce qui manque, c'est le résultat à montrer à la fin. --- ![](https://storage.ghost.io/c/69/5a/695addfe-1c1d-4828-b10c-8f9c23732c07/content/images/2026/05/bis4-book--2-.jpg) Ce guide te donne une méthode simple pour que chaque réunion d'équipe produise un résultat que tu peux montrer : - **Un but clair :** tu sais pourquoi tu réunis les gens, et eux aussi. - **Les bons ingrédients :** contexte, règles, visuel, résultat attendu. Tout est posé avant de commencer. - **Une séquence qui tient :** tu sais quoi faire à chaque étape, dans l'ordre. - **Un résultat montrable :** ta réunion finit avec quelque chose que tu peux envoyer à ton boss. Testé avec des vraies équipes. Utilisable dès ta prochaine réunion. Le guide fait 50 pages, dispo en format ePUB, PDF et Kindle. Des exemples réels, des grilles d'auto-évaluation, des anecdotes d'équipes pour que tu voies comment appliquer ça dans ton contexte, pas dans un monde idéal. Satisfait ou remboursé (et tu gardes le livre). **Chapitre gratuit plus bas.** [Acheter sur Amazon](https://a.co/d/0bwX7au9?ref=collaborationsolved.com) ![](https://storage.ghost.io/c/69/5a/695addfe-1c1d-4828-b10c-8f9c23732c07/content/images/2026/05/Screenshot_attente.png) ![](https://storage.ghost.io/c/69/5a/695addfe-1c1d-4828-b10c-8f9c23732c07/content/images/2026/05/Screenshot_lecteur.png) ![](https://storage.ghost.io/c/69/5a/695addfe-1c1d-4828-b10c-8f9c23732c07/content/images/2026/05/Screenshot_retro.png) ![](https://storage.ghost.io/c/69/5a/695addfe-1c1d-4828-b10c-8f9c23732c07/content/images/2026/05/Screenshot_toc.png) ![](https://storage.ghost.io/c/69/5a/695addfe-1c1d-4828-b10c-8f9c23732c07/content/images/2026/05/Screenshot_grille.png) > Je ne t'écris pas ça depuis une tour d'ivoire. > > J'ai animé des centaines de réunions d'équipe. Certaines brillantes, beaucoup ratées. Ce guide, je l'ai construit en accompagnant des équipes au quotidien. En testant, en me plantant, en ajustant. > > Est-ce que ça marche à tous les coups ? Non. > Une culture toxique ou un backlog vide, ça ne se répare pas avec ce guide. > > Mais si ton équipe veut avancer et que tu veux montrer que c'est grâce à toi, c'est un bon point de départ. > > Pierre-Cyril (mais tu peux m'appeler PC) ### Télécharge un chapitre gratuit. [Télecharger l'extrait du livre BIS4 (par Pierre-Cyril Denant)EXTRAIT DU LIVRE (CHAPITRE 1 SUR 5) - Le Daily ScrumFree Sample- Méthode BIS4 v3.1.pdf829 KBdownload-circle](https://collaborationsolved.com/content/files/2026/05/Free-Sample--M--thode-BIS4-v3.1.pdf "Download") Pas prêt à acheter ?[ ​**Clique ici pour faire le SM Survival Score, c'est gratuit.**](https://sm-score.collaborationsolved.com/?ref=collaborationsolved.com) --- #### ****C'est pour qui, ce guide ?** D'abord pour les Scrum Masters : nouvelle équipe, bilan à mi-parcours, ou réunions qui tournent à vide. Utile aussi pour les managers qui veulent évaluer l'efficacité de leurs réunions avec des critères concrets, et pour les équipes qui veulent tenir leurs événements seules quand le facilitateur n'est pas là. #### ****Combien de temps ça prend à lire et à appliquer ?** 50 pages. Testé avec des vraies équipes, pas en théorie. Tu peux appliquer le premier outil dès ta prochaine réunion, pas besoin de finir le livre avant de commencer. #### ****Quels formats sont disponibles ?** ePUB, PDF et Kindle, sur Leanpub et Amazon. #### ****Et si ça ne marche pas pour moi ?** Satisfait ou remboursé, et tu gardes le livre. #### ****Je peux essayer avant d'acheter ?** Oui. Le premier chapitre, sur le Daily, est téléchargeable gratuitement plus haut sur cette page. ### Ton rôle est en danger. Tu ne sais pas encore où. URL: https://collaborationsolved.com/scrum-master-survival-score/ Last updated: 2026-09-13T23:46:57.000Z ## SM Survival Score Diagnostic des zones où le rôle de Scrum Master est le plus vulnérable. [20 questions, 5 min, gratuit →](https://sm-score.collaborationsolved.com/?ref=collaborationsolved.com) Capital One a éliminé plus de 1 100 postes dans la famille agile. ScrumAlliance rapporte que seulement 18 % des organisations maintiennent encore un poste d'agile coach dédié. La majorité du reste a éliminé ou absorbé le rôle. Ce n'est pas une crise du marché. C'est une crise de visibilité. Les Scrum Masters qui ont été coupés n'étaient pas mauvais. Ils étaient invisibles. [Voir mes angles morts → ](https://sm-score.collaborationsolved.com/?ref=collaborationsolved.com) ## **Le SM Survival Score, c'est quoi ?** Un diagnostic de 20 questions. Gratuit. En français. Il mesure cinq dimensions où les Scrum Masters deviennent vulnérables sans s'en rendre compte : - Ta valeur est-elle visible pour ton management ? - Tes réunions produisent-elles des résultats mesurables ? - Ton équipe peut-elle fonctionner sans toi sur les sujets clés ? - Sais-tu lire le silence de ton équipe ? - Est-ce que tu te différencies des outils IA qui font partie de ton quotidien ? À la fin, tu reçois un score sur 100, un diagnostic par dimension, et les angles morts à corriger en premier. ![](https://storage.ghost.io/c/69/5a/695addfe-1c1d-4828-b10c-8f9c23732c07/content/images/2026/08/cartescore.png) ![](https://storage.ghost.io/c/69/5a/695addfe-1c1d-4828-b10c-8f9c23732c07/content/images/2026/08/resultdimensions.png) ![](https://storage.ghost.io/c/69/5a/695addfe-1c1d-4828-b10c-8f9c23732c07/content/images/2026/08/prioritydiag.png) ![](https://storage.ghost.io/c/69/5a/695addfe-1c1d-4828-b10c-8f9c23732c07/content/images/2026/08/dimensions.png) Captures du SM Survival Score [Fais ton diagnostic gratuit → ](https://sm-score.collaborationsolved.com/?ref=collaborationsolved.com) ### **Ce n'est pas un test de certification.** Il n'y a pas de bonne réponse. Pas de badge à la fin. Juste un diagnostic honnête de là où tu es fragile, pour que tu puisses agir avant que ce soit ton manager qui l'identifie à ta place. A+ Pierre-Cyril (mais tu peux m'appeler PC). --- #### ****C'est quoi le SM Survival Score ?** Un diagnostic gratuit de 20 questions, en français. Il mesure cinq dimensions où les Scrum Masters deviennent vulnérables sans s'en rendre compte : visibilité auprès du management, résultats mesurables de tes réunions, dépendance de l'équipe envers toi, lecture du silence d'équipe, et ta différenciation face aux outils IA. Tu repars avec ton score et un diagnostic honnête, sans certification ni badge. #### ****Le poste de Scrum Master est vraiment menacé ?** Capital One a éliminé plus de 1 100 postes dans la famille agile. ScrumAlliance rapporte que seulement 18 % des organisations maintiennent encore un poste d'agile coach dédié. Les SM coupés n'étaient pas mauvais. Ils étaient invisibles. #### ****C'est quoi BIS4 ?** Une méthode pour que chaque réunion Scrum (Daily, Rétro, Planning, Review) produise un résultat montrable. Livre de 50 pages, dispo sur Leanpub et Amazon, avec un chapitre gratuit. [Voir la page BIS4](https://collaborationsolved.com/bis4-methode-scrum-master/). #### ****Le Survival Score, il y a un piège ? Faut payer pour voir le résultat** Non. C'est gratuit, ça prend 5 minutes, et tu as ton score et ton diagnostic par dimension tout de suite. Pas de carte de crédit demandée. #### ****T'as pas de baseline pour prouver ton impact, c'est mort ?** Non. Tu peux commencer à mesurer même sans point de départ officiel. La question à te poser : sur quoi ton équipe est jugée, coût, qualité, volume ou vitesse. [Le détail de la méthode ici](https://collaborationsolved.com/tas-pas-de-baseline-tu-peux-quand-meme-mesurer/). ### A propos URL: https://collaborationsolved.com/a-propos/ Last updated: 2026-08-31T00:36:42.000Z Si tu es Scrum Master depuis quelques années, tu t'es déjà posée, cette question : > Qui sera sur la liste, si jamais on coupe des postes ? Moi, j'ai eu la réponse... Le Scrum Master le plus facile à couper dans une réorg, c'était moi. Mars 2020, à Montréal. Sur un appel Zoom avec les RH, le manager, et le directeur, on m'a dit : "Pas assez performant." Pendant que la mise à pied tombait sur mon équipe et sur moi, mes collègues s'échangeaient leurs numéros personnels sur Slack pour rester en contact. Un mois plus tard, invité sur un podcast, j'ai parlé 40 minutes de mon métier. Facilitation, confiance, rétros. Zéro mention du licenciement. Zéro chiffre, zéro avant/après... Je décrivais exactement le pattern qui m'avait coûté mon job, et je le voyais pas... ## Pourquoi le rôle de Scrum Master est le plus facile à couper [](https://github.com/pcdenant/collaboration-solved/blob/main/07-positionnement-branding/brief-page-a-propos-2026-08.md?ref=collaborationsolved.com#pourquoi-le-r%C3%B4le-de-scrum-master-est-le-plus-facile-%C3%A0-couper) Mon travail était réel. L'équipe livrait, le client était content, mon manager savait que je faisais du bon boulot "en général". Mais quand est venu le moment de choisir qui garder, personne n'avait de matière. Pas de mauvaise volonté, juste rien sur la table. Facilitation, formation, rétros, communautés de pratique : des mots sans unité de mesure. Ce qui n'a pas de trace n'entre pas dans le calcul. C'est comme jouer à World of Warcraft sans les points d'expérience. Tu montes en niveau pour de vrai, ta guilde le sent, mais rien ne s'affiche à l'écran. Le jour où quelqu'un doit choisir qui peut aller dans le dernier donjon et qui reste sur le carreau, toi t'as juste ton nombre d'heures à montrer. Depuis, c'est arrivé à d'autres. Capital One a coupé 1 100 postes agile en 2023\. ScrumAlliance recense 18% des Scrum Masters touchés par des licenciements liés à l'agilité entre 2022 et 2024\. Et maintenant, des "Scrum Master AI" se vendent par abonnement. La menace a changé de forme, mais le problème de fond, lui, n'a pas bougé : si la seule chose visible dans ta colonne c'est "facilite les meetings", le calcul se fait tout seul. T'es trop cher pour ce que tu rapportes. ## Qui je suis ![](https://storage.ghost.io/c/69/5a/695addfe-1c1d-4828-b10c-8f9c23732c07/content/images/2026/08/pcID_square-2-1.png) [](https://github.com/pcdenant/collaboration-solved/blob/main/07-positionnement-branding/brief-page-a-propos-2026-08.md?ref=collaborationsolved.com#qui-je-suis) Je suis Pierre-Cyril Denant, (tout le monde m'appelles PC). Scrum Master à Montréal depuis 2017, je passe mes journées à aider des gens compétents à arrêter d'être invisibles. En 2023, j'ai fondé Collaboration Solved pour en faire plus qu'un métier à temps plein. En construisant les outils qui rendent leur impact montrable, même quand je ne suis pas dans la pièce. Un bon coach agile se rend inutile. Si l'équipe ne peut pas fonctionner sans toi, t'as pas coaché, t'as créé une dépendance. **Collaboration Solved**, c'est ça : des preuves, pas des promesses. Un outil gratuit ([SM Survival Score](https://collaborationsolved.com/scrum-master-survival-score/)) pour diagnostiquer ton angle mort en 5 minutes. Une newsletter chaque semaine avec une tactique concrète. Des conférences où je raconte cette histoire sans l'édulcorer, parce que le seul moyen de la rendre utile aux autres, c'est de la dire telle qu'elle a été vécue. ## Mon parcours [](https://github.com/pcdenant/collaboration-solved/blob/main/07-positionnement-branding/brief-page-a-propos-2026-08.md?ref=collaborationsolved.com#mon-parcours) Avant l'agilité, j'ai été infographiste à Paris pendant une dizaine d'années. J'étais pas un super graphiste. J'étais un bon technicien, mais j'ai appris que je préfère organiser le travail collectif que l'exécuter seul. Arrivé à Montréal en 2010, j'ai rejoint une coopérative audiovisuelle. Une structure qui mettait déjà les gens au centre des décisions, sans jamais utiliser le mot "agile". C'est en 2015 qu'en lisant la documentation Jira j'ai découvert que ce que je pratiquais avait un nom : Scrum Master. Oui, ça s'est fait comme ça. Et j'ai sauté à pieds joints dans la piscine de Kool-Aid... Puis en mars 2020 c'est la mise à pied. Reconstruction, puis l'envie d'en parler : Collaboration Solved. Aujourd'hui, je suis Coach Agile. J'ai raconté cette histoire pour [Agile Montréal ](https://agilemontreal.ca/evenement/13mai/?ref=collaborationsolved.com)(mai 2026), co-animé un atelier sur la pensée scientifique à l'Agile Tour Montréal 2024, et j'en ai parlé aux podcasts [Agile Enablers](https://www.youtube.com/watch?v=iiCmUJKMHac&ref=collaborationsolved.com) (2020) et [Le Sprinkler](https://youtu.be/l1jsZWkxRlU?si=XfUWI9pFl7HZRBz2&ref=collaborationsolved.com) (2023). Entre-temps, j'ai écrit [BIS4](https://collaborationsolved.com/bis4-methode-scrum-master/), un framework de design de réunions, parce que les réunions sont des produits, pas des rituels. ## Ce que je crois [](https://github.com/pcdenant/collaboration-solved/blob/main/07-positionnement-branding/brief-page-a-propos-2026-08.md?ref=collaborationsolved.com#ce-que-je-crois) Les organisations récompensent la visibilité, et l'impact. Si tu ne mesures pas le fruit de ton travail, quelqu'un d'autre le mesurera à ta place (et problement mal, avec des story points)... Je joue pas la victime. Le système qui rend le travail du SM invisible, c'est un angle mort, pas une conspiration. Mais c'est toi qui paies le prix si tu n'y fais rien. Si ta direction te demandait demain matin c'est quoi ton impact ce trimestre, en chiffres, t'aurais une réponse prête ? Si t'hésites, commence ici. [![CTA Image](https://storage.ghost.io/c/69/5a/695addfe-1c1d-4828-b10c-8f9c23732c07/content/images/2026/08/smsurscore.jpg)](https://sm-score.collaborationsolved.com/?ref=a-propos) [Fais le test (5 min) → ](https://sm-score.collaborationsolved.com/?ref=a-propos) ### Ressources pour Scrum Masters URL: https://collaborationsolved.com/ressources/ Last updated: 2026-08-26T00:54:19.000Z Ce que j'utilise, ce qui m'a aidé, ce que je partage avec mes clients. Pas un catalogue : ce que je filtrerais pour toi si tu me le demandais en 1-1. GRATUIT - trello [![CTA Image](https://storage.ghost.io/c/69/5a/695addfe-1c1d-4828-b10c-8f9c23732c07/content/images/2026/08/toolboxtrello.png)](https://trello.com/b/qBQIU1ry/ultimate-agile-toolbox-for-coaches-scrum-masters?ref=collaborationsolved.com) ****Toolbox ultime du Scrum Master** Une collection de ressources sur Trello construite au fil des années : templates, références, liens utiles. Le point de départ que j'aurais voulu avoir quand j'ai commencé. [Accèdes à la toolbox → ](https://trello.com/b/qBQIU1ry/ultimate-agile-toolbox-for-coaches-scrum-masters?ref=collaborationsolved.com) GRATUIT - youtube [![CTA Image](https://storage.ghost.io/c/69/5a/695addfe-1c1d-4828-b10c-8f9c23732c07/content/images/2026/08/youtube-channel.png)](https://www.youtube.com/@collaboration-solved?ref=collaborationsolved.com) ****Podcast "Collaboration Solved"** Des dizaines d'épisodes sur la facilitation, le coaching d'équipe, et ce qui se passe vraiment dans les équipes quand ça coince. Des sujets que je reviens encore consulter. [Écoute les épisodes → ](https://www.youtube.com/@collaboration-solved?ref=collaborationsolved.com) 9.99$ - ebook pdf + kindle [![CTA Image](https://storage.ghost.io/c/69/5a/695addfe-1c1d-4828-b10c-8f9c23732c07/content/images/2026/08/bis4-book--1-.jpg)](https://collaborationsolved.com/bis4-methode-scrum-master/) ****Livre BIS4 - Des événements Scrum qui montrent ton impact** Ce que j'utilise pour rendre les réunions actionnables : Buts, Ingrédients, Séquence, et 4 composantes visibles. Ça marche aussi bien pour un daily qui traîne que pour un PI Planning de deux jours. [Chapitre gratuit → ](https://collaborationsolved.com/bis4-methode-scrum-master/) ## Posts ### Ton équipe a appris quoi, exactement ? URL: https://collaborationsolved.com/equipe-autonome-nommer-ce-quelle-a-appris/ Last updated: 2026-09-14T11:07:45.000Z > Tu veux savoir si un Scrum Master fait bien son travail ? Demande à son équipe. Elle le sait, elle. C'était ma réponse pendant des années et c'était une connerie. Une équipe qui n'a jamais regardé ses résultats ne peut pas te dire si tu l'as aidée. Elle n'a pas de "avant". Elle n'a que le aujourd'hui, et pour elle (ou ton manager), ça a toujours été comme ça. L'autre jour, j'assistais à un atelier animé par la Scrum Master d'une équipe. Ce SM fait déjà [l'email du vendredi](https://collaborationsolved.com/email-vendredi-scrum-master-prouver-impact/) à ses managers, son travail remonte. Ce qui manquait, c'était l'autre côté. Et c'est sorti tout seul, dans la bouche d'un dev sans que personne le demande. > *Avant, une carte finissait le développement et elle attendait 5 ou 6 jours avant le code review. Là, c'est 1 à 3 jours.* Tout le monde a hoché la tête (la SM aussi). Elle ne l'avait jamais écrit comme ça. En creusant : le dev allait voir les cartes qui traînaient. La SM observait ces temps depuis des mois et en parlait. C'est ça qui a produit l'habitude ? Probablement. Plus personne ne peut le prouver... ## Ton équipe ne se voit pas grandir La semaine dernière, je t'ai demandé de [compter les sujets de tes rétros](https://collaborationsolved.com/retrospective-sans-suivi-actions/). Ceux qui ont disparu après une action livrée sont ta matière première. 9 fois sur 10, ça devient "l'équipe est plus autonome". Personne ne peut le contredire, personne ne peut le croire et ça finit par [ressembler à ton absence.](https://collaborationsolved.com/paradoxe-autonomie-scrum-master/) Tu te rappelles le cadre de porte chez tes parents ? Le trait de crayon au dessus de la tête, la date, et ton prénom ? Peut-être que tu le fais aussi avec tes enfants... L'enfant ne se voit pas grandir. Avec ça on peut lui montrer son évolution et aussi le montrer à quelqu'un qui n'était pas là. Genre la grand-mère qui arrive à Noël et qui voit d'un coup ce qu'elle n'a pas vu se produire. ## La phrase en trois temps Situation : \[le déclencheur\] Avant : \[ce que l'équipe faisait\] Aujourd'hui : \[ce qu'elle fait\] Date : ... Deux règles. La deuxième va peut-être te déranger. - **Le déclencheur doit être le même des deux côtés (avant et après).** Si tu ne sais pas nommer 2 fois la même situation, tu décris un état, pas un changement. - **Ton nom n'apparaît pas dans la ligne "Aujourd'hui".** L'email du vendredi, c'est le format où tu es le sujet. Celui-là, c'est l'inverse. Si tu es dans la phrase, ce n'est pas un apprentissage, c'est une dépendance envers toi. ### Ce que ça donne rempli Situation : une carte finit le développement et attend le code review. Avant : elle attendait 5 à 6 jours. Aujourd'hui : elle attend 1 à 3 jours, les devs vont voir celles qui traînent. Date : 12 septembre Tu lis les 3 lignes à ton équipe et pose une seule question : > C'est bien ça qui s'est passé ? Tu leur demandent pas de t'évaluer, tu trace juste les deux traits sur le cadre de porte. ### Ton expérimentation cette semaine Prends une ligne de [ton comptage,](https://collaborationsolved.com/retrospective-sans-suivi-actions/) écris-la en 3 temps, pose la question avant vendredi. Il y a des choses que ton équipe n'apprendra jamais, quoi que tu écrives. Pas parce qu'elle en est incapable mais car ce qui bloque n'est pas chez elle... Et toi, la dernière fois que ton équipe a nommé un progrès toute seule, tu étais dans la pièce ? ![](https://storage.ghost.io/c/69/5a/695addfe-1c1d-4828-b10c-8f9c23732c07/content/images/2026/08/signpc-1.png) [SM Survival Score : Quels sont tes angles morts ?](https://sm-score.collaborationsolved.com/?ref=collaborationsolved.com) ### 6 rétros plus tard rien ne change vraiment. URL: https://collaborationsolved.com/retrospective-sans-suivi-actions/ Last updated: 2026-09-07T11:02:00.000Z Ta rétro peut très bien se passer toutes les 2 semaines et ne rien changer du tout. J'ai mis des années à le voir, c'est un ancien dev de mon équipe qui me l'a mis sous le nez sans le savoir. On se croise en bas de chez moi, longtemps après. On s'était perdu de vue, il avait changé de boîte entre-temps. La première chose qu'il me sort : > "Ah PC, ça fait longtemps ! Je me rappelle de tes rétros, c'était vraiment le fun. On savait jamais à quoi s'attendre." Avant, j'aurais pris ça comme un compliment. Mais là, ça m'a mis la puce à l'oreille... Parce que le *"on savait jamais à quoi s'attendre"*, c'est moi qui l'avais cultivé. Une mécanique commune, mais un thème différent, un exercice différent, à chaque rétro (mon cerveau TDAH adore la nouveauté). Et surtout la seule trace qu'il restait : *"c'était le fun"*. Une rétro, c'est censé produire quoi, au juste ? Une impression de fun ? Dans Retour vers le futur, Marty change un truc en 1955, puis passe le reste du film à ressortir la photo de sa poche pour vérifier. Sans cette photo, y'a aucun moyen de savoir si son intervention a changé quelque chose. Ta rétro, c'est un voyage dans le passé. On changes un truc, mais personne ne regarde jamais la photo. ## Le test des sujets (pas des actions) Rouvre tes 6 dernières rétros. Liste pas les actions décidées mais les sujets. | Sujet | Revenu x fois | Action livrée depuis ? | | ------------------- | -------------- | ---------------------- | | Bugs en prod | 4 rétros sur 6 | Non | | Dépendance équipe Z | 2 sur 6 | Oui, sprint 14 | | | | | Ce que tu cherches, c'est si le sujet revient pas l'action. Un "action item" qui n'a pas marché et qu'on reprend autrement, c'est de l'itération, c'est ok. L'équipe à le droit de pas trouver la bonne solution du premier coup. Ce qui parle, c'est le croisement des deux colonnes : - **Le sujet revient, aucune action livrée.** T'en parles, ça retombe, ça revient. Ton système ne bouge pas, et la rétro non plus. - **Le sujet revient, des actions livrées à chaque fois.** Ton équipe cherche encore, mais elle cherche pour vrai. Laisse le temps faire. - **Le sujet a disparu après une action livrée.** Ça, c'est ta photo. La preuve que ta rétro produit quelque chose de mesurable, et la seule chose que ton manager va comprendre sans contexte. ### Ton expérimentation 48h Seul, avant ta prochaine rétro. Pas besoin d'annonce à l'équipe. Prends les 6 dernières rétros, la liste des sujets, deux colonnes. 30 minutes max. Si ton PO a arrêté de venir, [c'est un autre problème, et tu sais déjà quoi faire](https://collaborationsolved.com/retrospective-desertee-scrum-master-quoi-faire/). Si c'est la durée qui dérape, [la grille existe déjà](https://collaborationsolved.com/daily-scrum-trop-long-45-minutes/). Ici, tout le monde vient, tout se passe bien, et c'est exactement pour ça que personne ne regarde d'assez près. Ton équipe a peut-être beaucoup appris cette année. Tu ne pourras jamais le raconter si tu ne l'as pas compté. Quel sujet revient dans tes 6 dernières, sans qu'une seule action ait été livrée ? ![](https://storage.ghost.io/c/69/5a/695addfe-1c1d-4828-b10c-8f9c23732c07/content/images/2026/08/signpc-1.png) [SM Survival Score : Quels sont tes angles morts ?](https://sm-score.collaborationsolved.com/?ref=collaborationsolved.com) ### Ta réorg n'est pas une crise, c'est juste un lundi. URL: https://collaborationsolved.com/reorg-scrum-master-lundi/ Last updated: 2026-08-31T11:03:12.000Z Un lundi matin, ton manager t'annonce que tu changes d'équipe. C'est effectif immédiatement. Personne ne t'a demandé ton avis, personne ne t'a prévenu la semaine d'avant. Tu l'apprends en même temps que tout le monde, et tu dois avoir l'air de gérer ça devant l'équipe que tu quittes dans l'heure qui suit. Une réorganisation d'équipe, c'est traité comme une crise dans à peu près toutes les têtes de Scrum Master que je connais. Panique, sentiment d'injustice, sensation d'avoir perdu le contrôle. Sauf qu'une réorg n'est pas un événement rare qu'on subit une fois dans une carrière. C'est comme la météo, ça va et ça revient. La vraie question n'est pas "comment je survis à celle-ci?", c'est "qu'est-ce que je prépare avant qu'elle arrive?" ## C'est quoi une réorganisation quand t'es Scrum Master ? Une réorganisation, dans le contexte d'un Scrum Master, c'est un changement de rattachement décidé au-dessus de toi (nouvelle équipe, nouveau département, parfois nouveau rôle) sans que ta participation ait été demandée AVANT que la décision soit prise. Ce n'est pas la même chose qu'un licenciement, et ce n'est pas non plus une rotation planifiée à laquelle tu t'attendais. C'est un mouvement imposé, généralement annoncé le jour même où il devient effectif. Je vois ça comme un événement récurrent et normal du métier de Scrum Master, pas comme une anomalie. C'est cette bascule de posture qui change tout. Je t'explique. ## Pourquoi une réorg fait paniquer tout le monde d'un coup Si l'industrie traite une réorg comme une crise, alors la réaction naturelle de tout le monde dans la pièce est de se mettre en mode défensif au même moment (le fameux Fight, Flight, Freeze). Résultat : personne n'arrive à penser clairement dans les premières heures, et c'est précisément le moment où ça compterait le plus. C'est prévisible, presque mécanique. Une annonce sans préavis coupe le temps de préparation à zéro. Ton cerveau qui n'a pas eu le temps de digérer une information passe en réaction plutôt qu'en analyse. Ça vaut pour toi, pour ton équipe, et aussi pour le manager qui a dû livrer la nouvelle, souvent aussi peu préparé que toi à la gérer humainement. Heidi Helfand (Dynamic Reteaming) documente ça comme un des 5 grands patterns de changement d'équipe : les gens bougent d'une équipe à l'autre en continu dans une organisation vivante. C'est le fonctionnement normal du système, pas un accident. ## Ce qu'une réorg vient chercher chez toi précisément ### Quand t'es encore en train de construire ta crédibilité Si t'es un Scrum Master mid-career (3 à 5 ans, dans une grande organisation, encore en train d'apprendre à traduire ton travail en langage business), une réorg te frappe à l'endroit précis où t'es le plus vulnérable : tu n'as pas encore de dossier assez épais pour qu'on se batte pour te garder. Tu recommences une relation de confiance à zéro, avec un nouveau manager qui ne sait rien de ce que t'as déjà prouvé ailleurs. ### Quand tes preuves d'impact sont presque prêtes, mais pas encore exposées Le cas le plus cruel, et je l'ai vu revenir plus d'une fois en coaching : un Scrum Master finit justement de mettre ses preuves ensemble (un changement de découpage qui a débloqué l'équipe, une donnée qui montre l'impact) au moment exact où la réorg tombe. Il n'a pas eu le temps de le formaliser dans une évaluation, une conversation, un dossier. La preuve existe. Elle n'a juste jamais eu le temps d'entrer dans la pièce où la décision s'est prise. Ce n'est pas un échec de méthode, c'est la démonstration que l'invisibilité coûte avant même que t'aies fini de la corriger. L'organisation n'attend pas que tu sois prêt à te défendre. ## Ce qui te protège vraiment dans une réorg, ce n'est pas ton titre Ce qui survit à une réorg ne vit jamais dans l'organigramme. Ton titre disparaît le jour où la case bouge. Ta réputation, tes relations, mais le travail documenté quelque part en dehors de ta mémoire : ça, ça reste. Si tu me lis depuis un moment, tu connais déjà la moitié de cette idée. J'ai écrit un article entier là-dessus : [le paradoxe de l'autonomie](https://collaborationsolved.com/paradoxe-autonomie-scrum-master/) explique pourquoi un travail non documenté s'efface, même quand il a produit un vrai résultat. Une réorg ne change rien à ce mécanisme. Elle change juste le délai que t'as pour agir : au lieu de six mois pour t'apercevoir que ton travail s'est effacé de la mémoire collective, t'as juste un lundi matin. Ton carnet de bord (même juste un fichier texte, une ligne par changement observé) ne te protège pas seulement d'une prochaine coupe budgétaire. Il te protège aussi le jour où la case bouge sans préavis, parce que la conversation avec ton nouveau manager ne part pas de zéro. Elle part de ce que t'as déjà écrit. ## La réorg est aussi la seule fenêtre où ton rôle redevient négociable Une réorg, c'est le seul moment où le périmètre de ton rôle redevient ouvert à la discussion. Le reste du temps, ton périmètre est gelé par l'habitude. Personne ne le remet en question parce que personne n'a de raison de le faire. Une réorg force la conversation. Ça veut dire concrètement : le lundi où on t'annonce ton nouveau rattachement, c'est le moment le plus légitime que tu auras pour poser deux questions à ton nouveau manager, avant que l'ancienne routine se réinstalle et que la fenêtre se referme. **Question 1 : sur quoi je vais être évalué dans cette nouvelle configuration ?** Réduction des coûts, amélioration de la qualité, augmentation du volume, de la vitesse : lequel de ces critères pèse le plus pour toi ? **Question 2 : qu'est-ce qui a mené à ce critère-là ?** Pas pour contester la réponse. Pour comprendre le contexte derrière, parce que c'est ce contexte qui te dit où mettre ton énergie dans les six premières semaines. Ce mécanisme, je l'ai déjà détaillé en entier dans [les 2 questions à poser avant qu'on te bouge d'équipe](https://collaborationsolved.com/les-2-questions-a-poser-avant-quon-te-bouge-dequipe/). La différence ici : cet article-là parle d'un mouvement d'équipe ponctuel. Une réorg, c'est la même mécanique, mais avec l'urgence en plus, et souvent plusieurs personnes qui bougent en même temps. Si ton manager ne sait pas répondre à la deuxième question, c'est l'ouverture pour construire la baseline de la nouvelle équipe avec lui, au lieu de deviner ce qu'il attend de toi pendant 3 mois. ## Ce qu'on comprend mal sur les réorgs ### "Être calme, ça veut dire rien ressentir" Faux. Être la personne calme pendant qu'une réorg fait paniquer tout le monde autour de toi, c'est un acte de leadership visible, exactement au moment où le leadership regarde. Tu peux ressentir l'injustice de la situation et choisir quand même d'être la personne qui pose les bonnes questions plutôt que celle qui répand la panique. Les deux ne s'excluent pas. ### "Attendre que ça se calme avant d'agir" C'est l'erreur la plus commune, et je l'ai faite moi-même. Le timing de renégociation n'est plus là une fois que la poussière retombée. Il s'ouvre le jour de l'annonce, et se referme vite, souvent en quelques jours, parce que tout le monde (y compris toi) a envie que la nouvelle routine s'installe rapidement pour arrêter de sentir le déséquilibre. Attendre la stabilité pour poser tes questions, c'est attendre que la fenêtre soit déjà fermée. ## Ce que tu fais dès que l'annonce tombe Trois choses, dans l'ordre, la semaine même de l'annonce. - D'abord, tu écris une ligne dans ton carnet de bord avant même de savoir comment tu te sens. Date, contexte, ce que tu quittes (chantiers en cours), ce que tu emmènes (succès, apprentissages, bonnes pratiques). Ça prend 10 minutes et ça devient la première pièce de ton nouveau dossier. - Ensuite, tu demandes une rencontre courte avec ton nouveau manager dans la première semaine, pas dans le premier mois. Tu poses les 2 questions (critère d'évaluation, contexte derrière le critère). Tu notes les réponses, même approximatives. - Enfin, tu nommes explicitement, dans cette même rencontre, ce que tu veux garder de ton ancien périmètre si ça a du sens dans le nouveau contexte. Pas en demandant la permission. En le proposant comme une évidence : "voici ce qui a bien fonctionné, voici pourquoi je pense que ça vaut la peine de le reproduire ici." C'est un peu comme le dimanche soir où ta gardienne t'appelle pour te qu'elle ferme sa garderie, et que t'as deux semaines pour en trouver une autre. T'avais rien demandé, rien vu venir... Ceux qui s'en sortent le mieux dans un changement forcé, c'est jamais ceux qui figent devant la nouvelle. C'est ceux qui, sans savoir que ça s'en venait, avaient déjà des adresses de garderies alternatives et des commentaires d'autres parents. On les a pas prévenus plus tôt, mais ça les a aidé à s'en sortir vite : ils avaient déjà un système, indépendamment du moment où l'appel allait tomber. Ton carnet de bord et tes deux questions, c'est tes adresses et tes commentaires. Tu les prépares pas parce que tu sais quand la réorg va arriver. Tu les prépares parce que quand elle arrive (et elle va arriver), t'as déjà ce qu'il faut sous la main pour ne pas repartir à zéro un lundi matin. La première fois que ça m'est arrivé, j'ai fait l'inverse : silence total pendant les six premières semaines, à attendre qu'on me dise quoi faire. Le résultat a été exactement celui que t'imagines. Un redémarrage à l'aveugle, des 1-1 avec chaque personne de l'équipe pour ramasser le contexte que j'aurais pu avoir dès le premier jour si j'avais juste posé la question. ## Le seul chiffre qui compte après une réorg Tu ne peux pas empêcher une réorg. Tu peux contrôler à quelle vitesse tu redeviens lisible pour la personne qui décide maintenant de ton avenir. Le SM Survival Score mesure exactement ça : où t'es solide, où t'es invisible, sur cinq dimensions (Visibilité, Preuves, Business, Autonomie, Stratégique). La dimension Stratégique, celle qui couvre directement ta capacité à traverser un mouvement organisationnel sans perdre ton terrain, c'est souvent la plus mal comprise par les Scrum Masters qui le font pour la première fois. [SM Survival Score : Quels sont tes angles morts ?](https://sm-score.collaborationsolved.com/?ref=collaborationsolved.com) Et toi, la prochaine fois qu'une réorg tombe un lundi matin, qu'est-ce que tu auras déjà en main pour ne pas repartir de zéro ? --- ## FAQ **Q : Une réorg menace-t-elle vraiment le poste d'un Scrum Master ?** R : Pas directement, la plupart du temps. Ce qui te met en danger, c'est d'arriver dans le nouveau contexte sans dossier et sans avoir posé les bonnes questions dès le départ. Une réorg c'est un moment de vulnérabilité, pas une condamnation. **Q : Comment documenter mon travail avant qu'une réorg arrive ?** R : Un fichier texte, une ligne par changement observé dans ton équipe, daté. Pas besoin d'un outil compliqué. Ce qui compte, c'est que ça existe en dehors de ta mémoire avant que t'en aies besoin dans l'urgence. **Q : Faut-il accepter la première proposition d'affectation sans discuter ?** R : Non. Une réorg est le moment où ton périmètre redevient discutable. Poser 2 questions simples sur les critères d'évaluation dans la première semaine n'est pas de la résistance au changement. C'est construire la baseline dont toi et ton nouveau manager avez besoin. **Q : Que faire si mon nouveau manager ne sait pas répondre à mes questions sur les critères d'évaluation ?** R : C'est une bonne nouvelle déguisée. Ça veut dire que la baseline n'existe pas encore, et que tu peux la construire avec lui plutôt que de deviner ses attentes pendant des mois. ![](https://storage.ghost.io/c/69/5a/695addfe-1c1d-4828-b10c-8f9c23732c07/content/images/2026/08/signpc-1.png) ### Il a fait ce qu'il fallait. Ça n'a pas suffi. URL: https://collaborationsolved.com/il-a-fait-ce-quil-fallait-ca-na-pas-suffi/ Last updated: 2026-08-26T01:41:41.000Z ![](https://storage.ghost.io/c/69/5a/695addfe-1c1d-4828-b10c-8f9c23732c07/content/images/2026/08/contexte-changement-1.jpg) Tu peux prouver ton impact et te faire déplacer quand même. Tu fais le travail, tu mesures, tu commences même à écrire le dossier qui va le montrer à ton manager. Et la décision tombe sans toi dans la salle... Je t'ai déjà parlé de ce SM qui a organisé 2 ateliers d'une heure sur le découpage du travail. 12 stories livrées par PI avant. L'équipe se met à découper autrement: 50 stories au PI suivant. Des items bloqués depuis plus de 230 jours qui se débloquent enfin (si tu as raté l'histoire complète, avec le calcul de ce que ça représente, c'est ici : [Tu as déjà les preuves. Tu ne les as pas vues.](https://collaborationsolved.com/preuves-impact-scrum-master-invisibles/)). Mais je t'avais pas raconté la suite. Il a pris ces chiffres, il a commencé à construire son dossier pour son évaluation, avec des preuves réelles pour la première fois... Puis son département a été réorganisé. Une discussion de 15 minutes: il change de poste, plus d'équipe à lui. **Sa preuve est arrivée après la décision.** *(à ce stade tu penses peut-être "ça sert à rien de prouver quoi que ce soit alors", ou à l'inverse "il fallait juste un dossier plus gros, plus vite". Les deux ratent le vrai problème. C'est pas le volume de preuve qui a manqué. C'est le moment où il l'a sortie.)* C'est comme dans Top Chef: sortir un plat parfait du four une minute après que le jury ait déjà rempli sa fiche de notation, même si le plat est réussi, le jugement, lui, est déjà écrit. Ta preuve, c'est le plat. Le 1-1 où tu la sors, c'est le moment où le jury note encore ou pas. ### Pose la question avant qu'elle se pose à ta place Dans l'édition sur les transferts d'équipe ([Les 2 questions à poser avant qu'on te bouge d'équipe](https://collaborationsolved.com/les-2-questions-a-poser-avant-quon-te-bouge-dequipe/)), je te donnais 2 questions à poser à ton manager avant d'accepter un changement : sur quoi l'équipe est jugée, et ce qui a mené à ce critère-là. Cette suite-là le rend évident : ces 2 questions ne se posent pas qu'une fois. Elles se posent en continu, avant qu'un transfert soit sur la table. Pas après quand c'est trop tard. Exemple concret, à ton prochain 1-1 : > "En ce moment, sur quoi on est évalué : coût, qualité, volume ou vitesse ?" > > "Est-ce que ça a changé depuis la dernière fois qu'on en a parlé ?" Si la réponse a bougé sans que tu l'aies vue venir, tu viens de trouver ton signal. Pas après la réorg. Avant. ### Ton geste de la semaine Pose la première question à ton prochain 1-1, même si rien ne semble bouger en ce moment. Note la réponse quelque part. Reviens-y dans un mois. Si elle a changé, tu le sauras avant que ce soit trop tard pour agir dessus. Et toi, la dernière fois que le critère de jugement de ton équipe a changé, tu l'as su quand ? Avant, ou après ? Tu veux savoir où tu en es sur la dimension stratégique du rôle (celle qui décide si on te consulte avant un changement, ou si on t'informe après) ? [SM Survival Score : Quels sont tes angles morts ?](https://sm-score.collaborationsolved.com/?ref=collaborationsolved.com) ![](https://storage.ghost.io/c/69/5a/695addfe-1c1d-4828-b10c-8f9c23732c07/content/images/2026/08/signpc-1.png) ### Les 2 questions à poser avant qu'on te bouge d'équipe URL: https://collaborationsolved.com/les-2-questions-a-poser-avant-quon-te-bouge-dequipe/ Last updated: 2026-08-26T01:41:24.000Z ![](https://storage.ghost.io/c/69/5a/695addfe-1c1d-4828-b10c-8f9c23732c07/content/images/2026/08/contexte-changement.jpg) On te change d'équipe du jour au lendemain, et tu dis "ok" par surprise ou pour avoir l'air professionnel. Bref, t'embarques, tu t'adaptes, sans faire de vagues. C'est comme rentrer dans un nouveau jeu, avec une partie déjà commencée sans demander le score. Tu joues quand même mais tu sais même pas si l'équipe est en train de gagner, ni sur quoi on compte les points. Trois semaines plus tard, tu comprends enfin sur quoi elle est jugée. Trois semaines de jouées à l'aveugle... Je l'ai fait. On m'a annoncé un changement d'équipe du jour au lendemain. J'ai dit ok, et j'ai avancé. Je ne savais pas comment ça se passait avant moi. Je ne savais pas sur quoi l'équipe était vraiment évaluée. J'ai dû faire des 1-1 avec tout le monde pour ramasser, petit bout par petit bout, ce qu'une seule question aurait pu me donner le premier jour. C'est bon pour les relations (ça, au moins, ça a servi). Mais c'est mauvais pour le temps perdu en action et en résultats (ce que les gens attendent). Au final l'équipe voyait juste un SM sans contexte en train de dresser la carte de l'équipe au feeling. Comme si ils avaient pas déjà fait ça dans les précédentes rétro... **Ce n'est pas le transfert le problème. C'est le silence qui va avec.** ## Les 2 questions à poser avant de s'engager. Avant d'accepter le prochain changement d'équipe (même un simple ajout de projet, pas besoin d'attendre un vrai transfert), demande sur quoi cette équipe est jugée. 4 axes possibles, pour la question à poser : - **Coût** : on veut dépenser moins ? - **Qualité** : on veut faire mieux les choses ? - **Volume** : on veut livrer plus ? - **Vitesse** : on veut livrer plus vite ? ça donne un truc comme ça : > *"Avant de commencer, je veux comprendre : en ce moment, on est jugés sur le coût, la qualité, le volume ou la vitesse ?"* Après avoir la réponse, tu poses la suivante : > "Qu'est-ce qui c'est passé pour en arriver là?" C'est seulement un 10 minutes de plus dans la conversation, mais le reste du mois tu le passeras plus à deviner. Si ton manager ne sait pas répondre? C'est un signal intéressant. C'est encore plus important de le savoir maintenant, pas dans trois mois. C'est une occasion pour toi de planifier une 1ère mesure, ta baseline... ### Ton expérimentation de cette semaine Prends ton équipe actuelle (même si t'as pas changé depuis longtemps). Est-ce que tu sais, là maintenant, sur quoi elle est jugée ? Si non, pose la question avant vendredi. C'est le même angle mort que quand ton manager ne sait même pas décrire ta semaine de travail ([j'en parlais ici](https://collaborationsolved.com/ton-manager-comprend-il-ton-role-scrum-master/)). Et c'est une question de point de départ : tu peux pas prouver un avant/après si tu ne connais pas l'avant. [Même sans baseline officielle](https://collaborationsolved.com/tas-pas-de-baseline-tu-peux-quand-meme-mesurer/), tu peux commencer à mesurer, à condition de savoir sur quoi. Et toi, la dernière fois qu'on t'a bougé, t'as demandé quoi avant de dire ok ? Tu veux savoir où tu en es sur la dimension stratégique du rôle (celle qui décide si on te consulte avant un changement, ou si on t'informe après) ? [SM Survival Score : Quels sont tes angles morts ?](https://sm-score.collaborationsolved.com/?ref=collaborationsolved.com) ![](https://storage.ghost.io/c/69/5a/695addfe-1c1d-4828-b10c-8f9c23732c07/content/images/2026/08/signpc-1.png) ### Scrum Master inutile ? Le paradoxe de l'autonomie d'équipe URL: https://collaborationsolved.com/paradoxe-autonomie-scrum-master/ Last updated: 2026-08-30T19:54:40.000Z Un jour ton manager te dit : > L'équipe tourne toute seule maintenant, c'est vraiment bien. Il pense te faire un compliment. Toi, en tant que Scrum Master, tu sens un frisson dans le dos. Rendre ton équipe autonome, c'est l'objectif numéro 1 qu'on te répète dans les formations, les livres, et chaque session de coaching. Alors pourquoi cette phrase déclenche des sueurs froides ? Parce qu'une équipe autonome, si personne ne se rappelle comment elle est arrivée là, ça ressemble exactement à un Scrum Master inutile. Et c'est pas que tu n'as pas travaillé, mais que ton travail, personne ne l'a vu se construire. Une fois fini, il devient invisible. ## C'est quoi le paradoxe de l'autonomie ? Plus ton équipe fonctionne sans toi, plus tu ressembles à un poste qu'on peut couper (sauf si le chemin pour y arriver est écrit quelque part). Ton équipe apprend à résoudre ses propres blocages, elle facilite ses propres rétros, elle livre sans que tu pousses derrière. De l'extérieur, ça ressemble à une réussite totale et on peut se dire qu'on peut couper le budget de 10% sans sans rien casser. ## Pourquoi une équipe autonome menace le rôle de Scrum Master Si une équipe devient autonome sans que personne ne documente "le comment", alors la seule information qui reste visible, c'est le résultat pas le travail qui l'a produit. Le management voit rarement les 2 ateliers qui ont débloqué le vrai problème. Il voit un projet qui avance. Il voit pas le jour où tu as arrêté d'animer une cérémonie pour laisser quelqu'un d'autre le faire. Il voit une équipe qui n'a plus de questions pour toi en réunion. C'est exactement le mécanisme que documente Ben Balter (manager chez GitHub, auteur du livre *Open & Async),* en observant comment les communautés open source coordonnent le travail à l'échelle mondiale sans hiérarchie visible. Son constat : la coordination humaine coûteuse devient inutile dès que le travail est documenté et disponible quelque part. Ce qui est vrai pour du code, est vrai pour une équipe. Sauf que dans une équipe, si personne ne documente le chemin, il n'y a nulle part où le retrouver. ## Pourquoi l'autonomie d'une équipe s'efface avec le temps C'est comme les bons petits plats secrets de la grand-mère. Elle goûtes en cours de route, ajustes, ça sort exactement comme il faut. Personne n'a noté les proportions, la recette existe juste dans sa tête. Six mois plus tard, on te demande de faire ce plat et tu te souviens plus si il faut une ou deux gousses d'ail. L'autonomie de ton équipe, c'est la même chose. Cuisinée à l'instinct pendant des mois (une escalade en moins par-ci, une décision prise seuls par-là). Aucune de ces étapes n'a semblé assez grosse pour être notée sur le moment. (Je le confesse : mes trois premières années de coaching, zéro notes. Je redécouvrais mes propres recettes un an plus tard, par accident.) Et la cuisine ne s'arrête pas une fois le plat sorti... Coacher l'équipe à animer sa propre rétro, résister à l'envie de reprendre les rênes quand ça patine, ça continue longtemps après que l'équipe ait l'air autonome de l'extérieur. C'est juste plus difficile à nommer, car ce n'est plus de la facilitation. Ça ressemble à ne rien faire. Le vrai problème arrive quand la cuisine change de chef. Si ton manager est remplacé et que rien n'est écrit, le nouveau arrive dans une équipe déjà autonome. Pour lui, ça a toujours été comme ça. L'histoire n'existe nulle part, alors il n'y a aucune raison de croire qu'elle a un jour commencé ailleurs. Ton avant/après disparaît, pour toi, et pour l'équipe elle-même, qui ne peut plus s'en servir non plus si elle doit un jour reproduire le même chemin ailleurs. ## L'autonomie de ton équipe comme preuve, pas comme excuse Documenter ce chemin, ce n'est pas que te protéger d'une prochaine coupe budgétaire. C'est construire quelque chose qui te sert bien au-delà de ça. Un simple carnet de bord (même juste un fichier texte, une ligne par changement observé) fait deux choses en même temps : - rendre ton travail montrable le jour où quelqu'un le demande. - devient un tableau de chasse que tu réutilises : un post LinkedIn concret, un article, une conférence, etc... C'est la différence entre *"je pense être bon dans mon rôle"* et *"voici ce que j'ai construit, avec les chiffres".* Un carnet comme celui-là existe indépendamment de ta mémoire. Six mois plus tard, tu n'as pas besoin de te souvenir des détails (ils sont écrits). C'est cette différence qui peut, un jour, ouvrir une conversation avec un directeur, ou nourrir un talk. Ça a une valeur qui ne dépend pas de ce que tu te rappelles un mardi après-midi. ## Ce que ça change concrètement pour un Scrum Master ### Le Scrum Master qui n'était pas prêt à lâcher la rétro Un Scrum Master m'a raconté, qu'il n'arrivait toujours pas à déléguer la rétro à l'équipe. Pourtant, pendant ses vacances, l'équipe l'a menée seule (et ça s'est bien passé). Au daily, il admet être surtout en observation maintenant ; l'équipe se gère elle-même la plupart du temps. Rien de tout ça n'est un problème de performance. C'est même le résultat qu'on lui a demandé de produire. Mais il a fini par dire tout haut ce que ça lui faisait : > "Si ces heures de travail disparaissaient, peut-être qu'on va se dire que je ne suis plus utile." Ce qu'il a construit avec l'équipe est bien réel. Ce qu'il manque, c'est la version racontable de comment c'est arrivé. Le management voit juste une équipe autonome. L'équipe le voit probablement aussi. **Personne n'a capturé le travail qui a rendu l'autonomie possible,** ni les mois à coacher chaque personne à animer sa partie de la rétro, ni les fois où il a résisté à l'envie de reprendre les rênes. C'est du savoir. Dans un métier où le travail, c'est principalement de la connaissance, un savoir non capturé n'a pas de valeur (même quand il a produit un résultat réel). ### Le SM passé côté produit Quelqu'un de mon réseau, ex-Scrum Master, aujourd'hui côté produit, tourne à 7/8 sur la dimension autonomie du [Survival Score](https://sm-score.collaborationsolved.com/?ref=collaborationsolved.com). Sur la dimension Business, il est à 3/8\. Résultat : il est classé « Stable », et pas « Irremplaçable ». Une autonomie réelle, construite, mesurable mais qui ne s'est jamais traduite dans un langage que ses décideurs comprennent. L'autonomie seule ne protège personne. Comme dans l'exemple de la rétro, il faut les deux : le savoir capturé, et la version qui se raconte à quelqu'un qui n'était pas présent. ## Les mythes de l'autonomie d'équipe - **Une équipe autonome n'a plus besoin de facilitation.** Faux. Elle a besoin d'un encadrement différent (arbitrage, connexions externes, protection de nouvelles pressions...), le besoin change de forme mais ne disparaît pas. - **Documenter, c'est me vanter.** Non, c'est la seule différence entre un actif et un souvenir. Un CV qui dit *"j'ai rendu mon équipe autonome"* sans donnée derrière n'est pas de la modestie. C'est juste invérifiable. - **Une fois acquise, l'autonomie reste.** Faux, et c'est le piège le plus silencieux. L'autonomie ne s'inscrit nulle part d'elle même. Si personne ne l'écrit, elle s'efface du récit organisationnel exactement comme elle s'efface de ta propre mémoire. ## Comment prouver l'autonomie de ton équipe Ouvre un fichier dès maintenant. Pas après avoir fini cet article. Identifie au moins une chose que ton équipe fait aujourd'hui qu'elle ne faisait pas il y a 6 mois. Formule-la en une phrase. Date l'entrée. C'est ton premier dépôt dans un actif que tu vas réutiliser. Revisite cette liste toutes les semaines. Dans quelques mois, tu n'auras pas une impression vague d'avoir bien fait ton travail. Tu auras plusieurs lignes datées, avec un avant et un après pour chacune. ## Scrum Master, où en est l'autonomie de ton équipe ? Si cette question te parle : > Est-ce que je suis encore utile quand mon équipe se gère seule ? C'est exactement le sujet de *:* [L'équipe aurait pu faire ça sans toi,](https://collaborationsolved.com/valeur-ajoutee-scrum-master-equipe-autonome/) une édition de la newsletter qui creuse la même angoisse sous un autre angle. L'autonomie de ton équipe, est une des 5 dimensions mesurées par le [SM Survival Score](https://sm-score.collaborationsolved.com/?ref=collaborationsolved.com) (avec Visibilité, Preuves, Business et Stratégique). **La plupart des Scrum Masters qui font le test découvrent que c'est justement leur angle mort le plus silencieux, celui qu'ils n'ont jamais pensé à défendre.** [SM Survival Score : Quels sont tes angles morts ?](https://sm-score.collaborationsolved.com/?ref=collaborationsolved.com) Et toi, tu pourrais raconter comment ton équipe est devenue autonome avec les étapes, pas juste le résultat ? ![](https://storage.ghost.io/c/69/5a/695addfe-1c1d-4828-b10c-8f9c23732c07/content/images/2026/08/signpc-1.png) --- ## FAQ - **Q : Une équipe autonome, c'est bon signe pour un Scrum Master ?** R : Oui, pour l'équipe. Pas automatiquement pour ton rôle. C'est bon signe seulement si le chemin pour y arriver est documenté quelque part et traduit en langage compréhensible pour ton management. Sans ça, c'est juste un résultat sans auteur visible. - **Q : Comment prouver mon rôle si mon équipe n'a plus besoin de moi au quotidien ?** R : Tu ne prouves pas ton rôle avec ce que l'équipe fait aujourd'hui, tu le prouves avec le chemin entre l'avant et l'après. Documente une transformation précise, datée, avec ce que tu as changé concrètement. - **Q : Faut-il avoir peur de rendre son équipe trop autonome ?** R : Non. Il faut avoir peur de la rendre autonome sans rien noter. L'autonomie n'est jamais le problème. C'est le silence autour de comment elle a été construite. ### Le retard est gratuit sur papier. Il coûte cher ailleurs. URL: https://collaborationsolved.com/le-retard-est-gratuit-sur-papier-il-coute-cher-ailleurs/ Last updated: 2026-08-26T01:40:36.000Z ![](https://storage.ghost.io/c/69/5a/695addfe-1c1d-4828-b10c-8f9c23732c07/content/images/2026/08/rush-invisible.jpg) Ton retard ne coûte rien sur le budget. C'est bien le problème. Le client (interne ou externe) paie exactement ce qui était prévu. En comité de suivi, les chiffres sont bons. Un peu de retard de temps en temps, ça passe, mais quand ça revient sprint après sprint (genre une dépendance externe) on finir par s'y habituer et l'accepter. Et pendant ce temps, quelqu'un paie. Toi, ton équipe, ou ton management, qui rushent pour tenir le délai facturé sans jamais toucher au chiffre du budget. Ce coût-là ne sort d'aucun rapport. Il sort des journées, des week-ends, de la qualité qu'on sacrifie en silence. Invisible sur le papier. Bien réel ailleurs. Dans le [SM Survival Score,](https://sm-score.collaborationsolved.com/?ref=collaborationsolved.com) une question revient : > Sais-tu combien coûte une semaine de retard pour ton équipe ? La majorité des SM répondent non. Pas par paresse, parce que personne ne leur a jamais montré comment. ## Voici la formule pour calculer le coût d'une semaine de retard. > (nb personnes équipe) × 5 jours × coût journalier moyen par personne - Si les retards sont récurrents (dépendance externe qui revient), multiplie par le nombre de sprints touchés. - Le coût journalier moyen, tu le demandes à ton PO ou au management. Exemple: - Équipe de 6 personnes, coût journalier moyen 450$. - 6 × 5 × 450$ = **13 500$ pour une semaine**. - Si ça revient à chaque sprint sur un trimestre (3 sprints touchés) = **40 500$.** Zéro ligne budgétaire ne montre ce chiffre-là. Il existe quand même. C'est ta preuve. ### Ce que tu peux rendre visible cette semaine Prends UNE dépendance récurrente dans ton équipe. Calcule son coût sur le dernier trimestre avec la formule ci-dessus. Pas besoin d'être précis au dollar près, un ordre de grandeur suffit pour changer la conversation. Rendre ce chiffre visible, c'est ce qui déclenche l'urgence. Pas pour blâmer quelqu'un mais pour que quelqu'un décide enfin de s'attaquer au problème, ou de l'assumer les yeux ouverts plutôt que dans le silence. C'est comme ça que tu défends ton rôle sans hausser la voix. En sortant un chiffre que personne d'autre n'avait. [SM Survival Score : Quels sont tes angles morts ?](https://sm-score.collaborationsolved.com/?ref=collaborationsolved.com) ![](https://storage.ghost.io/c/69/5a/695addfe-1c1d-4828-b10c-8f9c23732c07/content/images/2026/08/signpc-1.png) ### La décision était prise avant la réunion. Tu l'as découvert après. URL: https://collaborationsolved.com/decision-prise-avant-reunion-scrum-master-boucle/ Last updated: 2026-08-26T01:40:19.000Z ![](https://storage.ghost.io/c/69/5a/695addfe-1c1d-4828-b10c-8f9c23732c07/content/images/2026/06/pas-dans-la-boucle.jpg) Aujourd'hui, ton manager t'a annoncé un changement qui touchait ton équipe. Tu l'as découvert en même temps que les devs : la moitié de l'équipe est splittée et part dans un autre stream. Personne n'a demandé ton avis. On ne t'a pas consulté. On te l'a juste annoncé en même temps que les autres. C'est arrivé aussi le jour où on t'a dit que le scope du sprint changeait en plein milieu. Ou que de nouvelles personnes arrivaient le lundi matin. Bref... T'as hoché la tête et tu t'es dit que tu allais gérer ça avec l'équipe. La rétro d'après, l'équipe savait déjà que ce que vous alliez décider ensemble ne changerait probablement rien. Parce qu'eux aussi, ils avaient compris... Dans ces moments-là, c'est facile de ressentir de la frustration. Mais ce qu'on ressent surtout, c'est une confirmation : ## Le SM n'est plus dans la boucle des décisions. Il y a quelqu'un qui a décidé que tu n'avais pas besoin d'être consulté. Que ce n'était pas si utile de te mettre dans le secret. Parce qu'au final, ce n'est pas toi qui gères c'est le management. Et d'un côté, c'est vrai. Mais de l'autre, ça révèle une croyance : que certaines décisions n'ont pas vraiment d'impact concret sur l'équipe. Ton équipe sait que les décisions se prennent ailleurs. Elle est bien gentille de participer à tes rétros. [Elle dit "ça va" quand tu poses des questions.](https://collaborationsolved.com/equipe-dit-ca-va-scrum-master-silence/) Vous passez 2 heures ensemble à générer des action items qui meurent le sprint d'après. Le premier réflexe c'est de se dire qu'il y a un problème de confiance entre toi et l'équipe. Mais dans ce cas précis, c'est plutôt un problème de positionnement dans le système. Et la différence est cruciale. Parce que si tu crois que c'est un problème de confiance, c'est toi que tu vas essayer de changer. Tu vas recréer un espace de confiance, changer ton animation, ta facilitation, ta posture. Changer la manière dont tu poses tes questions. Lire tout un tas de livres sur la sécurité psychologique. Et ça ne changera rien... Parce que tu es de bonne volonté, tu essaies de faire les choses bien, mais le problème ce n'est pas ce qui se passe dans la rétro, c'est pas la manière dont tu poses tes questions. C'est ce qui se passe en dehors. Et le problème, c'est que tu n'en fais pas partie. ### Trois signaux qui te permettent de dire que tu es sorti de la boucle. [Pour chacun, une petite expérimentation à tester.](https://docs.google.com/document/d/1rVb3iA7g9ON1nSQVPmWtf1oKyFK-fGglmVBX7zsfLPE/edit?usp=sharing&ref=collaborationsolved.com) **L'erreur à éviter c'est de formuler la demande comme un besoin personnel.** > "J'ai vraiment besoin d'être informé plus tôt." Ça donne l'impression de vouloir être dans toutes les décisions, de se rajouter des réunions. D'avoir un besoin d'être au courant de tout. Ce qu'il faut faire à la place c'est **expliquer ce que ça coûte**. Ce que ça impacte d'avoir l'information trop tard. Ce qu'on aurait pu éviter si on l'avait eue avant. - Est-ce qu'il y a des initiatives qu'on n'aurait tout simplement pas commencées si on avait su quelques jours avant qu'un événement allait impacter l'équipe ? - Est-ce qu'on aurait pu planifier le sprint suivant différemment ? **Tout ce qu'on fait en l'agilité c'est de la gestion de risque.** Ramène cet argument à ton management. **Être dans la boucle, ça ne veut pas dire être invité à toutes les réunions. Ça veut dire être consulté sur celles qui ont un impact, pour pouvoir éviter des risques avant qu'ils atteignent l'équipe.** Pour pouvoir chiffrer ce qui va se passer. Pour faire un plan de gestion de risque avec ton manager avant que le choc arrive. Et toi, t'as déjà eu une annonce à la dernière minute sur quelque chose qui allait impacter ton équipe ? Comment tu as géré ça ? [SM Survival Score : Quels sont tes angles morts ?](https://sm-score.collaborationsolved.com/?ref=collaborationsolved.com) ![](https://storage.ghost.io/c/69/5a/695addfe-1c1d-4828-b10c-8f9c23732c07/content/images/2026/08/signpc-1.png) ### Il sait ce que tu coûtes. Il ne sait pas que tu es gratuit. URL: https://collaborationsolved.com/il-sait-ce-que-tu-coutes-il-ne-sait-pas-que-tu-es-gratuit/ Last updated: 2026-08-26T01:40:05.000Z ![](https://storage.ghost.io/c/69/5a/695addfe-1c1d-4828-b10c-8f9c23732c07/content/images/2026/06/coute-ou-rapporte.jpg) ## Le coût d'un Scrum Master, c'est facile à connaître. C'est écrit sur ta fiche de paie. Ce que tu rapportes, c'est une autre histoire. La valeur que tu génères pour ton entreprise, c'est bien souvent plus une opinion qu'un chiffre. Et c'est pareil pour un coach agile, ou nos manager même eux auraient du mal à quantifier leur propre impact. Quand quelqu'un ouvre un fichier Excel et regarde les coûts, il voit les salaires. C'est tout ce qu'il voit. En réorg, c'est ça qu'on juge : la performance perçue vs le salaire qui coûte. Et ce déséquilibre peut mettre ton poste dans la balance. Quand la direction pose la question *"Est-ce que le rôle du Scrum Master a de la valeur ?"* c'est difficile à défendre. Pas nécessairement parce qu'on pense que tu ne sers à rien. Mais parce que personne n'a jamais mis un chiffre sur le retour sur investissement. Pourtant t'as contribué. T'en as débloqué des décisions. Recadré des sprints qui partaient en vrille. Amélioré la qualité. Débloqué un travail immobilisé depuis des mois sur une dépendance critique. Mais combien ça vaut, tout ça ? C'est là que la traduction manque... Parce que ça, c'est le coût du statu quo. Ne rien faire, c'est accepter que ces coûts-là pèsent sur les finances de l'entreprise en silence. Prenons un exemple concret : Un Scrum Master, 4 équipes SAFe. Il organise un atelier de deux heures : découpage vertical des stories, la base. PI suivant, la livraison passe de 12 à 50 stories. Multiplication par 4\. Du travail bloqué depuis 230 jours qui se débloque enfin. Est-ce qu'on peut estimer la valeur de ce travail débloqué ? Parfois oui. Souvent non. Dans une grosse organisation, avec autant d'intermédiaires, de produits, de passerelles, c'est dilué. On ne peut pas prendre le chiffre d'affaires et diviser par le nombre de stories. ### On peut calculer le prix qu'il aurait coûté de ne rien faire. Parce que du travail immobilisé, c'est du temps humain. Et le temps humain, on peut le chiffrer, parce que le salaire est connu. Un Scrum Master à Montréal, c'est environ 92000 $ brut par an (environ 7 500 $ par mois). Le coût de ces 230 jours de travail bloqué (calculé en heures humaines immobilisées) dépasse déjà le salaire mensuel du SM. Et après l'atelier, la capacité a été multipliée par quatre. Le SM était remboursé depuis longtemps. On n'avait juste pas calculé... Le coût du statu quo, c'est le coût d'avoir du travail immobilisé sans aucune action. À partir du moment où tu chiffres ce coût, et que tu vois la situation changer, tu es capable de mesurer ce que ton intervention a évité. C'est pas de la valeur au sens strict. Mais ça s'en rapproche. Et surtout, ça se défend devant un VP. ### Calcul du côut d'un déblocage Tu peux faire le test toi-même avec l'outil que je t'avais partagé il y a quelques semaines : [l'Impediment Value Calculator](https://pcdenant.github.io/impediment-value-calculator/?ref=collaborationsolved.com). Il te permet de regarder le coût réel du statu quo, et d'estimer ce qu'un déblocage a évité. Combien une décision que t'as aidé l'équipe à prendre a libéré comme capacité. C'est pas juste une estimation abstraite. Le poids de ton salaire est connu. Et il est facile d'extrapoler si ce déblocage couvre ton salaire mensuel ou même annuel. Si t'as pas encore de baseline et que tu ne sais pas par où commencer [check ici.](https://collaborationsolved.com/tas-pas-de-baseline-tu-peux-quand-meme-mesurer/) Je t'explique comment créer ta baseline avant même d'avoir les données parfaites. [SM Survival Score : Quels sont tes angles morts ?](https://sm-score.collaborationsolved.com/?ref=collaborationsolved.com) ![](https://storage.ghost.io/c/69/5a/695addfe-1c1d-4828-b10c-8f9c23732c07/content/images/2026/08/signpc-1.png) ### Ce que l'IA ne sait pas, c'est toi qui le sais. URL: https://collaborationsolved.com/ce-que-lia-ne-sait-pas-cest-toi-qui-le-sais/ Last updated: 2026-08-26T01:39:50.000Z ![](https://storage.ghost.io/c/69/5a/695addfe-1c1d-4828-b10c-8f9c23732c07/content/images/2026/06/le-vrai-probleme.jpg) J'ai un aveu à te faire. Je déteste faire des tableaux. Les calculs manuels, les formules Excel, les copier-coller de données d'une source à l'autre, c'est le genre de truc qui me donne envie de remettre à demain indéfiniment *(*je suis paresseux et perfectionniste en même temps... C'est souvent le bordel dans ma tête*).* Alors quand j'ai eu à produire un rapport de tendance sur la qualité des livrables de plusieurs équipes, j'ai fait ce que n'importe qui ferait : j'ai passé ma commande à l'IA : "Voici les données brutes. Calcule les tendances par rapport aux mois précédents. Dis-moi ce que tu vois." Franchement, l'IA a très bien fait le travail. Tendances calculées, graphiques, tout est propre. Et puis elle est allée plus loin, elle a croisé des données, trouvé une corrélation, et sorti une conclusion claire et confiante : **l'équipe avait un sérieux problème de qualité.** Sauf que c'est faux (jusqu'à preuve du contraire). Les données avaient des faux positifs connus : des bugs mal loggués, des entrées incomplètes, car les équipes remplissaient les tickets de manière très variable. On le savait (nous, les humains). [On avait délibérément décidé de mesurer quand même](https://collaborationsolved.com/tas-pas-de-baseline-tu-peux-quand-meme-mesurer/), pas pour avoir une image parfaite, mais pour commencer à voir où s'améliorer dans le temps. C'était le but de cette mesure. ## L'IA ne savait pas car cette décision-là n'était pas dans le dataset. "l'équipe a un problème de qualité" et "notre système de logging a besoin d'être standardisé" ne sont PAS deux interprétations différentes du même problème. Ce sont deux problèmes différents, avec deux solutions opposées. Le truc c'est que l'IA est rapide, multisource, et structurée. Elle traite en quelques secondes ce qui me prendrait une heure. Mais elle hallucine avec confiance quand le contexte lui manque et ce contexte vit pas souvent dans le dataset. Il vit dans les décisions prises autour de la table AVANT que la mesure commence. ### La donnée sans contexte c'est du bruit. Et là, on peut avoir deux mauvaises réactions. - Soit, t'es bluffé par la confiance du rapport : C'est propre, l'écriture est fluide, parait professionnelle, intelligente et les chiffres s'alignent. Alors, tu valides, tu partages et ton manager prend une décision. Mais la décision est fausse et personne ne comprend pourquoi (sauf toi, parce que toi tu savais ce que les données ne disaient pas). Ta crédibilité est en jeu. - Soit, tu vois que le résultat est faux : Tu perds confiance, te fermes à l'outil, repars faire tes tableaux manuellement en te disant que l'IA donne de mauvais résultats. Tu t'améliores pas. C'est comme une équipe qui décide que les rétros ne servent à rien, car ils en ont raté plusieurs. C'est pas une question de technologie, c'est une question de qui détient quoi. L'IA collecte, analyse et structure. Vite et bien, et sans se plaindre. Mais le contexte des décisions (dans lequel elles ont été prises) c'est toi qui le détiens. Et ça ne se stocke pas dans Jira. ### Le SM qui se démarque ne concurrence pas l'IA sur la collecte de données. Il fait ce que l'IA ne peut pas : il centralise le contexte qui donne un sens aux chiffres, écoute ce qui n'est pas dit, et formule des hypothèses que les données seules ne produiront jamais. ### Ton expérimentation 48h Avant de partager ton rapport généré par IA, ajoute une ligne. Une seule. Ce que l'outil ne savait pas quand il a produit ce résultat. C'est là que ton travail commence. Pas à la place des données, au-dessus. Et toi, t'as déjà eu un outil (IA ou autre) qui t'as sorti une conclusion confiante que tu savais fausse parce que tu avait le contexte ? Comment t'as géré ça ? [SM Survival Score : Quels sont tes angles morts ?](https://sm-score.collaborationsolved.com/?ref=collaborationsolved.com) ![](https://storage.ghost.io/c/69/5a/695addfe-1c1d-4828-b10c-8f9c23732c07/content/images/2026/08/signpc-1.png) ### Tu parles agile, il pense budget. Personne ne traduit. URL: https://collaborationsolved.com/sm-parles-agile-manager-pense-budget-personne-ne-traduit/ Last updated: 2026-08-26T01:39:35.000Z ![](https://storage.ghost.io/c/69/5a/695addfe-1c1d-4828-b10c-8f9c23732c07/content/images/2026/06/reorg.jpg) Il y a toujours une réorg qui se prépare. Ton manager fait sa liste. Il veut te garder ça, t'en es sûr. Mais en face de ton nom, il doit écrire quelque chose. Un argument. Un chiffre. Une phrase qu'il peut répéter en comité sans avoir l'air de défendre quelqu'un par habitude. Il t'appelle : > "Donne-moi quelque chose." Et là, t'as quoi en tête ? > "Je facilite les cérémonies, je coach l'équipe et le PO, je rapporte des métriques." Vous raccrochez. Il écrit à écrit exactement ça en face de ton nom... ## **T'as parlé agile à quelqu'un qui pense en coûts, volume, délais, et risques.** C'est le langage qu'il utilise pour défendre n'importe quelle décision en haut. Si tu ne lui donnes pas tes actions dans ce langage-là, il ne peut pas s'en servir. "Je facilite l'équipe" ne défend pas un poste. Par contre "J'ai réduit le temps moyen de résolution des blocages de 18 jours à 4 jours ce trimestre" ça, ça défend un poste. La différence entre les deux, c'est la traduction. On t'apprends pas ça dans les certifs de Scrum.org ### Le management évalue avec 4 questions. Souvent les mêmes. - **Coût :** Qu'est-ce que ça a coûté, et est-ce qu'on a évité de dépenser quelque chose ? > "Les items bloqués depuis plus de 60 jours représentaient environ 3 semaines de travail d'équipe immobilisées. J'en ai résolu 8 en un sprint. On a récupéré ce temps." - **Volume :** Qu'est-ce qu'on a produit de plus ? > "Le throughput de l'équipe est passé de 12 stories par PI à 50 après deux ateliers de découpage. Le même nombre de personnes, le même nombre de sprints." - **Rapidité :** Est-ce que quelque chose va plus vite maintenant ? > "Le délai moyen de démarrage du travail était de 11 jours après le planning. C'est à 5 jours depuis qu'on a changé la structure du daily." - **Qualité :** Est-ce qu'on prend de meilleures décisions, avec moins de rework ? > "On avait en moyenne 3 stories qui revenaient au sprint suivant pour corrections. Depuis qu'on a introduit une Definition of Done révisée, c'est tombé à moins d'une par sprint." Ces chiffres existent dans ton contexte. Ils sont dans JIRA, dans tes notes de retro, dans les mémoires de l'équipe. Tu les as juste pas encore formulés dans ce langage-là. Le marché, lui, a déjà fait le calcul... **1 poste SM pour 39 candidats à Montréal en ce moment.** [Le gouvernement Canadien classe les perspectives d'emploi "Limitées" pour les Scrum Master jusqu'en 2027.](https://www.jobbank.gc.ca/marketreport/outlook-occupation/296938/QC?ref=collaborationsolved.com) Ce ne sont pas les moins bons SM qui se font couper. Le marché cherche surtout des SM expérimentés qui savent parler le language du comité de direction, pas celui du Scrum Guide. Et si tu donnais à ton manager les bons mots avant qu'il te les demande ? [SM Survival Score : Quels sont tes angles morts ?](https://sm-score.collaborationsolved.com/?ref=collaborationsolved.com) ![](https://storage.ghost.io/c/69/5a/695addfe-1c1d-4828-b10c-8f9c23732c07/content/images/2026/08/signpc-1.png) ### T'as pas de baseline ? Tu peux quand même mesurer. URL: https://collaborationsolved.com/tas-pas-de-baseline-tu-peux-quand-meme-mesurer/ Last updated: 2026-08-26T01:39:16.000Z ![Comic minimaliste. À gauche, un Scrum Master (raton laveur orange) dit : "On a réglé le carryover. L'équipe livre mieux." À droite, un manager en costume répond : "C'est du feeling ou c'est réel ?"](https://storage.ghost.io/c/69/5a/695addfe-1c1d-4828-b10c-8f9c23732c07/content/images/2026/05/feeling-ou-pas.jpg) Le 13 mai, je donnais une conférence à Agile Montréal. Le sujet : ce que j'aurais voulu savoir pour prouver mon impact en tant que SM (avant de me faire virer). Lors du Q&A, une participante a dit quelque chose d'intéressant sur la mesure : > *"Mon problème, c'est que j'aurais dû prendre une photo de l'avant. Je sais que les choses se sont améliorées. Mais je peux pas le montrer."* La personne à côté d'elle a hoché la tête sans rien dire. ![si tu mesures pas, ça existe pas](https://storage.ghost.io/c/69/5a/695addfe-1c1d-4828-b10c-8f9c23732c07/content/images/2026/05/REX-Bon-SM----a-n-as-pas-suffi.jpg) une des slides de mon talk ## L'absence de point de départ, c'est ça le vrai problème... pas l'absence de résultats. [Dans une précédente newsletter](https://collaborationsolved.com/preuves-impact-scrum-master-invisibles/), je te parlais d'un SM qui gérait 4 équipes en SAFe. Après 2 heures d'ateliers le throughput était multiplié par 4\. Des items bloqués depuis 230 jours qui ont enfin bougé. Il avait fait quelque chose d'important, il l'avait juste pas vu... Ce qu'il n'avait pas non plus, c'est une baseline. Aucune mesure avant les ateliers. En tout cas, rien de formalisé. **Mais les données existaient.** Elles étaient dans Jira depuis le début. On a reconstitué les mesures avec ce qui traînait déjà là. Et le "avant" a rendu le "après" crédible. Si t'as pas de baseline, c'est pas foutu. C'est juste pas encore fait. ### **Ton expérimentation 48h** 3 questions pour créer ta baseline aujourd'hui Prends un problème que tu travailles en ce moment (un seul). ### 1\. C'est quoi le problème que tu règles ? Une phrase. Pas une liste. > *Les sprints finissent avec du carryover systématique.* ### 2\. Qu'est-ce qui te prouve qu'il existe aujourd'hui ? C'est là que les SM se trompent le plus souvent. Ils répondent avec du qualitatif pur : "l'équipe se plaint", "ç'est chaotique". C'est un début, mais ça donne pas de point de référence. Cherche 2 points de vue : > **Quantitatif :** *Sur les 4 derniers sprints, on livre 60% de ce qu'on s'engage à faire. On prends 50% de trop au planning.* > **Qualitatif :** *L'équipe dit "c'est pas grave" quand un item passe au sprint suivant. Personne ne questionne le pattern.* Les 2 ensemble, c'est une preuve. Juste le qualitatif, c'est une impression. ### 3\. Quelle évolution tu veux voir dans 6 semaines ? Pas un rêve, pas des licornes. Un signal. > **Quantitatif :** *"On livre 80% de ce qu'on s'engage. On prends sur la vélocité médiane des 4 derniers sprints."* > **Qualitatif :** *"L'équipe commence à nommer le carryover comme un problème, plus comme la norme."* --- ## N'attends pas que la mesure soit parfaite avant de commencer. Elle ne le sera jamais, et plus tu attends, plus le problème que tu travailles existe sans trace. Il y a aussi une 2ème peur, moins avouée : se faire challenger sur les chiffres. Alors on reste dans le qualitatif (c'est plus confo). C'est aussi plus facile à détruire en 30 secondes : *"C'est du feeling ou c'est réel ?"* Un chiffre approximatif tient mieux qu'un sentiment bien formulé. Trouve une donnée, même imparfaite, même vite fais. C'est suffisant pour commencer. Dans 6 semaines, t'as un "avant" et un "après" pour une conversation à avoir avec des preuves, pas juste des impressions. Est-ce qu'il y a un problème que tu travailles en ce moment avec ton équipe dont tu saurais pas montrer l'évolution si on te le demandait demain ? [SM Survival Score : Quels sont tes angles morts ?](https://sm-score.collaborationsolved.com/?ref=collaborationsolved.com) ![](https://storage.ghost.io/c/69/5a/695addfe-1c1d-4828-b10c-8f9c23732c07/content/images/2026/08/signpc-1.png) ### 85% des problèmes de sprint viennent du planning URL: https://collaborationsolved.com/problemes-sprint-viennent-du-planning/ Last updated: 2026-08-26T01:38:59.000Z ![](https://storage.ghost.io/c/69/5a/695addfe-1c1d-4828-b10c-8f9c23732c07/content/images/2026/05/sprint-pompier.jpg) 85% des problèmes que tu règles pendant ton sprint ont été créés le lundi au planning. C'est pas une stat académique... C'est ce que j'observe depuis des années sur le terrain. Et chaque fois que je le dis, j'entends la même réponse : "Ouais mais les urgences, on peut pas les prévoir." ## Tu peux anticiper les urgences en regardant d'où elles viennent vraiment. Le sprint goal était flou (ou absent) : Alors quand une demande arrive en milieu de sprint, personne sait si c'est urgent ou pas. Par défaut, tout devient urgent. La capacité de l'équipe a été surestimée : Pas de buffer, pas de place pour la maintenance. Le sprint commence déjà en retard avant qu'on ait commis une seule ligne de code. Le backlog était pas prêt : Les stories ont été découvertes pendant la réunion. Les décisions ont été prises sous pression, en 2h, avec les mauvaises informations. Résultat, tu passes les deux semaines suivantes à réagir, relancer, réajuster. Tu es (très) occupé. Et complètement invisible parce que tu gères du bruit, pas de la valeur. Le piège classique c'est de penser que le planning, c'est le territoire du PO. Que t'approcher du backlog, c'est faire le PM "déguisé". Alors tu te mets de côté. Tu facilites la réunion. Tu gères le temps. Et le sprint qui suit, tu te retrouves en mode pompier. Pis le sprint d'après aussi... Au 15e sprint en mode pompier, quelqu'un te dit : "Tu devais pas coacher le PO là-dessus ?" Oui. C'était exactement ton rôle. ### **Ton expérimentation 48h** Le vendredi avant ton prochain planning : 3 conversations. 20 min. **La question de capacité** Avant d'ouvrir la réunion, tu vas voir le PO avec un chiffre. Jours dispo, absences, maintenance incluse. Et tu poses cette question : > "Quelles sont les stories qu'on peut **pas** se permettre de ne **pas** livrer ce sprint ?" Contre-intuitive. Elle force une vraie priorisation, pas une liste de souhaits. Le PO choisit avant d'entrer dans la salle, l'équipe aussi. Ce qui rentre dans le sprint a déjà été défendu. **La vision avant la formulation** Le sprint goal ne s'invente pas pendant le planning. Mais on se l'approprie. Le PO arrive avec une intention claire : ce qu'on cherche à sécuriser, le feedback qu'on veut obtenir, la valeur qu'on veut livrer. Pas un paragraphe, juste une direction. L'équipe formule ensuite ses mots. Elle s'approprie l'objectif au lieu de le subir. Si le PO peut pas te dire ça en 2 min. le vendredi avant, la réunion du lundi va être longue... **Le % non-négociable** La dette technique, t'essaieras pas de la justifier en réunion, tu vas perdre. Le PO veut des features. Le management veut du delivery. Ce qui marche : négocier un pourcentage de capacité réservé à la maintenance et à l'amélioration technique. Le pourcentage varie selon le contexte. Le principe, lui, ne bouge pas. C'est exactement le principe de l'épargne. Tu mets de côté avant de dépenser, pas avec ce qui reste à la fin du mois. Ce qui reste à la fin du sprint, c'est zéro. Ça l'a toujours été. *"Super PC, et si j'ai pas le temps pour les trois ?"* ### Une seule question au PO, dans le couloir, avant lundi : > *"Shit happens. Ça arrive à chaque sprint. C'est quoi le scope que tu veux absolument protéger ?"* En général ça fait sourire. Et ça force la vraie conversation. Sur les priorités réelles, pas les priorités déclarées. Est-ce que t'as déjà essayé de négocier un % fixe pour la dette technique ? Comment ça s'est passé ? [SM Survival Score : Quels sont tes angles morts ?](https://sm-score.collaborationsolved.com/?ref=collaborationsolved.com) ![](https://storage.ghost.io/c/69/5a/695addfe-1c1d-4828-b10c-8f9c23732c07/content/images/2026/08/signpc-1.png) ### Tu travailles dans l'ombre. On t'y laisse. URL: https://collaborationsolved.com/scrum-master-invisibilite-sortir-ombre/ Last updated: 2026-08-26T01:38:38.000Z ![](https://storage.ghost.io/c/69/5a/695addfe-1c1d-4828-b10c-8f9c23732c07/content/images/2026/05/review-5.jpg) [La semaine dernière, je t’ai montré que tu avais déjà des preuves.](https://collaborationsolved.com/preuves-impact-scrum-master-invisibles) *(L’outil dedans va t’être utile pour la suite.)* Cette semaine : pourquoi tu ne les nommes pas. Voilà ce qui vient de se passer dans le comic au-dessus. L’équipe a livré. Le manager dit “bravo l’équipe.” Et tout le monde est content. Mais toi, t’as rien dit sur ce que tu as fait pour que ça arrive. C’est pas de la modestie, c’est un réflexe. Le servant leadership t’a appris à effacer ton impact au profit de l’équipe. C’est gravé dans la définition du rôle : le SM travaille dans l’ombre. ## Les zones d'ombres, ça fais poser des questions sur le budget. J’ai travaillé récemment avec un SM. Il avait organisé 2 ateliers d’une heure. Son équipe est passée de 12 stories livrées par PI à 50\. **Plus de 230 jours d’items bloqués avaient bougé**. Quand je lui ai sorti les chiffres, il a allumé : *“Ah ouais, j’avais pas vu ça comme ça.”* En Sprint Review, aurait pu dire “l’équipe a bien livré.” C’est vrai mais c’est incomplet. Personne dans la salle n’a su ce qui avait causé cette accélération. Ni le manager. Ni la direction. Possible que le PI suivant, personne ne sache quoi reproduire.... **Ce qui n’est pas dit, n’est pas répétable.** ### A tester au prochain Sprint Review Pas de pitch. Pas de vantardise. Juste ça : - Ce qu'on a livré : \[résultat de l'équipe\] - Ce que j'ai mis en place : \[la condition que TU as créée\] - Ce que ça a débloqué : \[impact + ce qu'on peut répéter\] Dans l'exemple du SM : - Ce qu'on a livré : 50 stories ce PI, contre 12 le PI précédent. - Ce que j'ai mis en place : deux ateliers de découpage, séparer les tâches simples des grosses stories. - Ce que ça a débloqué : les tech leads ont pu prendre le relais. 230 jours d'items bloqués ont bougé. On sait maintenant quoi refaire dès le prochain sprint. L’équipe est nommée en premier. Elle a livré, c’est dit. Et toi, tu nommes ce que tu as mis en place pour que ça soit possible. Deux vérités distinctes, pas de compétition. Le piège : attendre que quelqu’un te pose la question. Spoiler : on ne te la posera pas... La Sprint Review, c’est ton moment. Si tu le laisses passer, le prochain PI repart de zéro et toi aussi. Prends le résultat le plus visible de ta dernière Sprint Review. Remplis les 3 lignes. Entraîne-toi à les dire à voix haute avant la prochaine. Et toi, tu nommes ta contribution en Sprint Review ? Ou tu laisses “l’équipe a bien livré” faire tout le travail ? [Tu veux savoir où sont tes angles morts ? Passe le test.](https://sm-score.collaborationsolved.com/?ref=collaborationsolved.com) ![](https://storage.ghost.io/c/69/5a/695addfe-1c1d-4828-b10c-8f9c23732c07/content/images/2026/08/signpc-1.png) ### Tu as déjà les preuves. Tu ne les as pas vues. URL: https://collaborationsolved.com/preuves-impact-scrum-master-invisibles/ Last updated: 2026-08-26T01:38:24.000Z ![](https://storage.ghost.io/c/69/5a/695addfe-1c1d-4828-b10c-8f9c23732c07/content/images/2026/05/revue-1.jpg) J'ai parlé à un SM la semaine dernière. Il était plus sûr d'avoir une valeur ajoutée dans son équipe. Je l'ai fait penser à l'envers... > Moi : Donne moi un exemple d'amélioration dans ton équipe ces derniers temps ?SM : La vélocité à augmenté entre les PI. > Moi : De combien ? Tu as un chiffre en tête? > SM : Avant il était à 12 story par PI et au dernier il en avaient fini 50. > Moi : Qu'est-ce qu'ils ont fait pour s'améliorer ? > SM : Ils découpent leurs stories en plus petit. > Moi : Et, ils ont fait ça tout seuls ? C'était leur idée ? > SM: Hum. Ils étaient pas convaincus, j'ai monté un atelier pour leur montrer comment faire. > Moi : Combien de temps pour faire cet atelier? > SM: Deux sessions d'une heure. Je lui ai relu l'histoire dans le bon sens. - Ce qui se passait avant : L'équipe finissait 12 items en moyenne par PI - Ce que le SM a fait : 2 x 1h d'ateliers de découpage de story. - Le résultat : L'équipe découpe le travail en petit morceaux, au PI suivant le Throughput est multiplié par 4. Il avait pas fait le lien... Et calculer ce que ça rapporte l'a choqué. Il était pas prêt. ![](https://embed.filekitcdn.com/e/ceUmuVEEjJAQ8u3zcvM6Zp/h4bZ9DoZNdaGGmCeHY22WC/email) 1.0 M$ d'impact sur 3 mois. Équivalent de 4.1 M$ projeté sur l'année. Pas de magie : quand le coût par livrable passe de 28K$ à 7K$ et que l'équipe livre 4x plus, ça se chiffre. C'est la même logique que ton directeur financier utilise. ## **Voici le Continuous Improvement Financial Impact Calculator!** Tu rentres le Throughput de ton équipe sur deux moments dans le temps, la taille de l'équipe, le taux horaire moyen. Il traduit la différence en dollars. ### Ouvre-le. Entre les chiffres de tes 3 derniers mois. Dis-moi ce qui te choque le plus ! ​[Lien vers le CI Financial Impact Calculator](https://pcdenant.github.io/Continuous-Improvement-Calculator/?ref=collaborationsolved.com)​ La plupart des SMs arrivent en revue avec des activités. Pas parce qu'ils n'ont rien fait. Parce qu'ils ont jamais relu l'histoire dans le bon sens. Ce chiffre, tu le mets dans ta revue. En support de ton récit, pas à la place. Ton manager peut ignorer "j'ai animé des ateliers". Il peut pas ignorer un montant en dollars. [SM Survival Score : Quels sont tes angles morts ?](https://sm-score.collaborationsolved.com/?ref=collaborationsolved.com) ![](https://storage.ghost.io/c/69/5a/695addfe-1c1d-4828-b10c-8f9c23732c07/content/images/2026/08/signpc-1.png) ### Ça fonctionne mais pas comme prévu. URL: https://collaborationsolved.com/ca-fonctionne-mais-pas-comme-prevu/ Last updated: 2026-08-26T01:38:10.000Z ![](https://storage.ghost.io/c/69/5a/695addfe-1c1d-4828-b10c-8f9c23732c07/content/images/2026/05/pas-eu-le-temps-1.jpg) Je donne pas des outils que je teste pas moi-même... Alors cette semaine, j'ai fait mon propre [email du vendredi](https://collaborationsolved.com/email-vendredi-scrum-master-prouver-impact) à mon manager et mon directeur. Voilà ce que j'ai appris. Le [format original](https://collaborationsolved.com/email-vendredi-scrum-master-prouver-impact) était : \[Ce que j'ai fait + Résultat + Ce qui se passait avant\] En relisant ce que j'avais écrit, j'ai vu le problème. Ça se lisait comme un rapport hebdo. Alors je change l'ordre : ## **Le message au manager hebdo** **Avant :** \[le problème qui existait\], **Ce que j'ai fait :** \[l'action concrète\], **Ce qui s'est passé :** \[le résultat\] Tu pars du problème, comme ça quelqu'un qui lit ça sans contexte comprend tout de suite. C'était pas 3 lignes non plus... J'ai eu une grosse semaine. En fait, j'ai tout vidé, un brain dump complet avant le weekend. Et bizarrement, ça m'a aidé à décompresser. Mais j'ai pas listé tout ce que j'avais fait. Seulement les moments où j'avais eu un impact significatif. J'ai ajouté des citations directes de personnes impliquées. Du genre : "Il m'a dit que...". Ça donne un point de vue externe, vérifiable si quelqu'un veut creuser. Et j'ai posé des questions sur mes prochaines étapes. Pas pour avoir du buy-in, pour orienter : "Je compte faire A ou B. Lequel vous semble plus pertinent ?" J'imagine que ces questions-là vont structurer mon prochain 1-1. Dernier truc : je l'ai envoyé sur Teams dans un chat avec mon manager et mon directeur. Pas par email. Ça me paraissait trop formel. Maintenant à toi. Tu l'as testé cette semaine ? Qu'est-ce que t'as adapté ? Tu l'as pas testé ? Qu'est-ce qui t'a arrêté ? [SM Survival Score : Quels sont tes angles morts ?](https://sm-score.collaborationsolved.com/?ref=collaborationsolved.com) ![](https://storage.ghost.io/c/69/5a/695addfe-1c1d-4828-b10c-8f9c23732c07/content/images/2026/08/signpc-1.png) ### Le PO ne vient plus à ta retro ? URL: https://collaborationsolved.com/retrospective-desertee-scrum-master-quoi-faire/ Last updated: 2026-08-26T01:37:56.000Z ![](https://storage.ghost.io/c/69/5a/695addfe-1c1d-4828-b10c-8f9c23732c07/content/images/2026/05/po-pas-dispo-1.jpg) Ma PO venait au début... Elle s'asseyait, observait et disait pas grand-chose. À un moment j'aurais dû me demander pourquoi. À l'époque je m'en félicitais : "Elle respecte la dynamique de l'équipe." Un sprint, on a parlé des requis pas prêts. Pas méchamment hein, mais les développeurs ont nommé les choses. Elle était là et elle s'est sentie attaquée... Sprint suivant : son agenda est plein. Sprint d'après : elle à un appel urgent. Puis, elle est jamais revenue... Le truc c'est que son absence, c'était pas un problème d'agenda. C'était un signal : l**a rétro ne valait pas son temps.** Envoyer un email pour rappeler l'importance de la "cérémonie" ça change quoi, si la rétro ne produit rien de tangible ? **Avant d'envoyer quoi que ce soit, 2 questions :** 1.Est-ce que la dernière rétro a produit quelque chose de visible pour la livraison ? 2.Est-ce que ton PO est au courant ? Si tu as répondu non aux 2 : l'invitation ne sert à rien. C'est demander au PO de revenir alors qu'il n'y a pas de valeur. Ce dont il (elle) a besoin d'abord, c'est une preuve. ## **Le compte-rendu de rétro en langage business** Trois lignes. Après chaque rétro. Tu envoies ça au PO. Sprint \[x\] - Ce qu'on a réglé : \- Problème : \[Concret, pas du ressenti\] ex : "Les tests manuels prenaient 3 jours. On en parle depuis 2 sprints." \- Décision : \[L'action\] ex : "On automatise les 5 cas les plus fréquents d'ici jeudi." \- Impact : \[Pour la livraison : volume, temps, qualité, ou coûts\] ex : "Si ça tient, on récupère 2 jours par sprint d'ici 3 semaines." Pas de jargon, pas de "sécurité psychologique", pas de "comment on s'est senti". De la livraison, du volume, du temps, de la qualité, du coût. Au bout de 2 sprints, il va commencer à se demander ce qui se passe dans cette réunion. Et, c'est là que tu l'invites. ### **Ton expérimention de cette semaine** \- Problème : Mon PO ne vient plus en retro depuis \[x\] sprints. \- Hypothèse : Si j'envoie un compte-rendu de rétro de 3 lignes orienté livraison après la prochaine rétro, alors mon PO va commencer à voir ce que cette réunion produit. \- Signal : Il répond à l'email, ou il mentionne la rétro au planning, ou pose une question sur un problème qu'on a nommé. 48h plus tard, tu remplis ça : \- Que c'est-il passé ? Qu'est-ce qu'on fait ? (Standardise / Pivote / Abandonne) Je suis curieux de voir ce qui va se passer dans 48h... Tiens moi au courant. PS : Ça fonctionne aussi pour montrer au management ce qui se passe en rétro ;) [SM Survival Score : Quels sont tes angles morts ?](https://sm-score.collaborationsolved.com/?ref=collaborationsolved.com) ![](https://storage.ghost.io/c/69/5a/695addfe-1c1d-4828-b10c-8f9c23732c07/content/images/2026/08/signpc-1.png) ### L'équipe aurait pu faire ça sans toi. URL: https://collaborationsolved.com/valeur-ajoutee-scrum-master-equipe-autonome/ Last updated: 2026-08-26T01:37:42.000Z ![](https://storage.ghost.io/c/69/5a/695addfe-1c1d-4828-b10c-8f9c23732c07/content/images/2026/05/j-ai-coach---1.jpg) 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 ? [SM Survival Score : Quels sont tes angles morts ?](https://sm-score.collaborationsolved.com/?ref=collaborationsolved.com) ![](https://storage.ghost.io/c/69/5a/695addfe-1c1d-4828-b10c-8f9c23732c07/content/images/2026/08/signpc-1.png) ### Un daily de 45min. Normal ? URL: https://collaborationsolved.com/daily-scrum-trop-long-45-minutes/ Last updated: 2026-08-26T01:37:24.000Z ![](https://storage.ghost.io/c/69/5a/695addfe-1c1d-4828-b10c-8f9c23732c07/content/images/2026/05/jeudi15h-1.jpg) Jeudi 15h, 4 daily depuis lundi matin. Personne a dit un mot sur cette carte bloquée... L'équipe sait. Mais le daily n'est pas le moment où ça remonte, c'est le moment où chacun dit ce qu'il a fait, on coche "présent", et on repart. 45 min ou 12 min chrono, le résultat peut être le même. \-Le daily de 45 min déclenche une question dans la tête de ton manager : "L'équipe fait quoi pendant tout ce temps ?" \-Un daily expédié en 12 min, personne ne demande rien. Ça passe. Mais si personne ne parle d'obstacle, que le plan ne bouge pas, que chacun repart dans son coin, c'est autant de temps dépensé sans résultat. ## **La durée d'une réunion est un signal de dysfonction. Pas la cause.** ​[La grille en lien mesure ce qui se passe pendant le daily.](https://docs.google.com/document/d/1YS-dyicjscrIr81dO2J1rBsz2rpmqKgloGRyF1Srcgg/edit?usp=sharing&ref=collaborationsolved.com)​ Remplis-la pendant ton prochain daily, pas après. C'est 5 questions. Tu score de 1 à 3 avec un total sur 15. ### **Ton expérimentation 48h de la semaine** Note ton score et le critère le plus faible. C'est tout. Pas de changement immédiat. Juste de l'observation. Au prochain daily, ton attention va sur ce critère. Si tu veux me partager ton score, réponds à cet email. Je lis tout. [SM Survival Score : Quels sont tes angles morts ?](https://sm-score.collaborationsolved.com/?ref=collaborationsolved.com) ![](https://storage.ghost.io/c/69/5a/695addfe-1c1d-4828-b10c-8f9c23732c07/content/images/2026/08/signpc-1.png) ### Ça va ? Non, en fait. URL: https://collaborationsolved.com/equipe-dit-ca-va-scrum-master-silence/ Last updated: 2026-08-26T01:37:11.000Z ![](https://storage.ghost.io/c/69/5a/695addfe-1c1d-4828-b10c-8f9c23732c07/content/images/2026/05/--a-va--1--1.jpg) Tu attends la rétro pour trouver les problèmes ? Les frictions existent pendant le sprint : En daily, pendant les pauses, quand quelqu'un soupire en poussant du code, quand un dev reste tard, quand l'équipe rigole moins... L'angle mort dont on parle peu : Croire que la rétro sert à discuter des problèmes. En réalité, la rétro sert à les régler. ​Mais tu peux pas les régler si tu ne les as pas détectés avant. ## **Les 3 relances** Pendant le sprint (daily, 1-on-1, ou pauses), tu captures un signal : un ralentissement, une frustration, un silence. Tu ne laisses pas passer. Voici 3 *Breakthroughs* (les questions qui ouvrent) et 2 questions génériques pour creuser. Breakthroughs : pose-en une seule - **T'as eu un moment cette semaine où tu aurais aimé avoir de l'aide ?** **​**"J'aurais aimé" crée de l'espace. C'est pas accusateur. - **Quelque chose t'a ralenti sans que tu l'aies prévu ?** **​**Tu nommes le ralentissement, pas la personne. - **Y a un truc sur lequel tu t'es demandé si on faisait bien ?** **​**Toujours dans la curiosité, pas dans le jugement. Creuser : deux questions génériques Une fois que le signal sort, pose ces deux questions dans l'ordre : - **Qu'est-ce qui fait que \[le signal\] ?** **​**Pas "pourquoi" mais "qu'est-ce qui fait que" sonde la cause sans accuser. - **Qu'est-ce qui fait qu'on n'a pas vu ça plus tôt ?** **​**Tu remontes au système, pas à la personne. Exemple : *SM : "Quelque chose vous à ralenti sans que ce soit prévu ?"* *Dev : "Moi, j'ai bien galéré cette semaine !"* *SM : "Qu'est-ce qui fait que tu as galéré ?"* *Dev : "La doc du logging était obsolète."* *SM : "Qu'est-ce qui fait qu'on n'avait pas cette doc à jour ?"* *Dev : "Personne n'a pensé à la mettre à jour après le refacto"* *SM : "OK. On prend ça en retro. Vous proposez quoi ?"* Problème détecté PENDANT le sprint. Possibilité de le régler PENDANT le sprint, pas juste en parler après. ### **Ton expérimentation 48h** Cette semaine, pendant le daily ou une pause, pose une question *breakthrough* dès que tu sens un signal. Creuse avec les 2 questions. Ça prend 3 minutes. Tu vas remplir ta rétro de vrais trucs à régler, pas de discussions. Quel signal tu captures aujourd'hui mais tu repousses à la rétro ? Envoie-le moi. Je lis tout. [SM Survival Score : Quels sont tes angles morts ?](https://sm-score.collaborationsolved.com/?ref=collaborationsolved.com) ![](https://storage.ghost.io/c/69/5a/695addfe-1c1d-4828-b10c-8f9c23732c07/content/images/2026/08/signpc-1.png) ### Transforme un obstacle en chiffre URL: https://collaborationsolved.com/chiffrer-impact-obstacle-resolu-scrum-master/ Last updated: 2026-08-26T01:36:58.000Z ![](https://storage.ghost.io/c/69/5a/695addfe-1c1d-4828-b10c-8f9c23732c07/content/images/2026/05/marchepas-1.jpeg) Alex, une lectrice de la newsletter m'a raconté cette histoire la semaine dernière (partagé avec sa permission) : Une carte est bloquée dans mon équipe depuis 20 jours. Chaque matin au daily, le même échange : > \-Le dev : "Ma carte est bloquée, je ne peux pas tester, l'environnement ne marche pas." > \-Le QA : "Mais si, l'environnement fonctionne, il n'y a pas de problème." > 20 jours de suite... Cette semaine, j'ai dit "OK, montre-nous ton écran", le dev a partagé son écran. En 10 min, tout le monde a vu le problème. Une erreur de syntaxe, un point au mauvais endroit et le code qui passait pas. Le dev corrige live, relance, ça passe et c'est résolu. **20 jours de blocage. 10 minutes pour le régler. Il suffisait de quelqu'un qui dise "montre-nous."** C'est ça, le travail invisible d'un SM. Personne ne va mettre "j'ai demandé à un dev de partager son écran" dans un rapport trimestriel. Et pourtant, sans cette phrase, la carte restait bloquée. Encore combien de temps ? Alexandra l'estime à 3-4 jours. On le saura jamais avec certitude. Mais on peut le chiffrer. ## Calculateur d'impact des déblocages. Tu bouges les curseurs, tu obtiens deux chiffres : ce que le blocage a coûté, et ce que ton intervention a évité. Et une phrase prête à copier. [![](https://embed.filekitcdn.com/e/ceUmuVEEjJAQ8u3zcvM6Zp/hbe2qzcTmMgiKx3emdYdBU/email)](https://pcdenant.github.io/impediment-value-calculator/?ref=collaborationsolved.com) [Essaye le !](https://pcdenant.github.io/impediment-value-calculator/?ref=collaborationsolved.com) Maintenant, imagine qu'Alex envoie ça dans son email du vendredi : *Carte bloquée depuis 20 jours. Résolu en 10 minutes en demandant un partage d'écran (erreur de syntaxe). Coût du blocage : 10K$ (80h de capacité immobilisée). Sans intervention, le blocage aurait continué au moins 4 jours. Coût évité estimé : 4000$.* Son manager ne regardera plus son SM de la même façon après un email comme ça... [SM Survival Score : Quels sont tes angles morts ?](https://sm-score.collaborationsolved.com/?ref=collaborationsolved.com) ![](https://storage.ghost.io/c/69/5a/695addfe-1c1d-4828-b10c-8f9c23732c07/content/images/2026/08/signpc-1.png) ### Le email du vendredi (5 min) URL: https://collaborationsolved.com/email-vendredi-scrum-master-prouver-impact/ Last updated: 2026-08-26T01:36:43.000Z ![](https://storage.ghost.io/c/69/5a/695addfe-1c1d-4828-b10c-8f9c23732c07/content/images/2026/05/je-fais-les-daily-1.jpg) Un SM que je coache a changé une seule question dans son daily. Au lieu de "qu'avez-vous fait hier ?", il a demandé "qu'est-ce qu'on peut finir aujourd'hui ?" Une carte bougeait plus depuis quelques jours. Personne n'en avait parlé avant. L'équipe a proposé d'aller voir directement ceux qui bloquaient. Le lendemain, c'était réglé. La carte était terminée 48h plus tard. Son manager ? Il n'en a rien su. Le SM n'a jamais pris 5 minutes pour lui écrire ce qui s'était passé. Le résultat existe. Mais la preuve, non. Et sans preuve, ça n'a jamais eu lieu. ## **Le format : 3 lignes, chaque vendredi** Copie ce format. Remplis-le avec ta semaine. Envoie-le à ton manager par Slack ou par email. Cette semaine, j'ai \[action\]. Résultat : \[ce qui a changé\]. Avant : \[comment c'était\]. Voici à quoi ça ressemble quand c'est rempli. Cette semaine, j'ai changé la question du daily : "qu'est-ce qu'on peut finir aujourd'hui ?" au lieu du tour de table habituel. Résultat : une carte bloquée depuis 4 jours est devenue visible, la dépendance a été réglée en 24h. Avant, les blocages restaient invisibles jusqu’à la fin du sprint. ### **Fais ça cette semaine** Vendredi, avant de fermer ton ordi, envoie ton premier message. Un seul. Avec ta semaine dedans. 4 vendredis de suite = 4 traces écrites de ce que ton poste produit. Un dossier qui se construit tout seul. [SM Survival Score : Quels sont tes angles morts ?](https://sm-score.collaborationsolved.com/?ref=collaborationsolved.com) ![](https://storage.ghost.io/c/69/5a/695addfe-1c1d-4828-b10c-8f9c23732c07/content/images/2026/08/signpc-1.png) ### Ton manager peut-il décrire ce que tu fais ? URL: https://collaborationsolved.com/ton-manager-comprend-il-ton-role-scrum-master/ Last updated: 2026-08-26T01:36:30.000Z ![](https://storage.ghost.io/c/69/5a/695addfe-1c1d-4828-b10c-8f9c23732c07/content/images/2026/05/ton-manager-sais-pas-ce-que-tu-fais-1.jpg) Cette scène, tu l'as peut-être vécue. Pas forcément avec ces mots exacts. Mais le moment où quelqu'un résume ton rôle aux réunions, et toi tu ne sais pas quoi corriger sans avoir l'air sur la défensive... Tu as une image de ton rôle. Ton manager en a une autre. Et tant que les deux ne sont pas alignées, tu défends un poste que personne ne voit de la même façon que toi. C'est ça, l'angle mort. ## **Le test des 5 niveaux** J'ai classé 5 façons dont un manager décrit un SM. De la plus dangereuse à la plus solide. Lis les 5 phrases. Choisis celle qui ressemble le plus à ce que TON manager dirait de toi à un directeur. Sois honnête. **Niveau 1** : " Gère les cérémonies Scrum. " ​**Niveau 2** : " Aide l'équipe à bien collaborer. " ​**Niveau 3** : " Fait en sorte que l'équipe livre mieux. " ​**Niveau 4** : " Réduit nos délais et nos risques de livraison. " ​**Niveau 5** : " C'est grâce au SM que cette équipe performe. Je me battrais pour le garder. " Si t'es à 1 ou 2 : ton manager te voit comme un rôle de support. Utile, mais facile à couper. C'est pas un jugement sur ta compétence, c'est un gap dans ta visibilité. Si t'es à 3 : tu es reconnu, mais remplaçable. Un autre SM pourrait prendre ta place sans que ça change grand-chose dans la tête de ton manager. 4 ou 5 : ton impact est visible. Ton manager sait quoi dire pour te défendre. ​[La grille détaillée est ici → Google Doc](https://docs.google.com/document/d/e/2PACX-1vQblITMUX4I77wBmL6nfwIFXSCk4L6irUGrbE4vvJpzuF%5FdFSGBMLSn7aruPqu5RREmMuCteoyADWJ0/pub?ref=collaborationsolved.com). Pour chaque niveau : ce que ça veut dire, le risque que tu portes, et un geste pour monter d'un niveau. ### **Ton action cette semaine** Choisis ton niveau. Note-le. C'est ton point de départ. --- Si t'as fait le **SM Survival Score,** compare avec ton résultat « Visibilité de l'impact ». Si les deux racontent la même chose, tu sais où bosser. ​ [SM Survival Score : Quels sont tes angles morts ?](https://sm-score.collaborationsolved.com/?ref=collaborationsolved.com) ![](https://storage.ghost.io/c/69/5a/695addfe-1c1d-4828-b10c-8f9c23732c07/content/images/2026/08/signpc-1.png)