Questions d'entretien pour Scrum Master : le guide de préparation définitif

Les organisations utilisant des cadres Agile rapportent une mise sur le marché 60 % plus rapide et une productivité 25 % supérieure par rapport aux approches traditionnelles de gestion de projet, selon le 17e State of Agile Report [1]. Le Scrum Master est au centre de cette transformation — non pas en tant que chef de projet rebaptisé, mais en tant que servant-leader qui permet à des équipes performantes de s'épanouir. Les évaluateurs examinant les candidats Scrum Master recherchent une combinaison spécifique : connaissance approfondie du cadre, instinct de coaching, compétence en résolution de conflits et capacité à protéger une équipe sans créer de dépendance.

Ce guide couvre les questions d'entretien pour Scrum Master les plus fréquemment posées dans quatre catégories — connaissance du cadre et des processus, comportement et leadership, situations et scénarios, et concepts Agile avancés — avec des structures de réponses détaillées et ce que les évaluateurs cherchent véritablement à évaluer.

Points clés à retenir

• Les entretiens de Scrum Master testent votre compréhension de la théorie Scrum ET votre capacité à l'appliquer dans des situations réelles et complexes
• Attendez-vous à des questions qui sondent si vous êtes un gardien de processus ou un véritable servant-leader
• Les questions comportementales évaluent votre capacité de coaching, votre résolution de conflits et votre gestion des parties prenantes
• Préparez des exemples concrets montrant comment vous avez amélioré la vélocité de l'équipe, levé des obstacles et facilité le changement organisationnel
• La démonstration de connaissances sur les cadres de passage à l'échelle (SAFe, LeSS, Nexus) est de plus en plus attendue

Questions sur la connaissance du cadre et des processus

1. Quels sont les trois piliers du contrôle empirique des processus dans Scrum, et comment les appliquez-vous en pratique ?

Ce que recherchent les évaluateurs : que vous comprenez que Scrum est ancré dans l'empirisme, pas seulement dans les cérémonies.

Structure de réponse : Les trois piliers sont la transparence, l'inspection et l'adaptation [2]. La transparence signifie rendre l'état du travail visible — pas seulement à travers le Sprint Backlog et les graphiques d'avancement, mais à travers des conversations honnêtes lors des Daily Scrums où les membres de l'équipe font remonter les blocages plutôt que de donner des rapports d'état. L'inspection signifie examiner régulièrement les artefacts et la progression — les Sprint Reviews sont des inspections de l'incrément produit, les Rétrospectives sont des inspections du processus. L'adaptation signifie s'ajuster en fonction de ce que vous apprenez — c'est là que de nombreuses équipes échouent, traitant les actions de Rétrospective comme des suggestions plutôt que des engagements. Donnez un exemple concret : « Après trois Sprints où les tests étaient le goulot d'étranglement, nous nous sommes adaptés en mettant en place une Definition of Done "test-first" qui exigeait des cas de test avant le début du développement. Notre taux de défauts échappés a chuté de 40 % au trimestre suivant. »

2. Comment différenciez-vous le rôle de Scrum Master de celui de chef de projet ?

Ce que recherchent les évaluateurs : une compréhension claire que ce sont des rôles fondamentalement différents, pas juste des titres différents.

Structure de réponse : Un chef de projet est responsable du plan, assigne le travail, suit l'avancement et rend compte de la livraison. Un Scrum Master est responsable du processus, accompagne l'équipe vers l'auto-organisation, lève les obstacles et rend compte de l'efficacité de l'équipe [3]. Le Scrum Master n'assigne pas de tâches — l'équipe de développement tire le travail du Sprint Backlog. Le Scrum Master ne crée pas de rapports d'état pour la direction — les artefacts de l'équipe (Sprint Backlog, Incrément, graphique d'avancement) assurent la transparence. Là où un chef de projet dirait « nous devons ajouter des ressources pour respecter le délai », un Scrum Master pourrait dire « examinons pourquoi notre vélocité a baissé et traitons la cause racine ». Soulignez que beaucoup d'organisations embauchent par erreur des Scrum Masters pour être des chefs de projet Agile, et qu'une partie du rôle consiste à éduquer la direction sur cette distinction.

3. Qu'est-ce que la Definition of Done, et pourquoi est-elle importante ?

Ce que recherchent les évaluateurs : que vous considérez la DoD comme un engagement de qualité, pas comme une liste à cocher.

Structure de réponse : La Definition of Done est la compréhension partagée par l'équipe de ce que « terminé » signifie pour chaque élément du Product Backlog. Elle inclut typiquement des critères comme : revue de code effectuée, tests unitaires passés avec un seuil minimum de couverture, tests d'intégration passés, documentation mise à jour, benchmarks de performance atteints et déployé en environnement de pré-production [4]. La DoD est importante car sans elle, « terminé » est subjectif — pour un développeur, « terminé » peut signifier « fonctionne sur ma machine » tandis que pour un autre, cela signifie « prêt pour la production ». Une DoD faible crée du travail inachevé qui s'accumule en dette technique, rendant les métriques de vélocité insignifiantes car l'équipe compte du travail partiellement achevé. Décrivez comment vous avez fait évoluer la DoD d'une équipe au fil du temps : « Quand j'ai rejoint l'équipe, la DoD comptait trois critères. En six mois, nous l'avons progressivement renforcée à douze critères, ce qui a initialement réduit la vélocité de 20 % mais a entièrement éliminé notre problème de bugs de régression. »

4. Comment gérez-vous le Sprint Planning quand l'équipe s'engage régulièrement sur trop de travail ?

Ce que recherchent les évaluateurs : une approche de coaching qui construit l'appropriation par l'équipe plutôt que d'imposer des contraintes.

Structure de réponse : D'abord, diagnostiquez pourquoi le sur-engagement se produit — est-ce dû à une pression externe des parties prenantes, un biais d'optimisme au sein de l'équipe ou de mauvaises pratiques d'estimation ? Puis traitez la cause racine. Si l'équipe répond à la pression, facilitez une conversation avec le Product Owner sur le rythme soutenable et le coût du changement de contexte quand le travail inachevé se reporte [5]. Si l'estimation est le problème, introduisez des techniques comme des sessions de calibration des story points, des stories de référence ou le Planning Poker avec la vélocité historique comme garde-fou. Le geste de coaching clé est de rendre le schéma visible : « J'ai commencé à suivre l'engagement versus l'achèvement par Sprint sur un graphique simple. Après trois Sprints, l'équipe pouvait voir le schéma par elle-même et a commencé à se corriger. Elle a réduit son engagement Sprint de 15 % et a commencé à terminer 95 % du travail planifié, ce qui a en réalité augmenté le débit total. »

5. Expliquez l'objectif de chaque événement Scrum et ce qui se passerait si vous le supprimiez.

Ce que recherchent les évaluateurs : que vous comprenez la contribution unique de chaque événement plutôt que de les voir comme des réunions obligatoires.

Structure de réponse : Le Sprint Planning aligne l'équipe sur l'Objectif du Sprint et la stratégie de décomposition — le supprimer et l'équipe travaille sur des éléments individuels sans objectif fédérateur, réduisant la collaboration. Le Daily Scrum permet l'inspection et l'adaptation du plan de Sprint au sein du Sprint — le supprimer et les obstacles persistent, le travail se duplique et la synchronisation se dégrade. Le Sprint Review inspecte l'Incrément avec les parties prenantes — le supprimer et le produit diverge des besoins utilisateurs car les boucles de rétroaction sont rompues. La Sprint Rétrospective inspecte le processus de l'équipe — la supprimer et l'amélioration stagne, les frustrations s'accumulent et l'équipe plafonne [6]. Notez que le Sprint lui-même est un événement conteneur, et tous les autres événements existent pour soutenir l'Objectif du Sprint. « J'ai vu des équipes qui ont abandonné les Rétrospectives parce qu'elles "semblaient être une perte de temps." En trois Sprints, leur temps de cycle a doublé parce que des problèmes récurrents — comme une défaillance intermittente du CI — n'étaient jamais remontés ni traités. »

Questions comportementales et de leadership

6. Parlez-moi d'une situation où vous avez résolu un conflit au sein de votre équipe de développement.

Ce que recherchent les évaluateurs : la compétence en médiation, l'intelligence émotionnelle et si vous affrontez les conflits ou les évitez.

Structure de réponse : Utilisez la méthode STAR en mettant l'accent sur votre approche de facilitation. Choisissez un véritable conflit interpersonnel — pas seulement un désaccord technique. Peut-être que deux ingénieurs seniors avaient des philosophies architecturales contradictoires qui causaient des revues de code passives-agressives et des pull requests bloquées. Décrivez comment vous avez (1) observé le schéma à travers les métriques de revue et les signaux de moral de l'équipe, (2) eu des conversations individuelles pour comprendre la perspective et les préoccupations sous-jacentes de chaque personne, (3) facilité une session structurée où chacun pouvait présenter son approche avec des critères d'évaluation objectifs, et (4) guidé l'équipe vers un cadre de décision réutilisable. Quantifiez l'impact : « Le temps de cycle des merge requests est passé de 4,2 jours à 1,8 jour, et les deux ingénieurs ont fini par co-rédiger un processus de documentation des décisions architecturales pour l'équipe. »

7. Comment coachez-vous un Product Owner qui rédige des user stories vagues ?

Ce que recherchent les évaluateurs : des compétences de coaching et la capacité d'influencer sans autorité.

Structure de réponse : Résistez à la tentation de réécrire les stories vous-même — cela crée de la dépendance. Utilisez plutôt le questionnement socratique pendant le Backlog Refinement : « Quel problème l'utilisateur essaie-t-il de résoudre ? Comment saurions-nous que c'est terminé ? Quelle est la plus petite version qui apporte de la valeur ? » [7]. Introduisez les critères INVEST (Independent, Negotiable, Valuable, Estimable, Small, Testable) comme langage commun plutôt que comme outil de jugement. Proposez de travailler en binôme avec le Product Owner sur la rédaction de stories pendant quelques sessions, non pas pour faire le travail mais pour modéliser le processus de réflexion. « J'ai travaillé avec un PO qui écrivait des stories comme "Améliorer le tableau de bord." Grâce à la facilitation du Refinement, nous l'avons décomposé en six stories spécifiques avec des critères d'acceptation clairs. En un mois, le PO écrivait à ce niveau de manière autonome. »

8. Décrivez une situation où vous avez dû protéger votre équipe d'interférences externes pendant un Sprint.

Ce que recherchent les évaluateurs : le servant-leadership en action — protéger l'équipe tout en maintenant les relations avec les parties prenantes.

Structure de réponse : C'est une responsabilité classique du Scrum Master. Décrivez une situation où une partie prenante — peut-être un vice-président ou un responsable commercial — voulait injecter un travail urgent en cours de Sprint. Expliquez comment vous avez (1) reconnu l'urgence, (2) expliqué le coût de la perturbation (taxe de changement de contexte, risque d'échec de l'Objectif du Sprint), (3) proposé des alternatives (peut-on attendre le prochain Sprint ? peut-on échanger des éléments de taille équivalente ?) et (4) renvoyé la priorisation au Product Owner plutôt que de prendre la décision vous-même [8]. « Un VP des ventes voulait pousser un changement de tableau de bord en cours de Sprint pour une présentation au conseil. Au lieu d'un refus catégorique, j'ai facilité une conversation de 15 minutes entre le VP et le Product Owner pour discuter des compromis. Ils se sont mis d'accord sur un export de données manuel comme solution temporaire, et le changement de tableau de bord a été priorisé pour le Sprint suivant. »

9. Comment mesurez-vous votre efficacité en tant que Scrum Master ?

Ce que recherchent les évaluateurs : la conscience de soi et une réflexion orientée résultats au-delà des métriques de vanité.

Structure de réponse : Évitez les métriques qui reflètent la production de l'équipe plutôt que l'efficacité du Scrum Master. Concentrez-vous sur : (1) la stabilité et l'engagement de l'équipe — les gens restent-ils, les taux de participation aux Rétrospectives sont-ils élevés, (2) la vitesse d'amélioration des processus — à quelle vitesse l'équipe identifie et résout les obstacles, (3) le taux d'atteinte de l'Objectif du Sprint — pas l'achèvement des stories, mais l'atteinte de l'objectif, (4) les tendances de satisfaction des parties prenantes, (5) l'indépendance croissante de l'équipe — un excellent Scrum Master devrait être de moins en moins nécessaire pour la facilitation quotidienne [9]. « Je suis ce que j'appelle le "taux de graduation du coaching" — le pourcentage d'obstacles que l'équipe résout sans mon intervention. Quand j'ai commencé, il était de 30 %. Après un an, il était de 75 %. Cela me dit que je construis des capacités, pas de la dépendance. »

Questions situationnelles et basées sur des scénarios

10. Un développeur vous confie en privé qu'il pense que le lead technique prend des décisions techniques unilatérales sans consulter l'équipe. Comment gérez-vous cela ?

Ce que recherchent les évaluateurs : la capacité à naviguer dans la hiérarchie, respecter la confidentialité et traiter les problèmes systémiques.

Structure de réponse : D'abord, remerciez le développeur d'avoir soulevé la préoccupation et assurez-lui que vous traiterez le schéma sans l'attribuer à lui. Puis observez — assistez aux discussions techniques, examinez comment les décisions sont documentées, recherchez des preuves du schéma. Si confirmé, soulevez-le comme observation de processus lors de la Rétrospective : « J'ai remarqué que certaines décisions techniques sont prises en dehors des discussions d'équipe. Comment pouvons-nous créer un processus qui inclue l'avis de chacun ? » [10]. Si le schéma persiste, menez une conversation de coaching privée avec le lead technique sur les principes d'auto-organisation. L'objectif n'est pas de punir l'autorité mais de créer des structures de prise de décision collaborative.

11. La vélocité de votre équipe a chuté de 30 % au cours des trois derniers Sprints. Quelles mesures prenez-vous ?

Ce que recherchent les évaluateurs : une pensée diagnostique plutôt que des interventions réactives.

Structure de réponse : Les baisses de vélocité ont de nombreuses causes potentielles — ne tirez pas de conclusions hâtives. Investiguez systématiquement : (1) Vérifiez les facteurs externes — départs de membres, charge accrue de support production, instabilité de l'environnement ou distractions organisationnelles. (2) Examinez le travail lui-même — la complexité a-t-elle augmenté ? Les stories récentes ont-elles été sous-estimées ? La dette technique ralentit-elle le développement ? (3) Examinez la dynamique d'équipe — y a-t-il un conflit non résolu, un épuisement ou un désengagement ? (4) Examinez les changements de processus — un nouvel outil, une politique ou une dépendance ont-ils été introduits ? Utilisez la Rétrospective pour faire émerger le propre diagnostic de l'équipe, complété par les données de votre investigation. « Quand mon équipe a connu une baisse de vélocité, les données ont montré que les incidents de production avaient triplé suite à un changement d'infrastructure récent. En collaborant avec l'équipe DevOps pour stabiliser l'environnement, la vélocité s'est rétablie en deux Sprints. »

12. Le Product Owner veut annuler le Sprint parce que les priorités métier ont radicalement changé. Que faites-vous ?

Ce que recherchent les évaluateurs : la compréhension de quand l'annulation de Sprint est appropriée et le rôle du Scrum Master dans cette décision.

Structure de réponse : Selon le Scrum Guide, seul le Product Owner peut annuler un Sprint, et cela doit se produire quand l'Objectif du Sprint devient obsolète [11]. Votre rôle est de vous assurer que la décision est éclairée et que le processus est respecté. Facilitez une conversation : qu'est-ce qui a concrètement changé ? L'Objectif du Sprint actuel est-il vraiment obsolète, ou peut-il être adapté ? Quel est le coût de l'annulation (revue du travail achevé, effort de replanification, impact sur le moral de l'équipe) ? Si l'annulation est confirmée, facilitez une revue du travail achevé, puis menez un Sprint Planning pour un nouveau Sprint. « J'ai vécu une annulation de Sprint dans ma carrière. Un changement réglementaire a invalidé entièrement notre Objectif de Sprint. Nous avons mené une mini-Review du travail achevé, tenu un Sprint Planning abrégé, et l'équipe a apprécié la transparence de la décision plutôt que d'être forcée à continuer un travail sans valeur. »

13. Vous êtes Scrum Master pour trois équipes simultanément. Comment gérez-vous votre temps et votre attention ?

Ce que recherchent les évaluateurs : une stratégie pratique de facilitation multi-équipes et de priorisation.

Structure de réponse : Reconnaissez le défi — le Scrum Guide recommande une équipe, mais la réalité organisationnelle est souvent différente [12]. Décrivez votre stratégie : (1) Décalez les cadences de Sprint pour que les cérémonies ne se chevauchent pas, (2) développez des leaders de facilitation au sein de chaque équipe qui peuvent animer les Daily Scrums et certaines sessions de Refinement de manière autonome, (3) priorisez votre temps vers l'équipe ayant les obstacles les plus pressants ou la maturité Agile la plus faible, (4) utilisez des thèmes de Rétrospective partagés pour identifier des problèmes systémiques inter-équipes, (5) mettez en place des canaux de communication clairs pour que les équipes puissent signaler des obstacles de manière asynchrone plutôt que d'attendre votre disponibilité quotidienne. « J'ai structuré mon planning hebdomadaire : les lundis et jeudis étaient dédiés aux cérémonies de l'Équipe A, les mardis et vendredis à l'Équipe B, et j'alternais les semaines avec l'Équipe C. Les trois équipes avaient un facilitateur formé pour les standups quotidiens. »

Questions sur les concepts Agile avancés

14. Comment faciliteriez-vous la transition d'une organisation du Waterfall vers Scrum ?

Ce que recherchent les évaluateurs : une capacité de gestion du changement et des attentes réalistes sur la transformation Agile.

Structure de réponse : Commencez par un pilote — sélectionnez une équipe et un projet qui bénéficient de l'adhésion des parties prenantes et d'une complexité raisonnable. Ne tentez pas une transformation en big bang. Pour l'équipe pilote : (1) fournissez une formation Scrum pour l'équipe et les parties prenantes clés, (2) établissez le cadre Scrum avec tous les événements et artefacts, (3) fixez des attentes réalistes — les premiers Sprints seront désordonnés, (4) protégez le pilote des anticorps organisationnels qui résistent au changement [13]. Passez à l'échelle en démontrant des résultats : quand l'équipe pilote montre une meilleure prévisibilité de livraison et une satisfaction accrue des parties prenantes, d'autres équipes demanderont à adopter le cadre plutôt que d'y être contraintes. Adressez les obstacles organisationnels : les processus de planification de portefeuille, les modèles de financement, les systèmes d'évaluation de la performance et les structures de gouvernance doivent tous s'adapter pour soutenir les équipes Agile.

15. Quelle est votre expérience avec les cadres de passage à l'échelle comme SAFe, LeSS ou Nexus ? Quels sont leurs compromis ?

Ce que recherchent les évaluateurs : l'étendue des connaissances et une perspective opiniâtre mais informée.

Structure de réponse : SAFe (Scaled Agile Framework) fournit une structure complète pour les grandes entreprises mais peut sembler lourd et prescriptif — les critiques l'appellent « du Waterfall déguisé en Agile » quand il est implémenté sans changement culturel [14]. LeSS (Large-Scale Scrum) reste plus proche des principes Scrum avec une structure supplémentaire minimale, mais nécessite un engagement organisationnel fort et une restructuration significative. Nexus se concentre spécifiquement sur 3 à 9 équipes Scrum travaillant sur un produit unique, ajoutant une Nexus Integration Team et une Definition of Done partagée [15]. Partagez votre expérience réelle : quel cadre vous avez utilisé, ce qui a fonctionné et ce que vous feriez différemment. La meilleure réponse reconnaît qu'aucun cadre n'est une solution miracle — la culture, la taille et l'architecture produit de l'organisation déterminent l'approche de passage à l'échelle qui convient.

16. Comment gérez-vous la dette technique au sein du cadre Scrum ?

Ce que recherchent les évaluateurs : l'équilibre entre la pression de livraison et la durabilité à long terme.

Structure de réponse : La dette technique doit être visible, pas cachée. Faites-en un élément de premier plan dans le Product Backlog en quantifiant son impact — pas « refactoriser le module d'authentification » mais « le module d'authentification a un taux de bugs 3 fois supérieur à la moyenne et ajoute 2 jours à chaque fonctionnalité touchant la gestion des utilisateurs » [16]. Négociez avec le Product Owner une allocation durable — de nombreuses équipes utilisent une « règle des 20 % » où 20 % de la capacité du Sprint est réservée à la dette technique et aux améliorations de plateforme. Renforcez la Definition of Done pour prévenir l'accumulation de nouvelle dette. Utilisez les Rétrospectives pour faire remonter la dette qui ralentit l'équipe. « J'ai introduit une métrique de "santé technique" — le ratio de fonctionnalités par rapport aux corrections de bugs et au travail de maintenance par Sprint. Quand il descendait sous 60/40, nous le traitions comme un signal pour augmenter notre allocation de réduction de dette. »

17. Un membre de l'équipe dit qu'il ne voit plus la valeur des Rétrospectives. Comment répondez-vous ?

Ce que recherchent les évaluateurs : la créativité dans la facilitation et la capacité à revitaliser des processus en perte de vitesse.

Structure de réponse : Prenez le retour au sérieux — si les Rétrospectives semblent inutiles, le problème vient généralement d'une facilitation routinière, d'actions non résolues, ou des deux. Diagnostiquez d'abord : les actions des Rétrospectives précédentes sont-elles suivies et complétées ? Si non, c'est la cause racine — l'équipe a appris que les Rétrospectives ne mènent pas au changement. Si la facilitation est routinière, introduisez de la variété : essayez des formats comme le « Voilier » (vent, ancres, rochers, île), « Commencer/Arrêter/Continuer », « Ligne du temps » ou des Rétrospectives thématiques axées sur des aspects spécifiques comme la collaboration, les outils ou les pratiques techniques [17]. Demandez au membre de l'équipe désengagé de co-faciliter la prochaine Rétrospective — la responsabilité crée l'engagement. « Un membre de l'équipe m'a dit que les Rétrospectives étaient "juste des séances de râlerie." J'ai mis en place deux changements : les actions ont reçu des responsables et des dates d'échéance suivies sur notre board, et j'ai instauré une rotation de la facilitation. En deux Sprints, le membre de l'équipe qui s'était plaint est devenu l'un de nos participants les plus actifs en Rétrospective. »

Questions à poser à l'évaluateur

Des questions réfléchies signalent de la profondeur et un intérêt sincère :

1. « Combien d'équipes Scrum soutiendrais-je, et quel est leur niveau de maturité actuel ? » — Vous aide à évaluer l'envergure et le défi du poste.
2. « À quoi ressemble le soutien en coaching Agile au-delà du rôle de Scrum Master ? Y a-t-il un Centre d'Excellence Agile ou une équipe de coaching ? » — Montre que vous réfléchissez aux structures de soutien organisationnel.
3. « Quels sont les plus grands obstacles auxquels vos équipes font face et qu'elles ne peuvent pas résoudre au niveau de l'équipe ? » — Démontre une orientation servant-leader dès la première conversation.
4. « Comment la direction perçoit-elle le rôle de Scrum Master — comme un facilitateur, un coach ou un coordinateur de projet ? » — Vous aide à comprendre si l'organisation veut vraiment un Scrum Master ou un chef de projet rebaptisé.

Liste de contrôle de préparation

1. Relisez le Scrum Guide. La version 2020 fait 13 pages. Connaissez-le en profondeur — les évaluateurs vérifieront si vous savez ce que le cadre dit réellement par rapport aux idées reçues [18].
2. Préparez trois histoires STAR solides. Une sur la résolution de conflits, une sur la levée d'obstacles et une sur le coaching d'une équipe vers une performance supérieure. Chacune doit avoir des résultats quantifiés.
3. Connaissez vos métriques. Soyez prêt à discuter de tendances de vélocité spécifiques, de taux d'atteinte d'Objectif de Sprint et de métriques d'amélioration des équipes que vous avez coachées.
4. Pratiquez les questions de scénarios à voix haute. Les questions situationnelles vous demandent de réfléchir sur le vif — répéter votre approche diagnostique la rend naturelle.
5. Renseignez-vous sur la maturité Agile de l'entreprise. Consultez leurs offres d'emploi, leur blog d'ingénierie et les avis Glassdoor pour détecter des signaux sur leur culture Agile.

Références

[1] Digital.ai, "17th Annual State of Agile Report," Digital.ai, 2023. [2] Schwaber, K. & Sutherland, J., "The Scrum Guide," ScrumGuides.org, 2020. [3] Scrum Alliance, "Scrum Master vs. Project Manager," Scrum Alliance Resources, 2024. [4] Scrum.org, "Definition of Done," Scrum.org Professional Resources, 2024. [5] Rubin, K., "Essential Scrum: A Practical Guide to the Most Popular Agile Process," Addison-Wesley, 2012. [6] Schwaber, K. & Sutherland, J., "The Scrum Guide — Scrum Events," ScrumGuides.org, 2020. [7] Cohn, M., "User Stories Applied: For Agile Software Development," Addison-Wesley, 2004. [8] Adkins, L., "Coaching Agile Teams," Addison-Wesley Professional, 2010. [9] Scrum.org, "Evidence-Based Management Guide," Scrum.org, 2024. [10] Derby, E. & Larsen, D., "Agile Retrospectives: Making Good Teams Great," Pragmatic Bookshelf, 2006. [11] Schwaber, K. & Sutherland, J., "The Scrum Guide — Sprint Cancellation," ScrumGuides.org, 2020. [12] Scrum.org, "Scrum Master Focus Areas," Scrum.org Professional Resources, 2024. [13] Kotter, J., "Leading Change," Harvard Business Review Press, 2012. [14] Scaled Agile, Inc., "SAFe 6.0 Framework," ScaledAgileFramework.com, 2024. [15] Scrum.org, "The Nexus Guide," Scrum.org, 2021. [16] Fowler, M., "Technical Debt," MartinFowler.com, 2019. [17] Retromat, "Retrospective Activities," Retromat.org, 2024. [18] Schwaber, K. & Sutherland, J., "The Scrum Guide," ScrumGuides.org, 2020.