Les anti-patterns Scrum les plus courants

Scrum est un framework simple à comprendre mais difficile à maîtriser. Cette formule du Scrum Guide résume une réalité que vivent de nombreuses équipes : elles pensent pratiquer Scrum, mais tombent dans des anti-patterns qui en sapent l'efficacité. Le résultat est un "Scrum zombie" qui conserve les rituels sans en tirer les bénéfices.

Cet article identifie les anti-patterns les plus courants, explique pourquoi ils sont nocifs et propose des pistes concrètes pour les corriger.

Anti-patterns liés aux événements

Le Daily Scrum transformé en reporting

C'est probablement l'anti-pattern le plus répandu. Le Daily Scrum devient une réunion de statut où chaque Developer s'adresse au Scrum Master ou à un manager pour rendre compte de son activité. La discussion perd son caractère collaboratif et les Developers cessent de se synchroniser entre eux.

Comment le corriger : rappeler que le Daily Scrum est un événement des Developers, pour les Developers. Le Scrum Master doit encourager les membres à se parler entre eux plutôt qu'à lui. Pour aller plus loin, consultez notre guide sur le Daily Scrum efficace.

Le Sprint Planning sans Sprint Goal

L'équipe sélectionne des éléments du Product Backlog sans définir d'objectif commun. Le Sprint devient une liste de courses sans fil conducteur. Les Developers ne peuvent pas prendre de décisions éclairées sur les compromis à faire en cours de Sprint.

Comment le corriger : le Product Owner doit arriver au Sprint Planning avec une proposition de Sprint Goal. L'équipe en discute et la raffine ensemble. Le Sprint Goal doit être formulé avant la sélection des éléments du Backlog.

La Sprint Review réduite à une démo

La Sprint Review se résume à une démonstration technique devant un public passif. Les parties prenantes ne sont pas invitées ou restent silencieuses. Aucune discussion n'a lieu sur les prochaines priorités ou l'évolution du Product Backlog.

Comment le corriger : inviter activement les parties prenantes et structurer la session comme une conversation, pas une présentation. Préparer des questions ouvertes. Réserver du temps pour discuter du Product Backlog et des prochaines priorités.

La Retrospective sans suite

L'équipe identifie des problèmes et propose des actions, mais rien ne change d'un Sprint à l'autre. Les mêmes sujets reviennent indéfiniment, créant frustration et désengagement. Pour des techniques d'animation concrètes, consultez notre article sur l'animation de Sprint Retrospective.

Comment le corriger : limiter les actions à deux ou trois par Sprint. Intégrer ces actions dans le Sprint Backlog du prochain Sprint. Commencer chaque Retrospective par un bilan des actions précédentes.

La Retrospective supprimée

Sous prétexte de manque de temps ou parce que "tout va bien", l'équipe saute la Retrospective. C'est renoncer à l'amélioration continue, le pilier fondamental de Scrum.

Comment le corriger : la Retrospective n'est pas optionnelle. Le Scrum Master doit protéger cet événement. Si l'équipe résiste, c'est un symptôme à explorer : pourquoi la Retrospective est-elle perçue comme inutile ?

Anti-patterns liés aux rôles

Le Scrum Master comme chef de projet

Le Scrum Master assigne les tâches, suit l'avancement, rend compte au management et prend des décisions à la place de l'équipe. Ce n'est plus un servant-leader mais un command-and-control manager déguisé.

Comment le corriger : le Scrum Master doit se recentrer sur la facilitation, le coaching et la suppression des obstacles. Les Developers s'auto-organisent et décident eux-mêmes comment réaliser le travail.

Le Product Owner absent

Le Product Owner n'est pas disponible pour répondre aux questions des Developers, ne participe pas aux événements Scrum ou délègue toutes ses responsabilités. Les Developers devinent les priorités et font des hypothèses qui s'avèrent fausses.

Comment le corriger : le Product Owner doit être accessible quotidiennement. Si la charge de travail est trop importante, il faut revoir l'organisation, pas le rôle. Un PO à mi-temps n'est pas un PO.

Les Developers qui ne s'auto-organisent pas

Les Developers attendent qu'on leur dise quoi faire, ne prennent pas d'initiative et ne collaborent pas spontanément. L'auto-organisation est un muscle qui se développe avec le temps et le bon accompagnement.

Comment le corriger : le Scrum Master coache l'équipe vers l'autonomie, progressivement. Commencer par de petites décisions (choix des tâches, organisation du Daily) puis élargir le périmètre d'autonomie.

Le cumul des rôles

Le Scrum Master est aussi Developer. Le Product Owner est aussi Scrum Master. Ces cumuls créent des conflits d'intérêts et diluent l'attention portée à chaque rôle.

Comment le corriger : chaque rôle Scrum mérite une personne dédiée. Si les contraintes organisationnelles imposent un cumul, il faut au minimum que la personne soit consciente des tensions et les gère explicitement.

Anti-patterns liés aux artefacts

Le Product Backlog comme cahier des charges

Le Product Backlog ressemble à un document de spécifications détaillées de 200 pages, figé et rarement mis à jour. Il perd sa nature évolutive et adaptative.

Comment le corriger : le Product Backlog est un artefact vivant. Seuls les éléments du haut doivent être détaillés. Le bas du Backlog peut rester vague. Le PO le réordonne régulièrement en fonction des retours et de l'évolution du marché.

L'absence de Definition of Done

L'équipe n'a pas de Definition of Done formelle, ou elle existe sur le papier mais n'est pas respectée. Chaque Developer a sa propre interprétation de "terminé", ce qui crée des Increments de qualité variable.

Comment le corriger : définir une DoD en équipe lors d'une Retrospective. L'afficher de manière visible. La respecter sans exception. La renforcer progressivement.

Le Sprint Backlog géré par le Scrum Master

Le Scrum Master met à jour le tableau, assigne les tâches et contrôle le burndown chart. Le Sprint Backlog appartient aux Developers, pas au Scrum Master.

Comment le corriger : transférer la responsabilité du Sprint Backlog aux Developers. Le Scrum Master peut montrer l'exemple les premiers Sprints, puis se retirer progressivement.

Anti-patterns organisationnels

Le management qui impose le contenu du Sprint

Un responsable hiérarchique ou un client impose des éléments dans le Sprint sans passer par le Product Owner. Le Sprint Backlog est pollué par des demandes non prioritaires qui menacent le Sprint Goal.

Comment le corriger : toutes les demandes passent par le Product Backlog et sont priorisées par le Product Owner. Le Scrum Master protège l'équipe des interférences extérieures pendant le Sprint.

Les équipes Scrum sans autonomie

L'équipe n'a pas le pouvoir de prendre des décisions techniques, de choisir ses outils ou d'adapter ses processus. L'auto-gestion prônée par Scrum est impossible dans un environnement de contrôle.

Comment le corriger : le Scrum Master travaille avec le management pour créer les conditions de l'autonomie. C'est un travail de longue haleine qui nécessite de la confiance mutuelle.

Les estimations transformées en engagements

Le management interprète les estimations des Developers comme des engagements contractuels. L'équipe est sanctionnée quand elle ne livre pas exactement ce qui avait été estimé.

Comment le corriger : éduquer le management sur la nature des estimations (prévisions, pas promesses). Utiliser la vélocité comme outil de planification, pas comme outil de contrôle.

Comment détecter les anti-patterns

Signaux d'alerte

Certains symptômes indiquent la présence probable d'anti-patterns :

• Les mêmes problèmes reviennent Sprint après Sprint.
• L'équipe est démotivée ou désengagée pendant les événements Scrum.
• La vélocité stagne ou diminue malgré des efforts constants.
• La qualité des Increments se dégrade progressivement.
• Le turnover est élevé dans l'équipe.
• Les parties prenantes sont insatisfaites malgré un rythme de livraison soutenu.

Outils de diagnostic

• Health Check : un questionnaire régulier sur la santé de l'équipe (modèle Spotify Squad Health Check).
• Retrospective thématique : dédier une Retrospective à l'identification des anti-patterns.
• Coaching externe : un regard extérieur peut détecter des anti-patterns que l'équipe ne voit plus.

Anti-patterns et certification

La connaissance des anti-patterns est un atout majeur pour la certification PSM I et la PSM II. Les questions d'examen présentent souvent des scénarios qui décrivent des situations problématiques. Reconnaître l'anti-pattern permet d'identifier la réponse correcte parmi les options proposées.

Par exemple, une question qui décrit un Scrum Master assignant des tâches aux Developers teste votre capacité à identifier que ce comportement viole le principe d'auto-gestion, quel que soit le contexte présenté.

Pour vous entraîner sur ces scénarios et développer vos réflexes d'identification des anti-patterns, créez votre compte Outsmart et accédez à des centaines de questions contextualisées avec feedback intelligent.

En résumé

Les anti-patterns Scrum sont des pratiques qui semblent raisonnables en surface mais qui sapent les fondements du framework. Les identifier est la première étape pour les corriger. Le Scrum Master joue un rôle crucial dans cette détection et dans l'accompagnement de l'équipe vers des pratiques saines. La Retrospective est l'événement privilégié pour aborder ces sujets et décider d'actions correctives. Une pratique Scrum saine n'est pas une pratique parfaite : c'est une pratique qui s'améliore continuellement.