Le directeur engineering demande à Steven d'augmenter la vélocité de son équipe de 15 %. Quelles sont les deux meilleures réponses que Steven devrait apporter, et pourquoi cette demande est-elle problématique dans un contexte Scrum ?

Steven doit d'abord expliquer que la vélocité est un outil de prévision interne à l'équipe, non un levier de performance managérial pilotable de l'extérieur. La demander comme un objectif chiffré crée une pression contre-productive qui pousse les équipes à gonfler artificiellement la vélocité en contractant de la dette technique — exactement ce qui s'est produit dans ce programme. Steven doit rediriger les préoccupations de délai vers le Product Owner, seul responsable des arbitrages de périmètre et de valeur. Son rôle de Scrum Master est de lever les impediments organisationnels (dépendances non résolues entre équipes, exigences instables des équipes Components) qui pèsent réellement sur la capacité de livraison. Forcer une vélocité cible viole l'empirisme : si la capacité réelle ne permet pas de tenir le délai, la bonne réponse est de retravailler le Product Backlog avec le Product Owner pour redéfinir le périmètre de la release, pas de promettre une performance non fondée.

Le Product Owner découvre lors de la cinquième Sprint Retrospective un niveau élevé de dette technique et que des tests de régression ont été retirés de la Definition of Done. Quels facteurs ont probablement conduit à cette situation, et quelles actions Steven devrait-il faciliter ?

Plusieurs facteurs convergents expliquent cette situation : des Retrospectives inefficaces qui n'ont pas produit d'adaptations concrètes sur la qualité ; un manque de transparence du Scrum Master et du Product Owner sur l'état réel des Increments ; une Definition of Done affaiblie sous pression des délais, créant de fausses hypothèses sur l'état du système. La dette technique rend le système instable et ralentit les développements futurs de façon non linéaire. Steven doit faciliter avec l'équipe une discussion pour réintégrer les tests de régression dans la Definition of Done, estimer l'effort nécessaire pour rendre les Increments précédents réellement 'done', et re-estimer les items restants du Product Backlog sur cette base. La dette technique doit aussi être rendue visible via des Product Backlog items dédiés. La transparence retrouvée permettra au Product Owner de faire des arbitrages éclairés sur le périmètre versus la qualité.

Les deux équipes Components affirment être 'dans les temps' mais leurs Increments n'ont jamais été intégrés dans une branche commune. En quoi cela représente-t-il un problème fondamental dans un contexte Scrum multi-équipes, et comment Steven devrait-il y remédier ?

En Scrum multi-équipes, chaque Sprint doit produire un Increment unique, intégré et potentiellement livrable — y compris dès le premier Sprint. Le fait que chaque équipe travaille sur des branches isolées sans intégration commune crée un risque d'intégration massif en fin de programme, qui est précisément ce que Scrum cherche à éviter. La vélocité apparente de chaque équipe est une illusion de productivité : aucun Increment réel n'a été produit au sens du Scrum Guide. Steven doit faciliter l'adoption d'une Definition of Done partagée entre les trois équipes, qui inclut explicitement l'intégration de tous les Increments précédents. Il doit également aider les équipes à établir un cadre de synchronisation (par exemple des mécanismes inspirés de LeSS ou Nexus) pour résoudre les dépendances de manière collaborative, sans que ce soit le Scrum Master qui gère les plannings ou les ressources. La Sprint Review devrait présenter un Increment intégré unique, pas trois démonstrations isolées.

L'équipe n'arrive pas à formuler de Sprint Goals et le Sprint Backlog contient des items sans cohérence. Quels facteurs structurels expliquent ce problème, et quelles interventions Steven devrait-il engager ?

Plusieurs facteurs expliquent l'incapacité à créer des Sprint Goals : Paul n'est pas suffisamment disponible pour exercer son rôle de Product Owner (il gère trois produits simultanément), ce qui signifie qu'il ne peut pas fournir la vision et les objectifs business nécessaires pour ordonner le Product Backlog de façon cohérente. Sans vision claire, les items du backlog sont disparates et ne permettent pas de dégager un objectif commun. De plus, avec 11 membres travaillant dans leurs silos fonctionnels, l'équipe est probablement trop grande et trop fragmentée pour s'auto-organiser efficacement autour d'un but partagé. Steven devrait faciliter une conversation honnête sur l'implication réelle de Paul et sur la question de savoir si Scrum est adapté à cette configuration. Il devrait coacher Paul sur ses responsabilités de Product Owner — notamment la construction d'une vision produit claire et l'ordonnancement du Product Backlog. Il devrait également envisager de diviser l'équipe en sous-équipes plus petites travaillant sur le même Product Backlog, avec une coordination explicite.

Les investisseurs sont mécontents au huitième Sprint Review car le produit ne correspond pas à leurs attentes. Quels sont les facteurs qui ont conduit à cette situation selon les principes Scrum, et comment auraient-ils pu être évités ?

Cette situation est le résultat d'un manque de transparence systémique. Les investisseurs ont cessé d'assister aux Sprint Reviews dès le troisième Sprint, ce qui a coupé la boucle d'inspection et d'adaptation essentielle à Scrum. Sans feedback régulier des stakeholders, le Product Owner n'a pas pu recalibrer les priorités ni détecter les écarts entre ce qui était construit et les attentes business. Le Scrum Master aurait dû alerter l'équipe sur l'absence des stakeholders et travailler activement à les réengager, car la Sprint Review est le moment formel de collaboration avec les parties prenantes. Paul, en tant que Product Owner, avait la responsabilité de maintenir ce lien et d'assurer une communication proactive sur l'avancement. Steven aurait dû faciliter des Sprint Reviews plus attractives, centrées sur la valeur business et non sur des démonstrations techniques, et s'assurer que l'Increment présenté était réellement intégré et potentiellement livrable pour inspirer confiance.

Au Daily Scrum, Paul a pris l'habitude de reconnaître individuellement les développeurs qui avancent le plus vite sur leurs tâches. Comment Steven devrait-il gérer cette situation, et quel impact cela a-t-il sur la dynamique d'équipe ?

Le Daily Scrum est un événement conçu pour que l'équipe de développement se synchronise, inspecte sa progression vers le Sprint Goal et adapte son plan pour la journée — ce n'est pas un moment de reporting au Product Owner ni de reconnaissance individuelle. La pratique de Paul crée plusieurs dysfonctionnements : elle oriente les comportements individuels vers la complétion rapide de tâches personnelles plutôt que vers la livraison collective d'un Increment de valeur ; elle introduit une compétition implicite incompatible avec la collaboration ; et elle place le Product Owner dans un rôle de superviseur, ce qui contredit le principe d'auto-organisation. Steven devrait coacher Paul en privé sur la finalité du Daily Scrum et sur le fait que la reconnaissance devrait cibler les accomplissements de l'équipe dans son ensemble. Il devrait également aider l'équipe à reprendre possession de cet événement, en rappelant que le Daily Scrum appartient aux développeurs et que le Product Owner y est présent en observateur. La reconnaissance individuelle basée sur la vitesse personnelle, découplée de la qualité et de l'Increment, risque aussi de renforcer la dette technique.

Le management veut comparer les vélocités des trois équipes pour identifier les plus performantes. Quelles sont les deux meilleures réponses que Steven devrait apporter à cette demande, et en quoi cette approche est-elle problématique ?

Steven doit expliquer deux points fondamentaux : premièrement, la vélocité n'est pas une métrique de valeur business — elle mesure la quantité de travail complété selon la Definition of Done propre à chaque équipe, avec des unités qui ne sont pas comparables entre équipes (les items estimés par une équipe ne valent pas les mêmes points qu'une autre). Comparer les vélocités entre équipes revient à comparer des pommes et des oranges, et risque d'induire des comportements dysfonctionnels : les équipes pourraient gonfler leurs estimations ou réduire leur Definition of Done pour paraître plus productives. Deuxièmement, la vélocité est un outil de prévision interne pour aider chaque équipe à planifier ses Sprints — elle n'est pas conçue pour comparer ou évaluer les équipes. La baisse de vélocité de l'équipe ayant intégré de nouveaux membres est normale et prévisible (étape de 'forming' selon Tuckman) ; intervenir managérialement aggraverait la situation. Steven devrait proposer des indicateurs de valeur business (fonctionnalités livrées, feedback client, qualité de l'Increment) comme alternatives plus pertinentes pour piloter la performance.

Les trois équipes réclament Nicole à plein temps pour leur prochain Sprint. Comment Steven devrait-il gérer cette situation de ressource partagée, et quelles solutions structurelles sont envisageables ?

Steven ne doit pas gérer le planning de Nicole à la place des équipes ni décider unilatéralement de son allocation — cela contreviendrait au principe d'auto-organisation. Sa posture de servant leader consiste à faciliter une discussion entre les trois équipes pour qu'elles trouvent collectivement une solution. Plusieurs pistes acceptables peuvent émerger de cette discussion : retravailler l'ordre du Product Backlog pour séquencer les items dépendants de Nicole, afin qu'une seule équipe en ait besoin à la fois sur plusieurs Sprints successifs ; envisager un partage structuré du temps de Nicole entre les équipes sur le Sprint, avec des plages dédiées ; ou encore investir dans la montée en compétences de membres des équipes pour réduire la dépendance à une seule spécialiste. Steven devrait également alerter sur le risque systémique que représente une ressource unique pour trois équipes : c'est un goulot d'étranglement structurel qui menace la livraison d'Increments potentiellement livrables chaque Sprint. Il peut également explorer des cadres de mise à l'échelle (comme Nexus ou LeSS) qui intègrent des mécanismes de gestion des dépendances inter-équipes.

Le client demande une projection de livraison basée sur la vélocité actuelle. Comment le Product Owner devrait-il construire une réponse crédible et empirique, et quel est le rôle du burndown de release dans ce contexte ?

Le Product Owner doit s'appuyer sur l'empirisme plutôt que sur des projections déterministes. Un burndown de release peut être utilisé comme outil de prévision, mais uniquement en communiquant clairement ses conditions de validité : la projection indique quand le travail sera terminé sur la base du rythme actuel, en supposant que le Product Backlog et la capacité des équipes restent constants — ce qui est rarement le cas. Le Product Owner doit donc présenter une fourchette de scénarios (optimiste, probable, pessimiste) en tenant compte des variations de vélocité observées, notamment la baisse temporaire de l'équipe en phase d'intégration. Il doit être transparent sur les incertitudes : items non encore suffisamment affinés pour être estimés, dépendances sur Nicole, dette technique potentielle. La crédibilité de la projection repose sur la qualité du Product Backlog (refinement régulier, items clairs et estimés) et sur la rigueur de la Definition of Done qui garantit que la vélocité mesurée reflète du travail réellement 'done'. Sur-promettre en utilisant des vélocités passées idéales — sans tenir compte du contexte actuel — reproduirait exactement les erreurs qui ont conduit aux déceptions de Sprint Review dans d'autres contextes.

Le management de l'ANMA a adopté la terminologie Scrum sans former les équipes ni changer ses pratiques managériales. Quelles seront les conséquences probables de cette approche, et que devrait faire Marie pour y remédier ?

Adopter uniquement la terminologie Scrum sans en comprendre ni en soutenir les principes produit des effets contre-productifs bien documentés : les équipes maintiennent leurs comportements habituels (reporting hiérarchique, travail en silo, validation en cascade) en leur accolant des noms Scrum, ce qui crée une dissonance entre le discours officiel et la réalité quotidienne. Le vocabulaire devient vide de sens, les résistances se renforcent car les équipes perçoivent Scrum comme une contrainte supplémentaire sans bénéfice visible, et le management peut se sentir satisfait d'avoir 'fait la transition' alors qu'aucun changement réel n'a eu lieu. Marie doit travailler sur plusieurs niveaux : former les managers et le directeur de programme aux principes de Scrum et à leur rôle de soutien (créer un environnement favorable, pas de micro-management) ; coacher les équipes sur la signification réelle des événements Scrum ; et rendre visible l'écart entre les pratiques actuelles et Scrum, en utilisant les Rétrospectives pour progresser. Elle doit aussi travailler avec l'organisation pour débloquer les décisions d'amélioration identifiées en Rétrospective, sinon cet événement perd tout sens et la confiance de l'équipe.

Le directeur de programme assiste au Daily Scrum pour recevoir un rapport d'avancement individuel. Quelles sont les deux meilleures actions que Marie devrait prendre, et quel impact cette pratique a-t-elle sur le fonctionnement de l'équipe ?

Le Daily Scrum est conçu pour que les développeurs se synchronisent sur leur progression vers le Sprint Goal et adaptent leur plan — ce n'est pas une réunion de reporting au management. La présence du directeur en tant que destinataire de rapports individuels transforme cet événement en outil de surveillance, ce qui crée plusieurs problèmes : les membres de l'équipe filtrent l'information pour paraître productifs plutôt que d'identifier honnêtement les impediments ; la transparence nécessaire à l'auto-organisation disparaît ; et l'évaluation individuelle des performances basée sur la progression de tâches encourage le travail en silo au lieu de la collaboration. Marie devrait d'abord coacher l'équipe en privé sur la finalité réelle du Daily Scrum et les encourager à reprendre possession de cet événement. Ensuite, elle devrait s'entretenir avec le directeur pour lui expliquer que son besoin légitime de visibilité peut être satisfait autrement — via le Product Backlog, les burndowns de Sprint, les Sprint Reviews — sans perturber la dynamique de l'équipe. Si le directeur souhaite rester informé, la Sprint Review est l'événement approprié pour les parties prenantes.

Après quatre Sprints, l'équipe demande un Sprint de durcissement pour intégrer et tester le travail accumulé. Quels facteurs ont conduit à cette situation, et comment Marie devrait-elle réagir face à cette demande ?

La demande d'un Sprint de durcissement est un signal d'alarme révélateur de plusieurs dysfonctionnements accumulés : les équipes ont probablement produit des Increments non intégrés Sprint après Sprint, chacun travaillant dans son silo fonctionnel (design, backend, recette) sans produire de livrable potentiellement shippable à chaque itération. La Definition of Done était soit absente, soit insuffisante pour imposer l'intégration et les tests à chaque Sprint. La dette technique et le travail d'intégration différé se sont accumulés jusqu'à rendre un Sprint entier nécessaire pour 'nettoyer'. Scrum décourage explicitement les Sprints de durcissement car ils révèlent l'échec à produire de vrais Increments intégrés au fil des Sprints. Marie ne devrait pas simplement valider ou refuser la demande, mais faciliter avec l'équipe une prise de conscience sur les causes profondes : pourquoi l'intégration n'a-t-elle pas eu lieu à chaque Sprint ? Elle doit aider l'équipe à renforcer sa Definition of Done pour inclure l'intégration complète, les tests automatisés et la qualité production, et à restructurer son approche pour livrer de vrais Increments dès le prochain Sprint. Le travail non terminé doit être estimé et retourné au Product Backlog pour être repriorisé.

La vélocité de l'équipe originale a chuté de 55 à 38 unités après l'ajout des deux nouvelles équipes. Le management s'inquiète de cette baisse. Comment Steven devrait-il expliquer cette situation, et quelle est la réponse appropriée ?

Cette baisse de vélocité est normale, prévisible et temporaire lors de l'ajout de nouvelles équipes sur un même produit. Elle s'explique par plusieurs facteurs : l'augmentation de la charge de communication et de coordination entre trois équipes là où il n'y en avait qu'une ; le temps consacré au transfert de connaissance vers les nouvelles équipes par les membres de l'équipe originale ; les frictions d'intégration pour construire un Increment unique depuis plusieurs équipes travaillant en parallèle. La vélocité de l'équipe originale mesure sa propre capacité, qui est temporairement réduite par ces nouvelles responsabilités. Steven doit aider le management à comprendre que cette métrique ne reflète pas l'échec de l'équipe mais le coût réel et légitime de la mise à l'échelle. À long terme, si le scaling est bien exécuté, le débit global du produit devrait augmenter. L'objectif n'est pas de maximiser la vélocité d'une seule équipe mais de maximiser la valeur livrée par l'ensemble du système. Steven devrait également rappeler que comparer les vélocités entre équipes ou dans le temps sans tenir compte du contexte est trompeur.

Un conflit oppose les membres de l'équipe sur ce qui constitue la Definition of Done, et certains ont décidé d'en retirer les tests de performance avec l'accord du Product Owner. Quelles sont les deux meilleures actions que Steven devrait prendre, et quels sont les risques de cette décision ?

Steven doit d'abord poser des questions de coaching pour aider l'équipe et le Product Owner à comprendre les conséquences de leur décision : quel problème essaient-ils de résoudre ? L'Increment sera-t-il toujours potentiellement livrable sans tests de performance ? Quelle est l'hypothèse sur laquelle ils s'appuient ? Cette approche respecte l'autonomie de l'équipe tout en révélant les angles morts. Ensuite, Steven doit faciliter une session impliquant l'ensemble de l'équipe Scrum pour résoudre le conflit sur la Definition of Done de manière collaborative et transparente — pas par un accord tacite entre deux membres et le Product Owner. Les risques de cette décision sont sérieux : retirer les tests de performance de la Definition of Done crée de la dette technique, génère de fausses hypothèses sur l'état réel du système, et peut masquer des problèmes qui ne seront détectés qu'en production (comme c'est déjà le cas avec le stakeholder qui se plaint). La situation actuelle est précisément la conséquence prévisible de cet affaiblissement de la Definition of Done. À terme, la vélocité apparente augmente mais au prix d'une qualité dégradée et d'une instabilité croissante du système.

Un stakeholder se plaint de performances dégradées et la Sprint Review avec les investisseurs approche. Le Product Owner est inquiet. Quelles actions Steven devrait-il faciliter pour préparer cette échéance tout en respectant les principes Scrum ?

Steven doit aider le Product Owner et l'équipe à répondre à cette situation avec transparence et empirisme, sans sur-promettre ni minimiser les problèmes. Concrètement, il faut d'abord renforcer immédiatement la Definition of Done pour réintégrer les tests de performance, afin que les prochains Increments soient réellement shippables. L'Increment actuel doit être honnêtement évalué : s'il ne répond pas à la Definition of Done, il ne devrait pas être présenté comme livrable. Les lacunes qualitatives des Increments précédents doivent être matérialisées sous forme de Product Backlog items de dette technique, estimés et priori sés par le Product Owner. Pour la Sprint Review avec les investisseurs, Steven doit coacher le Product Owner pour présenter la situation avec une transparence totale : ce qui a été livré, ce qui ne l'a pas été, les causes, et le plan d'action. Présenter un Increment partiellement défaillant comme réussi violerait le pilier de transparence de Scrum et éroderait la confiance des investisseurs sur le long terme. La Sprint Review est précisément le moment d'inspection et d'adaptation qui permet d'aligner les attentes et de décider collectivement des prochaines priorités, y compris le traitement de la dette qualitative accumulée.