Scrum n'est pas une religion.
Voici quand l'abandonner.

J'ai facilité des centaines de cérémonies Scrum. Des daily standups à 9h02 où personne ne parlait vraiment à personne. Des sprint plannings de quatre heures qui produisaient un sprint backlog que personne ne croyait. Des rétrospectives où les mêmes problèmes revenaient semaine après semaine, recouverts d'une nouvelle couche de post-its.

À un moment, j'ai arrêté de me demander "comment mieux faire Scrum ?" et j'ai commencé à me demander "est-ce que Scrum est le bon outil ici ?"

Ce n'est pas la même question.

Scrum est un outil, pas une identité

Le Guide Scrum fait 13 pages. Il décrit un cadre de travail empirique pour gérer des problèmes complexes dans des environnements incertains. Il ne dit nulle part que vous devez l'appliquer à la lettre dans tous les contextes, pour toutes les équipes, à tous les stades de croissance.

Pourtant, dans beaucoup d'organisations, Scrum est devenu une identité. "Nous sommes agiles." "Nous faisons du Scrum." Ce glissement sémantique est dangereux : dès que le framework devient une identité, le remettre en question devient une menace personnelle pour ceux qui l'ont adopté.

C'est là que ça coince. Pas dans le framework lui-même — dans le rapport émotionnel à la méthode.

Un bon Scrum Master est celui qui sait quand arrêter de faire du Scrum.

Signal 1 : les cérémonies sont là, mais personne n'y croit

Vous reconnaissez ce meeting. Le daily standup à heure fixe, 15 minutes au chronomètre, chacun récite son triptyque "hier / aujourd'hui / blocage" — et repart à son bureau sans que quoi que ce soit ait changé.

Les gens sont présents physiquement. Mentalement, ils répondent à leurs emails.

Ce n'est pas un problème de facilitation. C'est un problème de signal faible : la cérémonie existe parce qu'elle a toujours existé, pas parce qu'elle produit de la valeur. Quand personne ne se souviendrait du standup s'il disparaissait demain, c'est que le standup ne sert plus à rien.

Le signal à guetter : la durée réelle des décisions prises en cérémonie versus hors cérémonie. Si les vraies décisions se prennent dans des couloirs, en DM Slack, ou dans des réunions ad hoc — et que les cérémonies servent juste à les officialiser — le rituel a perdu son utilité.

Signal 2 : le sprint planning prend 4h et produit 0 clarté

Un sprint planning réussi produit trois choses : un sprint goal clair, un sprint backlog accepté par l'équipe, et une confiance collective dans la faisabilité du sprint.

Quand la réunion prend quatre heures et que personne ne sait vraiment ce qu'on fait ce sprint ni pourquoi — c'est que quelque chose de fondamental est cassé. Soit les user stories arrivent trop vagues, soit le backlog n'est pas raffiné, soit le sprint goal n'existe pas en pratique.

Mais souvent, le vrai problème est plus profond : l'équipe ne fait pas face à des problèmes "complexes" au sens de Cynefin — elle fait face à des projets bien définis, avec des spécifications claires, dans un domaine maîtrisé. Dans ce cas, un sprint de 2 semaines avec cérémoniaux complets est une lourdeur inutile, pas un avantage.

Signal 3 : l'équipe parle de "points" mais ne sait pas ce qu'elle livre

Les story points sont une abstraction pour estimer la complexité relative. Ils n'ont aucune valeur en eux-mêmes. Quand une équipe optimise sa vélocité en points mais peine à répondre à "qu'avez-vous livré à vos utilisateurs ce mois-ci ?", c'est que la mesure a pris la place de l'objectif.

Ce décrochage — entre les métriques internes du framework et la valeur externe produite — est l'un des signes les plus sûrs que Scrum a cessé d'être un outil pour devenir une fin.

Quand Scrum tient vraiment la route

Pour être honnête : Scrum est excellent dans les bons contextes. Il excelle quand :

• Le problème est genuinement complexe et les solutions ne sont pas connues d'avance
• L'équipe est stable, petite (3-9 personnes), et pluridisciplinaire
• Les stakeholders sont disponibles pour des feedbacks fréquents
• Le produit est vivant et évolue en réponse à des apprentissages continus

Si vous cochez ces quatre cases, Scrum est probablement votre meilleur outil. Gardez-le.

Trois alternatives à connaître

Shape Up (Basecamp)

Cycles de 6 semaines avec un appétit défini à l'avance — pas des estimations, mais une décision politique sur ce qu'on est prêt à investir. L'équipe a une autonomie totale sur l'implémentation dans les bornes du cycle. Pas de backlog permanent. Pas de dette de sprint. Excellent pour les équipes produit matures avec des projets bien cadrés.

Kanban flow-based

Pas de sprints, pas de vélocité. Un flux continu avec des limites de WIP (Work In Progress) strictes. Chaque ticket entre quand il est prêt, sort quand il est fini. Le cycle time moyen remplace la vélocité comme métrique de performance. Idéal pour les équipes qui gèrent beaucoup de demandes entrantes de taille variable — support, ops, platform.

Le mode projet pour les petites équipes

Parfois, la bonne réponse est de faire du management de projet classique. Un objectif, un scope, une deadline, un plan. Sans cérémoniaux, sans rôles Scrum, sans sprints. Pour un MVP avec 2 devs et 12 semaines, c'est souvent largement suffisant — et infiniment moins coûteux en overhead.

Comment faire la transition sans tout casser

La transition d'un framework à un autre est moins un problème technique qu'un problème humain. Quelques règles :

• Ne jamais tuer Scrum "du haut". Si la décision vient uniquement du management, l'équipe résistera. La transition doit être co-construite, avec une rétrospective dédiée pour nommer clairement ce qui ne fonctionne plus.
• Choisir une période pilote de 6 semaines. Pas "on change définitivement", mais "on essaie autre chose pendant 6 semaines et on réévalue". Ça réduit la résistance au changement.
• Garder un rituel de synchronisation. Même sans sprints, l'équipe a besoin d'un temps régulier pour se coordonner et aligner les priorités. La fréquence peut changer, pas la nécessité.
• Mesurer ce qui change. Avant / après : cycle time, satisfaction de l'équipe (simple échelle 1-5 chaque semaine), nombre de blocages résolus en 24h. Sans mesure, impossible de savoir si la transition a fonctionné.

Scrum n'est pas une religion. C'est un outil. Et comme tout outil, son utilité dépend du contexte dans lequel vous l'utilisez. La vraie agilité, c'est savoir s'adapter — y compris à sa propre méthode de travail.

Si votre équipe souffre du framework plus qu'elle n'en bénéficie, vous avez l'autorisation de changer. Pas besoin de le justifier avec un manifeste. Il suffit de regarder ce qui produit de la valeur et ce qui n'en produit plus.