Entretien Scrum Master : répondre aux cas de conflit, de sprint et de rétrospective

En entretien Scrum Master, expliquez comment vous intervenez quand une discussion sur le travail tourne aux accusations. Réciter les événements Scrum ne suffit pas à expliquer comment vous rendez un obstacle visible, préservez les responsabilités de chacun et vérifiez qu’une amélioration a réellement été essayée.

Ce cas original porte sur des éléments reportés pendant trois Sprints et une dépendance d’interface que personne n’avait explicitée. Préparez une intervention, un court dialogue de facilitation et une lecture prudente des résultats. Pour commencer, travaillez Resolve Poor Team Collaboration: Identify Issues, Implement Solutions en distinguant observation, hypothèse et action.

Périmètre des preuves : le Guide Scrum, Scrum.org et le Manifeste Agile fondent les quelques règles citées. L’équipe, les données, les échanges et les résultats sont fictifs ; ils ne décrivent ni une entreprise ni des témoignages de candidats. Sept vérifications Python contrôlent la cohérence des chiffres. Elles ne prouvent pas l’efficacité d’une intervention auprès d’une équipe réelle.

Clarifier le problème avant de proposer un rituel

L’équipe développe un portail permettant à un locataire de suivre une demande de réparation. Quatre Developers travaillent avec un Product Owner et un Scrum Master. L’Objectif de Sprint concerne le suivi du statut ; certaines vues dépendent d’un format d’événement fourni par une autre équipe. Les Developers connaissent cette dépendance, mais elle n’apparaît pas clairement dans leur plan.

Après trois Sprints, le frontend dit : « Le backend nous livre toujours trop tard. » Le backend répond : « Les écrans changent dès que nous terminons. » Le Product Owner propose de sélectionner davantage de travail pour compenser les reports. Aucun de ces énoncés ne suffit à expliquer ce qui a empêché l’équipe d’atteindre son objectif.

Demandez d’abord un exemple précis : quel élément, quelle information attendue, à quelle date et avec quelle conséquence ? Dans le cas, un exemple de payload attendu en début de Sprint n’a été partagé qu’au huitième jour. Cela a retardé une vérification d’intégration. L’observation ne désigne pas encore une personne fautive ni la cause unique de tous les reports.

Le Guide Scrum en français attribue aux Developers l’adaptation de leur plan vers l’Objectif de Sprint, au Product Owner la gestion du Product Backlog, et au Scrum Master l’efficacité de l’équipe. Cette répartition ne fait pas du Scrum Master le répartiteur quotidien des tâches. Votre intervention doit aider l’équipe à décider, sans reprendre toutes ses décisions.

En entretien, annoncez votre première intention : « Je veux rendre la dépendance et son effet visibles, puis aider l’équipe à adapter son plan. Je ne conclurais pas à un manque d’engagement à partir des seuls reports. » Cette phrase donne un cap et laisse la place à des informations qui peuvent contredire votre hypothèse.

Lire les reports sans transformer un ratio en jugement

Voici les données fournies. Chaque ligne compte des sélections d’éléments pour un Sprint, pas des personnes ni des unités de valeur. Un élément repris dans deux Sprints peut donc être compté dans deux sélections. « En attente du contrat » est une annotation du cas, qui doit être vérifiée avec l’équipe.

Au total, dix sélections sur vingt-sept ne sont pas terminées, soit environ 37,0 %. Sept de ces dix portent l’annotation d’attente. Ces sept annotations justifient d’examiner la dépendance d’interface. Elle ne montre pas que sept éléments uniques ont échoué pour la même raison, ni que l’équipe externe est responsable de tout le retard.

Le nombre d’éléments terminés ne mesure pas directement la valeur livrée ou l’atteinte de l’Objectif de Sprint. Les éléments peuvent avoir des tailles très différentes. Deux demandes simples ne sont pas équivalentes à deux intégrations complexes. Évitez de convertir ce tableau en classement de performance individuelle ou en objectif mécanique de « zéro report ».

Vérifiez aussi la qualité de l’annotation. « Attente du contrat » signifie-t-il absence de payload, règle métier ambiguë, indisponibilité de l’environnement ou choix de différer le travail ? Ces situations nécessitent des actions différentes. Demandez des exemples datés pour distinguer les causes que cette catégorie regroupe.

Une question d’entretien probable, sans prétendre à un processus d’entreprise, serait : « Pourquoi ne pas réduire immédiatement l’engagement ? » Vous pouvez répondre que réduire le travail sélectionné est une option à discuter, mais qu’elle ne rend pas la dépendance visible. L’équipe pourrait sélectionner moins d’éléments et rencontrer le même blocage sur chacun.

Faciliter le désaccord en conservant le sujet technique

Le Manifeste Agile invite notamment à travailler ensemble et à ajuster régulièrement la manière de faire. Il ne fournit pas un script obligatoire de résolution de conflit. Le dialogue suivant est une technique proposée pour ce cas, à adapter au contexte et à la sécurité de la conversation.

Frontend : « On attend toujours après eux. »

Scrum Master : « Prenons le suivi de réparation R42. Quelle information manquait pour terminer la vérification, et quand l’avons-nous demandée ? »

Backend : « Nous avions le nom du statut, mais pas la règle pour les événements reçus dans le désordre. »

Scrum Master : « Nous avons donc deux besoins : un exemple de message et une règle de traitement. Qui doit participer pour les préciser, et quelle décision pouvons-nous prendre avant demain ? »

Product Owner : « Le suivi du statut reste prioritaire ; l’historique détaillé peut être discuté. »

Scrum Master : « Vérifions avec les Developers quelle adaptation conserve un suivi utilisable et quels points restent à confirmer avec l’équipe d’interface. »

La reformulation change le sujet de la discussion : on passe de « toujours » à une information manquante et une décision. Vous n’avez pas tranché le contrat technique à la place des Developers ni imposé un nouveau périmètre au Product Owner. Vous avez rapproché les personnes capables de clarifier le problème.

Si la conversation devient personnelle, interrompez l’attaque et reformulez le comportement observable. Si une personne se tait, proposez un temps d’écriture individuelle ou un tour de parole, sans lui demander de s’exposer devant tous. Un soupçon de harcèlement ou un problème de santé nécessite les canaux adaptés ; une rétrospective ne remplace pas ces prises en charge.

Agir pendant le Sprint sans attendre la rétrospective

Un obstacle identifié aujourd’hui ne doit pas attendre la fin du Sprint pour être discuté. Dans le cas, aidez l’équipe à réunir les personnes concernées par l’interface, à nommer la décision attendue et à rendre visible son effet sur l’objectif. Une note de suivi peut indiquer le responsable du contact, la décision attendue et l’heure du prochain point, sans devenir un reporting permanent au Scrum Master.

Selon le Guide Scrum, le Daily Scrum sert aux Developers à inspecter leur progression vers l’objectif et à adapter leur plan. Ce n’est pas une réunion obligatoire de compte rendu au Scrum Master. Une discussion technique détaillée peut suivre avec les personnes nécessaires, plutôt que monopoliser tout l’événement.

Les Developers peuvent proposer une adaptation du plan et discuter du périmètre avec le Product Owner. Si une démonstration utilise un faux backend, dites-le explicitement : elle peut aider à clarifier un écran, mais ne prouve pas une intégration utilisable. Ne présentez pas comme terminé un élément qui ne respecte pas la Definition of Done pour améliorer le tableau.

Une équipe externe peut ne pas pouvoir répondre avant plusieurs jours. Rendez alors l’arbitrage visible : poursuivre un autre travail pertinent, réduire une partie du périmètre en préservant l’objectif, ou traiter la dépendance à un niveau organisationnel. « Escalader » doit préciser le blocage et la décision recherchée, pas simplement mettre un manager en copie.

Le Scrum Master peut aider à lever l’obstacle et à améliorer la coordination. Il ne promet pas à la place de l’équipe externe une date qu’elle n’a pas acceptée. En entretien, dites ce qui dépend de vous : rendre le problème visible, obtenir une discussion et suivre une décision. Distinguez cela d’un résultat technique encore incertain.

Choisir une expérimentation de rétrospective vérifiable

La ressource Scrum.org sur la Sprint Retrospective propose de rendre les améliorations visibles et de choisir peu d’actions. Elle précise aussi que la facilitation n’appartient pas obligatoirement au Scrum Master. Pour notre cas, l’équipe choisit une expérimentation centrée sur la dépendance plutôt qu’un nouveau rituel général.

Avant de sélectionner un élément dépendant de l’interface, les personnes concernées relisent ensemble un exemple de message, la règle de traitement et l’inconnue restante. Une personne est identifiée pour suivre la clarification avec l’équipe partenaire. L’objectif n’est pas d’obtenir une spécification exhaustive avant de commencer ; il est de rendre explicites les dépendances qui peuvent bloquer un résultat utilisable.

Cette pratique est une convention expérimentale de l’équipe, pas un artefact Scrum obligatoire ou une Definition of Ready imposée par le Guide. Si elle devient une file d’attente d’approbation ou un prétexte pour refuser tout travail incertain, elle produit un nouveau problème. Convenez d’un périmètre limité et d’une date de réexamen.

Précisez comment observer l’essai : quels éléments ont eu une clarification avant sélection, quelles inconnues ont été découvertes ensuite et combien de temps elles ont bloqué une vérification ? Gardez aussi un exemple où l’équipe a décidé consciemment de commencer malgré une inconnue. Le suivi doit éclairer une décision, pas fabriquer une conformité de façade.

Le Scrum Master peut prendre en charge le rappel du rendez-vous de suivi pendant cet essai. Il ne devient pas le propriétaire permanent de tous les contrats. L’équipe doit pouvoir continuer la pratique sans sa présence. L’essai vise une capacité collective à voir et traiter la dépendance ; le suivi doit encore montrer si elle progresse.

Interpréter le suivi sans annoncer une causalité

Le paquet de suivi contient deux Sprints fictifs. S4 sélectionne sept éléments, en termine six et en laisse un non terminé, sans annotation d’attente du contrat. S5 sélectionne huit éléments, en termine sept et en laisse un non terminé, avec une annotation d’attente. Nous comptons donc deux sélections non terminées sur quinze, environ 13,3 %.

Vous pouvez dire : « Après l’essai, nous observons moins de sélections non terminées dans ce paquet. » Vous ne pouvez pas conclure que l’intervention a causé une baisse déterminée de performance perdue. Le volume, la taille des éléments et les dépendances ont changé ; deux Sprints ne constituent pas une expérience contrôlée.

Les sept vérifications Python contrôlent les partitions sélectionnés/terminés/non terminés, les totaux et les ratios, ainsi que le fait que l’attente reste un sous-ensemble des non terminés. Elles empêchent des incohérences arithmétiques dans l’exercice. Elles ne valident ni les annotations, ni le vécu des personnes, ni la valeur du produit.

Demandez ensuite à l’équipe ce qui a facilité ou compliqué le travail. Un ratio meilleur avec davantage d’heures supplémentaires ne serait pas nécessairement une amélioration souhaitable. Une baisse des reports obtenue en découpant artificiellement les éléments pourrait également masquer le problème. Croisez les chiffres avec des exemples et la soutenabilité du travail.

Construire votre réponse d’entretien autour d’une décision

Une réponse initiale peut suivre ce fil : « Je pars des exemples de report, pas d’un jugement sur les personnes. Je rends la dépendance d’interface visible, facilite une clarification entre les acteurs et aide l’équipe à adapter le plan. En rétrospective, je propose un essai limité avec un suivi. Je distingue la pratique essayée des résultats observés et des causes encore incertaines. »

Si l’on vous demande qui décide du travail, gardez les responsabilités explicites. Si l’on vous demande comment vous prouvez une amélioration, montrez les éléments comparables et les limites du suivi. Pour une expérience personnelle, précisez votre rôle, les autres acteurs et ce que vous avez réellement observé ; ne présentez pas ce scénario fictif comme votre histoire.

Ces questions étendent le travail sur la collaboration, sans constituer une liste officielle de recrutement Scrum Master :

Continuez avec Resolve Poor Team Collaboration: Identify Issues, Implement Solutions. Préparez un fait, une hypothèse, une intervention et une observation qui vous ferait ajuster cette intervention.

Sources and Further Reading

• Ken Schwaber et Jeff Sutherland — Guide Scrum 2020, traduction française.
• Scrum.org — Conducting the Sprint Retrospective.
• Manifeste Agile — Principes en français.