Questions d'entretien Scrum Master

La résistance à Scrum vient généralement de trois sources : de mauvaises expériences passées avec un cadre mal implémenté, la peur que la transparence expose les performances individuelles, ou un véritable décalage entre Scrum et le type de travail réel de l'équipe. Ma première étape est d'écouter plutôt que de défendre le cadre. Je mène des entretiens individuels pour comprendre les objections spécifiques et identifier les tendances. Si la résistance porte sur de mauvaises pratiques passées, je l'admets et je distingue ce que nous ferons différemment. Si elle porte sur la transparence, j'aide l'équipe à comprendre que les cérémonies Scrum la protègent du travail non planifié et des attentes irréalistes. Si le travail ne correspond genuinement pas à Scrum, j'explore Kanban ou une approche hybride plutôt que d'imposer un cadre à une équipe pour qui il ne fonctionnera pas. Mon rôle est de servir l'équipe, pas d'imposer une méthodologie.

Une rétrospective qui ressemble à un exercice de façade signifie généralement que l'équipe ne croit pas que ses retours mènent à des changements. Ma première action est d'ouvrir la session en passant en revue les actions issues de la rétrospective précédente et en étant honnête sur ce qui s'est passé pour chacune. Si la moitié n'ont pas été suivies, je le nomme. Ensuite, je change le format : au lieu de la même structure "ce qui a bien marché / ce qui pourrait être amélioré", j'essaie une technique différente, comme un exercice de timeline, un radar du bonheur ou une rétrospective "voilier". Ces approches changent l'énergie et suscitent des conversations différentes. Je réduis aussi le nombre d'actions à une ou deux, avec un propriétaire précis et une définition de terminé. Les équipes se désengagent des rétrospectives quand elles produisent de longues listes que personne n'applique.

La différence fondamentale porte sur l'autorité et la responsabilité. Un chef de projet possède généralement la livraison : il détient le planning, le budget et la responsabilité d'atteindre les jalons. Un Scrum Master possède le processus : il facilite, accompagne et lève les obstacles, mais il ne possède pas ce qui est construit ni quand cela est livré. Un chef de projet manage des personnes vers un plan. Un Scrum Master permet à une équipe de se gérer elle-même. En pratique, de nombreuses organisations recrutent des Scrum Masters mais les traitent comme des chefs de projet, ce qui est l'une des causes les plus fréquentes de dysfonctionnement agile. Mon rôle est de coacher l'équipe vers l'auto-organisation, d'animer les cérémonies et de protéger l'équipe des interférences externes.

L'équipe avec laquelle je travaillais perdait deux à trois heures par sprint dans un processus manuel de promotion d'environnement géré par une équipe infrastructure séparée. Chaque déploiement nécessitait un ticket, un délai d'attente et des étapes manuelles que seules deux personnes dans l'organisation savaient effectuer. J'ai d'abord cartographié l'impact complet sur plusieurs équipes et chiffré : environ 25 personnes-heures par sprint sur trois équipes Scrum. J'ai ensuite apporté ces données au directeur technique et proposé un spike de 30 jours pour automatiser le processus. J'ai facilité la collaboration entre l'équipe dev et l'équipe infrastructure et tenu les deux parties informées. L'automatisation a pris quatre semaines et a réduit le temps de promotion d'environnement de 90 minutes à moins de cinq. La leçon que j'en ai tirée : les obstacles qui ressemblent à de petits inconvénients sont souvent des blocages systémiques déguisés.

Deux développeurs seniors de l'équipe avaient une tension persistante sur les standards de revue de code. L'un prônait des revues approfondies avec des commentaires détaillés ; l'autre trouvait le processus lent et décourageant. Le conflit se manifestait dans les stand-ups sous forme de désaccord passif et ralentissait le débit des pull requests. J'ai mené un exercice structuré bref lors d'une rétrospective : les deux développeurs ont écrit indépendamment leur définition d'une bonne revue de code, puis nous les avons comparées. Leurs valeurs fondamentales étaient en réalité alignées, mais ils étaient en désaccord sur le temps investi et le style des commentaires. Nous avons convenu d'un accord de travail : les revues seraient finalisées dans les 24 heures et les commentaires distingueraient les problèmes bloquants des suggestions. En deux sprints, le délai de cycle des PR a baissé de 30% et la tension interpersonnelle s'était largement dissipée.

Le Product Owner avec lequel je travaillais avait un backlog de plus de 200 éléments, dont beaucoup étaient vagues et non estimés. Les sessions de sprint planning dépassaient régulièrement le temps imparti et se terminaient avec une équipe incertaine de ses engagements. J'ai mené un entretien individuel avec le PO et recadré le backlog comme un outil de communication, pas un système d'archivage. Nous avons convenu d'une règle simple : les 20 premiers éléments doivent être prêts pour le sprint, définis par une Définition de Prêt légère (critères d'acceptation clairs, estimés, sans dépendances non résolues). J'ai animé une session de chirurgie du backlog de deux heures où nous avons fermé 60 éléments qui n'avaient pas été touchés depuis six mois. Les sessions de sprint planning sont passées de 3 heures à 90 minutes en un mois.

J'utilise un mélange de signaux quantitatifs et qualitatifs. Côté quantitatif, je suis la tendance de la vélocité (pas le chiffre absolu, mais sa stabilité ou sa volatilité), le taux d'atteinte des objectifs de sprint et le ratio entre travail planifié et non planifié à chaque sprint. Une équipe avec beaucoup de travail non planifié a généralement un problème de protection, pas de capacité. Côté qualitatif, j'effectue une vérification de santé d'équipe trimestrielle avec un radar léger : nous nous évaluons sur la collaboration, la clarté des objectifs, la sécurité psychologique et la confiance dans le processus. Les scores importent moins que la conversation qu'ils suscitent. Je surveille aussi les sprint reviews : si les parties prenantes sont régulièrement surprises par ce que l'équipe a construit, quelque chose s'est cassé dans la boucle de communication.

La première chose que je fais est de diagnostiquer la cause plutôt que de supposer que l'équipe sous-performe. Les raisons les plus fréquentes sont : des stories trop grandes mal décomposées, une vélocité surestimée par un optimisme lors du planning, trop de travail non planifié en milieu de sprint, ou une Définition de Terminé appliquée de façon incohérente. J'examine les trois à cinq derniers sprints et catégorise les stories incomplètes par cause racine. Si les stories sont trop grandes, j'anime un atelier de découpage. Si l'équipe sur-s'engage, j'introduis une zone tampon dans le planning. Si les interruptions en milieu de sprint sont le problème, je travaille avec les parties prenantes pour créer un canal formel pour les demandes urgentes qui ne contourne pas le processus Scrum.

La résistance au changement dans les équipes porte presque toujours sur l'incertitude et la perte de compétence. Les personnes expertes dans la façon de travailler actuelle redeviennent soudainement des débutants, ce qui est inconfortable. Mon approche est de rendre la transition progressive et de distinguer le temps d'apprentissage du temps de livraison, pour que l'équipe ne soit pas attendue à pleine vélocité tout en apprenant une nouvelle technologie ou un nouveau processus. J'organise des sessions de binômage entre ceux qui sont plus à l'aise avec le changement et ceux qui le sont moins. J'ajuste les engagements de sprint à la baisse pendant la période de transition et je communique cet ajustement aux parties prenantes de façon proactive. Je tiens aussi une rétrospective structurée à mi-parcours de la transition pour vérifier si l'approche fonctionne.