logo
Rétrospectives
Poker de planification
Standups
Brise-Glaces
Tarification
Tableau de bord

Articles

15 Anti-patterns Scrum Qui Tuent la Productivité de Votre Équipe

Équipe illustrée passant par des mouvements mécaniques lors d'une réunion de standup avec des expressions sans vie, un tableau Agile stagnant en arrière-planÉquipe illustrée passant par des mouvements mécaniques lors d'une réunion de standup avec des expressions sans vie, un tableau Agile stagnant en arrière-plan
Matt Lewandowski

Matt Lewandowski

Dernière mise à jour 16/02/202615 min de lecture

Votre équipe suit le Guide Scrum. Vous avez un Product Owner, un Scrum Master et une équipe de développement multifonctionnelle. Vous menez chaque cérémonie selon le calendrier. Et pourtant, rien ne semble fonctionner. Le problème n'est généralement pas que vous ignoriez les événements Scrum. C'est que vous les menez de manière à sembler productive mais qui érode réellement la capacité de votre équipe à livrer. Ce sont des anti-patterns : des pratiques qui semblent normales, peut-être même correctes, mais qui détruisent silencieusement les boucles de rétroaction dont Scrum dépend. Voici 15 des plus courants, organisés par zone de cérémonie. Si vous en reconnaissez plus que quelques-uns, votre processus a besoin d'une chirurgie, pas d'un pansement.

Anti-patterns de Planification du Sprint

La planification du sprint définit la direction pour tout le sprint. Quand cela tourne mal, tout ce qui suit en souffre. Pour un guide complet sur la façon de bien le faire, consultez comment mener des réunions de planification de sprint efficaces.

1. Pas d'objectif de sprint

À quoi cela ressemble : L'équipe extrait les éléments du haut du backlog jusqu'à épuisement de la capacité. Il n'y a ni thème ni objectif cohérents, juste un tas de tickets. Pourquoi c'est nuisible : Sans objectif de sprint, l'équipe n'a pas de but commun. Quand la portée doit être négociée à mi-sprint (ce qui est toujours le cas), il n'y a pas de cadre pour décider quoi éliminer. Chaque ticket semble tout aussi important, alors rien n'est éliminé et le sprint déborde. Comment corriger : Commencez chaque session de planification du sprint en articulant l'objectif du sprint avant de sélectionner les éléments du backlog. L'objectif répond à la question « Pourquoi ce sprint est-il important ? » Si le Product Owner ne peut pas en articuler un, le backlog a probablement besoin d'être restructuré. Pour une approche étape par étape, le guide des cérémonies Scrum couvre le flux de planification complet.

2. Le Product Owner Dicte la Portée

À quoi cela ressemble : Le PO arrive en planification avec une liste pré-sélectionnée d'éléments et dit à l'équipe ce qu'elle va accomplir ce sprint. Les développeurs acquiescent. Pourquoi c'est nuisible : La planification du sprint est une négociation, pas une attribution. Quand le PO dicte la portée, les développeurs perdent la propriété de leurs engagements. Ils arrêtent de contester les calendriers irréalistes car ils ont appris que cela n'a pas d'importance. Le résultat : surengagement chronique et épuisement silencieux. Comment corriger : Le PO propose des priorités et explique le contexte commercial. Les développeurs sélectionnent ce qu'ils peuvent réalistiquement s'engager à faire en fonction de leur capacité et de la Définition de Terminé. Le Scrum Master facilite cela en tant que conversation bidirectionnelle, pas en tant que transmission.

3. Estimation Pendant la Planification au Lieu du Raffinage

À quoi cela ressemble : L'équipe rencontre des éléments de backlog non estimés pendant la planification du sprint et passe 30+ minutes à débattre des points d'histoire pour chacun. Pourquoi c'est nuisible : La planification est faite pour sélectionner et s'engager dans le travail, pas pour l'estimer. Quand l'estimation s'infiltre dans la planification, la réunion s'allonge, l'énergie baisse et l'équipe se précipite dans la partie réelle de la planification. Pire encore, le PO ne peut pas correctement prioriser les éléments dont le coût est inconnu. Comment corriger : Estimez pendant les sessions de raffinage du backlog tenues tout au long du sprint. Utilisez Planning Poker pour garder l'estimation structurée et limitée dans le temps. D'ici le temps où les éléments arrivent à la planification du sprint, ils devraient déjà avoir des estimations et des critères d'acceptation clairs. Si vos estimations souffrent de pensée de groupe ou de biais d'ancrage, Planning Poker anonyme peut aider.

4. Surengagement Chronique

À quoi cela ressemble : L'équipe s'engage pour plus de travail qu'elle ne peut en accomplir, sprint après sprint. Les éléments inachevés se reportent. Les chiffres de vitesse semblent bons sur papier car les estimations sont gonflées. Pourquoi c'est nuisible : Le surengagement entraîne l'équipe à traiter les engagements du sprint comme aspirationnels plutôt que réels. Cela érode également la confiance des parties prenantes. Quand tout est « presque terminé », personne ne peut prédire quand quelque chose sera réellement livré. Comment corriger : Suivez la vélocité réelle (complétée, non engagée) et utilisez-la comme limite supérieure pour le prochain sprint. Laissez de la marge pour le travail non planifié. Si l'équipe termine régulièrement tôt, elle peut toujours extraire d'autres éléments du backlog.

Anti-patterns du Daily Standup

Le daily standup existe pour aider les développeurs à se coordonner. Quand il s'écarte de cet objectif, cela devient la réunion que tout le monde redoute. Pour une approche plus saine, consultez nos outils de standup et alternatives asynchrones.

5. Rapport de Statut au Scrum Master

À quoi cela ressemble : Les membres de l'équipe font face au Scrum Master ou au gestionnaire et rapportent ce qu'ils ont fait hier. La conversation remonte, pas latéralement. Les développeurs ne se parlent pas. Pourquoi c'est nuisible : Le standup devient un mini-examen de performance au lieu d'un outil de coordination. Les gens optimisent leurs mises à jour pour sembler productifs plutôt que de surfacer les obstacles. L'équipe manque les occasions de s'entraider car elle joue un rôle au lieu de communiquer. Comment corriger : Le Scrum Master doit reculer physiquement et verbalement. Tenez-vous littéralement en dehors du cercle. Posez des questions à « qu'a besoin de savoir l'équipe ? » au lieu de « qu'as-tu fait ? » Parcourir le tableau (discuter les tickets de droite à gauche) change naturellement l'accent des personnes au travail.

6. Dépasser 15 Minutes

À quoi cela ressemble : Le standup dure régulièrement 25, 30, parfois 45 minutes. La résolution de problèmes et les discussions de conception font éruption. Les gens commencent à apporter des ordinateurs portables. Pourquoi c'est nuisible : Les standups longs sont un impôt sur la matinée de toute l'équipe. Cela signale que la réunion manque de discipline, ce qui invite à plus de dérive. Les membres de l'équipe commencent à faire plusieurs tâches ou à se déconnecter mentalement. Les personnes non impliquées dans la conversation latérale viennent de perdre 30 minutes pour rien. Comment corriger : Utilisez une minuterie visible. Quand un sujet a besoin d'une discussion plus approfondie, notez-le et programmez un suivi uniquement avec les personnes impliquées. La phrase à utiliser : « Discutons-en après le standup. »

7. Résolution de Problèmes en Standup

À quoi cela ressemble : Quelqu'un mentionne un obstacle et l'équipe entière passe 10 minutes à le déboguer ensemble. Ou une question technique provoque une discussion d'architecture. Pourquoi c'est nuisible : Cela confond deux activités différentes : synchroniser et collaborer. Le standup est pour identifier les problèmes, pas les résoudre. Quand la résolution de problèmes prend le contrôle, les personnes non impliquées restent inactives et la réunion devient imprévisible en durée. Comment corriger : Entraînez l'équipe à utiliser le standup pour surfacer, non résoudre. Le format devrait être : « Je suis bloqué sur X. J'ai besoin d'aide de [personne spécifique]. » Ensuite, ces deux personnes se réunissent immédiatement après le standup. Le reste de l'équipe retourne au travail. Réunion de rétrospective illustrée où un gestionnaire est assis en tête de table tandis que les membres de l'équipe semblent mal à l'aise et silencieux, avec des notes adhésives blanches sur le murRéunion de rétrospective illustrée où un gestionnaire est assis en tête de table tandis que les membres de l'équipe semblent mal à l'aise et silencieux, avec des notes adhésives blanches sur le mur

8. Seul le Scrum Master Parle

À quoi cela ressemble : Le SM parcourt les tickets de chaque personne, demande les mises à jour et décrit le tableau. Les développeurs donnent des réponses d'un mot. Le standup est fonctionnellement un spectacle d'une seule personne. Pourquoi c'est nuisible : Cela prive les développeurs d'agentivité. Quand le SM dirige la conversation, l'équipe ne s'auto-organise pas ; elle est gérée. Cela signifie aussi que le SM devient un point unique de défaillance pour la coordination. S'il est malade, le standup s'effondre. Comment corriger : Faites tourner la facilitation parmi les membres de l'équipe. Ou mieux encore, éliminez complètement la facilitation explicite et laissez l'équipe parcourir le tableau elle-même. Le SM devrait observer, noter les modèles et amener les problèmes systémiques à la rétrospective plutôt que de micromanager la synchronisation quotidienne.

Anti-patterns de Rétrospective

La rétrospective est censée être le moteur de l'amélioration continue. Quand elle s'effondre, l'équipe cesse d'apprendre. Pour un guide sur la façon de bien mener les rétros, consultez comment mener une rétrospective Agile efficace, et essayez notre outil de rétrospective pour les formats structurés.

9. Aucun Suivi des Éléments d'Action

À quoi cela ressemble : L'équipe identifie de bonnes améliorations lors de la rétro. Les éléments d'action sont écrits sur des notes adhésives. Deux semaines plus tard, personne ne se souvient de ce qu'ils étaient. La prochaine rétro expose les mêmes problèmes. Pourquoi c'est nuisible : C'est le moyen le plus rapide de tuer l'engagement pour les rétrospectives. Quand les gens voient leurs suggestions disparaître dans le vide, ils arrêtent de les faire. La rétro devient une séance de décompression sans conséquences, et finalement, les gens arrêtent d'y assister mentalement (même s'ils sont physiquement présents). Comment corriger : Limitez les éléments d'action à deux ou trois par rétro. Assignez un propriétaire spécifique à chacun. Commencez la prochaine rétrospective en révisant les éléments d'action du sprint précédent avant autre chose. Suivez l'achèvement visiblement. Si un élément d'action ne peut pas être complété en un sprint, il est trop gros. Décomposez-le.

10. Même Format À Chaque Sprint

À quoi cela ressemble : Chaque rétrospective utilise le même format. Commencer/Arrêter/Continuer. Chaque. Seul. Sprint. L'équipe sait exactement à quoi s'attendre et a arrêté de réfléchir de manière critique à ses réponses. Pourquoi c'est nuisible : La familiarité engendre l'autopilote. Quand le format ne change jamais, les membres de l'équipe pré-calculent leurs réponses avant le début de la réunion. Ils arrêtent de découvrir de nouvelles perspectives car les questions ne les poussent pas à penser différemment. La rétro devient un exercice de case à cocher. Comment corriger : Faites tourner les formats de rétrospective. Utilisez le format Voilier un sprint, le 4Ls le suivant, puis un exercice de chronologie. Chaque format révèle différents types d'aperçus. Notre post idées de rétrospective a une bibliothèque de formats à choisir. La variété elle-même signale que cette réunion mérite d'investir.

11. L'Assistance des Gestionnaires Tue l'Honnêteté

À quoi cela ressemble : Un gestionnaire ou une partie prenante assiste à la rétrospective. L'équipe ne discute que de sujets sûrs : horaires des standups, préférences des outils, acoustique de la salle de réunion. Personne ne mentionne les vrais problèmes. Pourquoi c'est nuisible : Les rétrospectives exigent de la vulnérabilité. Les gens doivent nommer les échecs, signaler les pannes de processus et parfois aborder les frictions interpersonnelles. Rien de tout cela ne se produit quand quelqu'un ayant autorité sur leur carrière est dans la pièce. L'équipe bascule vers du « théâtre du succès » et les vrais problèmes restent cachés. C'est un cas classique de faible sécurité psychologique qui mine silencieusement les cérémonies Agiles. Comment corriger : Les gestionnaires ne doivent pas assister aux rétrospectives à moins que l'équipe ne les invite à l'unanimité. Si la culture organisationnelle exige une visibilité de gestion, partagez un résumé des éléments d'action (pas la discussion brute) après la rétro. Le travail du Scrum Master est de protéger cette limite.

12. La Rétrospective « Tout Va Bien »

À quoi cela ressemble : Personne ne soulève de préoccupations. L'équipe convient que les choses vont bien. La rétro se termine en 10 minutes. Mais les métriques du sprint racontent une histoire différente : engagements manqués, temps de cycle croissant, dette technique croissante. Pourquoi c'est nuisible : « Tout va bien » n'est presque jamais vrai. Cela signifie généralement l'une de trois choses : l'équipe ne fait pas assez confiance à l'environnement pour parler, le format de la rétro ne révèle pas les vrais problèmes, ou l'équipe a renoncé à l'amélioration car les suggestions précédentes ont été ignorées. Comment corriger : Commencez par les données, pas les sentiments. Montrez les métriques réelles du sprint : tendance de vitesse, éléments reportés, bugs échappés, temps de cycle. Laissez les chiffres commencer la conversation. Utilisez une collecte d'entrée anonyme avant la rétro pour que les gens puissent soulever des sujets sensibles sans y attacher leur nom. Et reconsidérez si les anti-patterns 9 et 11 sont en jeu.

Anti-patterns de Revue de Sprint

La revue de sprint est la chance de l'équipe d'obtenir des retours réels des parties prenantes. Quand elle devient une présentation unidirectionnelle, cette boucle de retour se ferme. Pour un guide complet des révisions saines, consultez comment mener une revue de sprint.

13. Démo Uniquement, Pas de Retours

À quoi cela ressemble : L'équipe présente une démo soignée du travail complété. Les parties prenantes regardent, acquiescent, applaudissent. Personne ne pose de questions ou ne suggère de changements. La réunion se termine par « excellente travail, équipe. » Pourquoi c'est nuisible : La revue de sprint n'est pas une démo. C'est un événement d'inspection-et-adaptation. Si les parties prenantes ne fournissent pas de retours, l'équipe construit dans le vide. Les attentes désalignées se composent sur plusieurs sprints jusqu'à ce qu'une correction de cap majeure devienne inévitable (et coûteuse). Comment corriger : Structurez la révision autour de questions, pas de présentations. Après chaque incrément est montré, posez explicitement : « Cela correspond-il à ce que vous aviez prévu ? Que changeriez-vous ? Que devrions-nous prioriser ensuite ? » Donnez aux parties prenantes le produit avec lequel interagir, pas seulement regarder. Envoyez la démo à l'avance pour que la réunion puisse se concentrer sur la discussion.

14. Aucune Assistance des Parties Prenantes

À quoi cela ressemble : La revue de sprint n'est assistée que par l'équipe Scrum. Pas de clients, pas d'utilisateurs, pas de parties prenantes commerciales. Le PO joue parfois le rôle des trois. Pourquoi c'est nuisible : Sans perspectives externes, l'équipe perd le contact avec les vrais besoins des utilisateurs. Le PO devient un goulot d'étranglement pour tous les retours, et ses hypothèses ne sont pas remises en question. L'équipe construit ce que le PO pense que les utilisateurs veulent au lieu de valider directement. Comment corriger : Facilitez l'assistance des parties prenantes. Envoyez des invitations de calendrier tôt. Gardez la réunion brève et focalisée. Partagez un agenda d'une page montrant ce qui sera examiné. Si les principales parties prenantes ne peuvent vraiment pas assister, enregistrez la révision et recueillez des retours asynchrones. Mais une non-assistance persistante est un signal que l'organisation ne valorise pas le processus Scrum, ce qui est un problème qui vaut la peine d'être escaladé.

15. Le PO Approuve ou Rejette le Travail

À quoi cela ressemble : La revue de sprint devient une porte d'acceptation. Le PO examine chaque élément et le marque comme « accepté » ou « rejeté », souvent avec des demandes de modification de dernière minute. Pourquoi c'est nuisible : Cela transforme la revue de sprint en inspection de qualité plutôt qu'en discussion collaborative. Cela crée une dynamique antagoniste entre le PO et l'équipe. Cela signifie aussi que la Définition de Terminé n'est pas en train de faire son travail. Si les éléments « terminés » peuvent être rejetés, la définition de terminé de l'équipe n'est pas claire, ou le PO ajoute de nouvelles exigences déguisées en critères d'acceptation. Comment corriger : L'acceptation doit être continue, pas regroupée dans la révision. Le PO devrait examiner les incrémentes tout au long du sprint, pas les garder pour une seule cérémonie. La revue de sprint devrait se concentrer sur la direction stratégique et les retours des parties prenantes, pas sur le contrôle des éléments individuels.

Anti-patterns Organisationnels

Certains anti-patterns n'appartiennent pas à une seule cérémonie. Ils infectent tout le processus.
🧟Zombie Scrum

L'équipe passe par tous les mouvements de Scrum, mais rien de significatif en ressort. Les sprints produisent des incrémentes que personne n'utilise. Les parties prenantes ont arrêté de prêter attention. L'équipe a perdu tout sens du but. Les cérémonies se produisent, mais elles sont creuses. Cela provient souvent d'unemanque de sécurité psychologiquecombinée à une dysfonction organisationnelle dont l'équipe se sent impuissante à résoudre.

🔧Sprints de Durcissement

L'équipe consacre des sprints entiers à la « stabilisation » ou au « durcissement », en corrigeant les bugs et en remboursant la dette technique accumulée lors des « sprints de fonctionnalités ». C'est un symptôme direct d'une Définition de Terminé cassée. Si le travail de qualité n'est fait que dans des sprints spéciaux, la qualité n'est pas partie du processus. Intégrez les tests, la refactorisation et la documentation dans chaque sprint.

📊Vélocité comme Métrique de Performance

La gestion utilise la vélocité pour comparer les équipes, évaluer la performance individuelle ou définir des objectifs. L'équipe répond prévisiblement : ils gonflent les estimations. Une histoire de 5 points devient un 8. La vélocité monte. La production réelle ne change pas. Pour les métriques qui révèlent réellement la santé des processus, consultezles métriques de flux comme le temps de cycle et le débit.

Comment Diagnostiquer Votre Équipe

Si vous ne savez pas quels anti-patterns s'appliquent à votre équipe, utilisez cette liste de contrôle comme une évaluation de santé. Passez-la honnêtement, idéalement en équipe lors d'une rétrospective.

Notre sprint a un objectif clair et articulé que toute l'équipe peut expliquer.

Les développeurs choisissent leur propre portée de sprint en fonction de la capacité, pas des attributions du PO.

Les éléments du backlog sont estimés avant d'entrer en planification du sprint.

Nous complètons régulièrement 80 % ou plus de notre engagement de sprint.

Notre standup reste sous 15 minutes et se concentre sur la coordination, pas sur le statut.

Les membres de l'équipe se parlent lors du standup, pas seulement au Scrum Master.

Les éléments d'action de notre rétrospective du sprint précédent ont été complétés.

Les gens soulèvent de véritables préoccupations dans les rétrospectives, pas seulement des logistiques.

Les parties prenantes assistent aux révisions de sprint et fournissent des retours exploitables.

Nous n'avons jamais de sprints dédiés « correction de bugs » ou « durcissement ».

La vélocité est utilisée pour la planification, pas pour l'évaluation de performance.

La Définition de Terminé de l'équipe inclut les tests et la documentation.

Tout élément non coché pointe vers un anti-pattern qui vaut la peine d'aborder. Commencez par celui qui cause le plus de douleur et corrigez-le avant de passer au suivant. Essayer de tout corriger à la fois est son propre anti-pattern.

Conclusion

Les anti-patterns sont insidieux car ils ressemblent à un processus. L'équipe fait Scrum, exécute chaque cérémonie, remplit chaque champ dans Jira. Mais les résultats ne sont pas là. Reconnaître le modèle est la première étape. La correction exige de l'honnêteté sur ce qui se passe réellement dans la salle et le courage organisationnel pour le changer. Commencez par un. Corrigez-le. Prouvez qu'il fonctionne. Puis abordez le suivant. C'est ainsi que l'amélioration continue est censée fonctionner, un sprint à la fois. Si vous cherchez des outils qui soutiennent des cérémonies Scrum plus saines, Kollabe fournit Planning Poker avec estimation anonyme, rétrospectives avec des formats structurés, et standups asynchrones qui gardent les équipes distribuées alignées.

Un anti-pattern est une pratique qui semble productive ou qui suit la structure de Scrum en surface mais qui mine réellement la capacité de l'équipe à livrer de la valeur. Les anti-patterns se développent souvent graduellement lorsque les équipes trouvent des raccourcis ou tombent dans des habitudes qui contournent l'intention derrière les événements et les rôles de Scrum.

Zombie Scrum décrit les équipes qui passent par tous les mouvements de Scrum sans aucun des résultats. Les sprints se produisent, les cérémonies se déroulent selon le calendrier et les tableaux sont mis à jour, mais l'équipe a perdu la connexion avec les parties prenantes, le but et la capacité à inspecter et adapter. Le terme a été popularisé par Johannes Schartau, Christiaan Verwijs et Barry Overeem. C'est généralement causé par une combinaison de dysfonction organisationnelle, de faible sécurité psychologique et d'une déconnexion entre l'équipe et les personnes qui utilisent leur produit.

Commencez par la rétrospective. C'est la seule cérémonie explicitement conçue pour l'amélioration des processus. Soulevez l'anti-pattern spécifique avec des données : montrez les métriques du sprint, pointez les modèles sur plusieurs sprints et proposez une expérience concrète à essayer pour un sprint. Encadrez-la comme une hypothèse, pas une plainte. Si les anti-patterns rétrospectifs sont le problème (modèles 9-12), c'est une conversation pour le Scrum Master, qui a le mandat organisationnel de protéger la capacité de l'équipe à inspecter et adapter.

Oui, à court terme. Les équipes peuvent livrer des fonctionnalités tout en exécutant des standups cassés, en ignorant les éléments d'action rétro et en s'surengageant chaque sprint. Mais ce n'est pas durable. Les anti-patterns créent des coûts cachés : épuisement professionnel, dette technique, confiance en érosion et roulement. Les dégâts se composent avec le temps. Les équipes qui abordent les anti-patterns tôt protègent leur vélocité à long terme et la santé de l'équipe.