Votre équipe fait-elle du faux Scrum ?
Cinq questions pour mesurer l'écart entre vos rituels et le cadre.
1 / 5 — À quoi ressemble votre daily ?
Votre équipe a un Scrum Master, des sprints de deux semaines et un daily chaque matin. Pourtant, les livraisons glissent, les développeurs s’épuisent et la direction se demande à quoi sert « l’agile ». En réalité, dans bien des cas, le problème ne vient pas de Scrum. Il vient plutôt d’un Scrum de façade.
Or ce faux Scrum touche de nombreuses équipes. En effet, il est facile de copier les réunions et les intitulés de poste. Changer la façon de décider demande en revanche bien plus d’efforts. Le résultat ressemble à Scrum, mais il fonctionne comme l’ancienne organisation, avec plus de réunions.
Cet article passe donc en revue sept signes concrets. Pour chacun, vous verrez ce que dit le cadre officiel et pourquoi l’écart pose problème. Vous trouverez aussi un premier geste simple pour corriger la situation, sans tout remettre à plat.
Le terme désigne d’abord une équipe qui applique les formes de Scrum sans en appliquer les principes. Le Scrum Guide, le texte de référence des créateurs du cadre, tranche clairement ce point. Il précise ainsi que le cadre reste immuable. Une équipe peut certes appliquer seulement certaines parties, mais le résultat ne relève alors plus de Scrum.
Ron Jeffries, l’un des signataires du Manifeste agile, parle quant à lui de « Dark Scrum ». Selon lui, le faux Scrum commence quand des personnes qui connaissent leur ancien métier, mais pas leur nouveau rôle Scrum, se mettent à animer les rituels. Il souligne d’ailleurs que ces responsables agissent souvent de bonne foi. Ils font simplement ce qu’ils ont toujours fait, dans un nouveau décor.
Le faux Scrum n’est donc pas une question de mauvaise volonté. Il relève surtout d’un manque de formation et de posture. Par conséquent, il se corrige, à condition de savoir le reconnaître.
Chaque matin, chacun annonce ce qu’il a fait hier et ce qu’il fera aujourd’hui. Ensuite, un manager écoute, prend des notes et redistribue les tâches. La réunion dure trente minutes et personne n’en sort plus avancé.
C’est le premier exemple de Dark Scrum cité par Ron Jeffries. Le responsable voit dans le daily une occasion idéale de contrôler l’avancement. Ainsi, au lieu de s’organiser entre eux, les développeurs rendent des comptes.
Or le Scrum Guide décrit tout autre chose. Le Daily Scrum est un événement de quinze minutes destiné aux développeurs. Son but est d’inspecter la progression vers l’objectif du sprint et d’adapter le plan de travail. Autrement dit, c’est un moment de coordination entre pairs, pas un rapport hiérarchique.
Le premier geste : recentrer le daily sur une seule question, « sommes-nous en bonne voie pour atteindre l’objectif du sprint ? ». Si un manager assiste à la réunion, il écoute sans distribuer de tâches.
Le product owner existe sur le papier. Pourtant, chaque priorité doit être validée par un comité, un sponsor ou un directeur métier. Il passe donc ses journées à relayer des demandes qu’il n’a pas choisies.
Le Scrum Guide le dit sans détour : le product owner est une personne, pas un comité. Il peut représenter les besoins de nombreuses parties prenantes, mais les décisions sur le backlog lui reviennent. Pour que cela fonctionne, l’organisation doit respecter ses choix.
Ce signe a des conséquences directes. Les priorités changent en cours de sprint et les arbitrages prennent des semaines. Quant aux développeurs, ils ne savent plus à qui s’adresser. Notre article sur le rôle du product owner détaille ce que ce poste exige vraiment.
Le premier geste : écrire noir sur blanc qui tranche sur l’ordre du backlog. Ensuite, faire valider ce périmètre par la direction.
Le sprint planning se résume à remplir la colonne « à faire » avec autant de tickets que possible. À la fin, l’équipe a livré une liste de petites tâches sans lien entre elles. Personne ne sait dire ce que le sprint a apporté.
Le Scrum Guide prévoit pourtant un objectif de sprint, défini comme l’objectif unique du sprint. Il donne de la cohérence au travail et laisse de la souplesse sur le détail des tâches. Le cadre ajoute même qu’un sprint peut être annulé si cet objectif devient obsolète.
Sans objectif, il n’y a donc plus rien à inspecter. Le daily perd son sens, la revue de sprint devient une démonstration de tickets et l’équipe ne peut pas arbitrer seule quand un imprévu survient.
Le premier geste : commencer le prochain planning par une phrase. Elle décrit la valeur que le sprint doit apporter. Choisissez ensuite les éléments du backlog qui y contribuent.
Le Scrum Master attribue les tâches, suit les délais et fait remonter les retards au management. Il est en fait un chef de projet sous un autre nom.
Selon le Scrum Guide, le Scrum Master est responsable de l’efficacité de l’équipe Scrum. Il aide chacun à comprendre la théorie et la pratique de Scrum. Il lève aussi les obstacles et accompagne l’organisation dans son adoption. En revanche, ce sont les développeurs qui décident qui fait quoi, quand et comment, car l’équipe s’autogère.
Ce glissement survient d’ailleurs souvent sans intention. Un chef de projet devient Scrum Master du jour au lendemain, sans formation, et garde ses réflexes. Pour mieux distinguer les deux postures, lisez notre comparatif Scrum Master ou chef de projet.
Le premier geste : laisser l’équipe répartir elle-même le travail pendant un sprint entier. Le Scrum Master observe alors ce qui bloque, au lieu de décider à sa place.
L’équipe déclare une fonctionnalité « terminée » en fin de sprint. Pourtant, personne ne l’a testée ni documentée, et elle ne peut pas partir en production. Elle revient deux sprints plus tard sous forme de correctifs.
Le Scrum Guide répond à ce problème avec la définition de « terminé » (Definition of Done). Il s’agit d’une description formelle de l’état de l’incrément quand il atteint la qualité requise. Le guide est strict : si un élément ne la respecte pas, l’équipe ne peut ni le livrer, ni même le présenter en revue de sprint.
Sans cette définition partagée, la vélocité affichée trompe tout le monde. En effet, l’équipe semble avancer vite, alors que la dette s’accumule en silence.
Le premier geste : rédiger avec l’équipe une définition de « terminé » courte et vérifiable. Par exemple, elle peut inclure les tests passés, la revue de code faite et le déploiement possible en préproduction.
Toutes les deux semaines, l’équipe liste ce qui va et ce qui ne va pas. Les mêmes problèmes reviennent sprint après sprint. Faute d’action concrète, la rétrospective finit par être annulée « pour gagner du temps ».
Pourtant, c’est l’un des piliers du cadre. Les principes du Manifeste agile le disent déjà : à intervalles réguliers, l’équipe réfléchit aux moyens de devenir plus efficace, puis ajuste son comportement. Le Scrum Guide va plus loin. L’équipe traite ainsi les améliorations les plus utiles dès que possible et peut même les ajouter au backlog du sprint suivant.
Une rétrospective sans suite envoie un message clair à l’équipe : rien ne changera. C’est d’ailleurs souvent à ce moment que la motivation décroche.
Le premier geste : limiter chaque rétrospective à une ou deux actions, avec un responsable. Ajoutez-les au backlog du sprint suivant, puis commencez la rétrospective d’après par leur bilan.
La direction compare la vélocité de plusieurs équipes et demande à chacune de « faire plus de points ». Les estimations gonflent alors rapidement et les chiffres montent. Pourtant, la valeur livrée ne bouge pas.
Le Scrum Guide ne mentionne d’ailleurs pas la vélocité. C’est en effet un outil interne, utile à une équipe pour prévoir sa propre capacité. Comparer deux équipes n’a aucun sens, car chacune estime avec sa propre échelle. De plus, le guide rappelle qu’il n’y a ni sous-équipe ni hiérarchie au sein d’une équipe Scrum.
Voici les effets les plus fréquents de cette pression chiffrée :
Le premier geste : remplacer la vélocité dans les tableaux de bord de la direction par des résultats. Montrez par exemple les objectifs de sprint atteints ou les fonctionnalités réellement utilisées.
Peu d’équipes cochent les sept signes. La plupart en présentent deux ou trois. Le tableau ci-dessous vous aide à faire le point rapidement, avec une question simple pour chaque signe.
| Signe | Question à poser | Rôle concerné |
|---|---|---|
| Daily en reporting | À qui l’équipe parle-t-elle pendant le daily ? | Scrum Master |
| Product owner sans pouvoir | Qui tranche vraiment sur l’ordre du backlog ? | Product owner |
| Sprint sans objectif | Pouvez-vous résumer le sprint en une phrase ? | Product owner |
| Scrum Master chef de projet | Qui attribue les tâches ? | Scrum Master |
| « Terminé » flou | L’équipe a-t-elle une définition écrite ? | Développeurs |
| Rétrospective sans effet | Quelle action de la dernière rétro a abouti ? | Scrum Master |
| Vélocité sous pression | Qui lit les chiffres de vélocité, et pourquoi ? | Management |
Si la plupart de vos réponses pointent vers le même rôle, vous savez par où commencer. Dans la majorité des cas, le levier principal se trouve chez le Scrum Master ou le product owner.
Face à ces constats, la tentation est grande de tout arrêter ou de changer de méthode. Pourtant, c’est rarement la bonne réponse. En effet, le faux Scrum vient surtout d’un manque de compréhension partagée, pas d’un défaut du cadre.
Voici une démarche progressive qui fonctionne dans la plupart des organisations :
Ce dernier point pèse souvent lourd. Comme le note Ron Jeffries, Scrum démarre généralement avec très peu de personnes formées. Beaucoup d’autres pensent aussi savoir ce qu’elles doivent faire. Une formation commune donne au contraire à tous le même vocabulaire et les mêmes repères.
Enfin, impliquez la direction dès le départ. Un Scrum authentique demande au management de déléguer des décisions, ce qui ne se décrète pas. Vous trouverez toutes nos formations agile et Scrum pour accompagner chaque rôle.
Le faux Scrum se reconnaît à un écart constant entre les rituels et leur intention. Le daily sert au contrôle, le product owner ne décide pas, le sprint n’a pas de cap et « terminé » ne garantit rien. Chacun de ces signes, pris seul, semble anodin. Ensemble, en revanche, ils vident Scrum de sa valeur.
La bonne nouvelle, c’est que chaque signe a un remède simple. Commencez par un seul, mesurez l’effet, puis avancez. Surtout, formez les rôles clés : un Scrum Master et un product owner qui comprennent vraiment leur mission font toute la différence.
Qu’est-ce que le faux Scrum ?
C’est une équipe qui applique les rituels de Scrum sans en appliquer les principes. Les réunions existent, mais les décisions se prennent comme avant.
Peut-on adapter Scrum à son organisation ?
Oui, dans le détail des pratiques. En revanche, le Scrum Guide précise que n’appliquer qu’une partie du cadre ne donne plus du Scrum.
Combien de temps doit durer un daily scrum ?
Quinze minutes au maximum, selon le Scrum Guide. Il réunit les développeurs pour inspecter la progression vers l’objectif du sprint.
Le Scrum Master doit-il attribuer les tâches ?
Non. L’équipe s’autogère : les développeurs décident eux-mêmes qui fait quoi. Le Scrum Master veille à l’efficacité de l’équipe et lève les obstacles.
Faut-il comparer la vélocité de plusieurs équipes ?
Non. Chaque équipe estime avec sa propre échelle. La vélocité sert seulement à une équipe pour prévoir sa propre capacité. Comparer les équipes entre elles reste d’ailleurs un symptôme classique du faux Scrum.
Nos dernières publications
S’abonner à la Newsletter
Consultez nos formations et sessions confirmées
ITTA
Route des jeunes 35
1227 Carouge, Suisse
ITTA
Route des jeunes 35
1227 Carouge, Suisse
