Vous connaissez les 5 valeurs Scrum. La vraie question n'est pas « quelles sont-elles ? », mais « votre équipe les vit-elle vraiment ? ». Cet auto-diagnostic Premium de Passe Ton Scrum, conçu pour les Scrum Masters, Agile Coaches et managers, vous donne en quelques minutes une lecture précise de la maturité de votre équipe sur chacune des 5 valeurs — engagement, courage, focus, ouverture, respect — avec un plan d'action concret par valeur.
Pourquoi les valeurs Scrum sont rarement appliquées
La plupart des équipes savent réciter les 5 valeurs. Mais entre les connaître et les vivre, il existe un fossé considérable. Plusieurs raisons se combinent :
Auto-diagnostic interactif
Répondez aux 25 questions ci-dessous en pensant à votre équipe telle qu'elle est aujourd'hui, pas telle que vous aimeriez qu'elle soit. Le score et le radar se recalculent en temps réel.
- Engagement0%
- Courage0%
- Focus0%
- Ouverture0%
- Respect0%
Le radar évolue en temps réel selon vos réponses ci-dessous.
Scrum est probablement appliqué de façon cargo-cult : les événements ont lieu, mais les valeurs sont absentes. Sans intervention, la démotivation et la dette technique vont s'installer.
- Prendre un temps hors-Sprint (½ à 1 journée) pour poser les vrais problèmes.
- Faire appel à un Agile Coach externe pour objectiver la situation.
- Vérifier que la structure organisationnelle permet réellement Scrum (pas de silos figés, pas d'objectifs individuels contradictoires).
S'engager pleinement sur le Sprint Goal et sur la qualité.
Q1.Chaque Developer se sent personnellement responsable du Sprint Goal, pas seulement de ses tickets.
Q2.L'équipe tient ses engagements de Sprint plus de 80 % du temps sans sacrifier la qualité.
Q3.Les membres s'entraident spontanément quand une PBI est en risque.
Q4.Le Product Owner s'engage sur un Product Goal clair et visible de tous.
Q5.Les décisions prises en Sprint Planning sont assumées collectivement, pas remises en cause à mi-Sprint.
Dire la vérité, refuser les compromis sur la qualité, oser les sujets difficiles.
Q1.Les Developers osent dire « non » à un ajout de scope qui menace le Sprint Goal.
Q2.Le Scrum Master remet en cause les comportements managériaux qui nuisent à l'équipe.
Q3.L'équipe refuse de livrer un Increment qui ne respecte pas la Definition of Done.
Q4.Les mauvaises nouvelles remontent immédiatement, pas seulement en Sprint Review.
Q5.Les désaccords techniques ou produit se règlent en réunion, pas en couloir.
Se concentrer sur le Sprint Goal et sur ce qui a le plus de valeur.
Q1.L'équipe sait citer son Sprint Goal actuel sans regarder Jira.
Q2.Le WIP (work in progress) est limité et respecté.
Q3.Les interruptions externes en cours de Sprint sont filtrées par le Product Owner.
Q4.Le Daily Scrum sert à inspecter la progression vers le Sprint Goal, pas à faire du reporting.
Q5.L'équipe évite le multi-projet et n'est pas éclatée sur plusieurs produits simultanément.
Transparence sur le travail, les difficultés et les résultats.
Q1.Le Sprint Backlog est visible et à jour, accessible à toute la Scrum Team.
Q2.Les échecs et les bugs sont discutés ouvertement en Retrospective, sans blâme.
Q3.Les stakeholders reçoivent en Sprint Review l'Increment réel, pas une démo maquillée.
Q4.Les métriques (vélocité, dette technique, incidents) sont partagées avec tous.
Q5.Les membres partagent leurs doutes et zones d'ignorance sans crainte.
Respect mutuel entre membres, avec les stakeholders et les utilisateurs.
Q1.Les décisions du Product Owner sur la priorisation sont respectées, même en cas de désaccord.
Q2.Les Developers respectent l'auto-organisation et n'imposent pas de solutions à leurs collègues.
Q3.Le Scrum Master est traité comme un pair, pas comme un chef de projet ou un secrétaire.
Q4.L'équipe respecte les time-boxes des événements Scrum.
Q5.Les feedbacks entre membres sont directs mais bienveillants, jamais personnels.
Interprétation des scores
| Score global | Niveau | Situation | Priorité |
|---|---|---|---|
| 85–100 % | Excellent | Culture Scrum solide, valeurs vécues. | Transmission, mentorat, exigence continue. |
| 65–84 % | Bon | Fondations solides, une ou deux valeurs faibles. | Cibler la valeur la plus basse sur 2–3 Sprints. |
| 40–64 % | À améliorer | Scrum devient mécanique, sens qui s'efface. | Plan de coaching structuré, implication du management. |
| 0–39 % | Critique | Cargo-cult : événements sans valeurs. | Intervention urgente, Agile Coach externe recommandé. |
Attention aux moyennes trompeuses : un score global à 70 % peut cacher une valeur à 30 %. Regardez toujours le détail par valeur et le radar avant de conclure.
Comment améliorer chaque valeur
Une fois la valeur la plus faible identifiée, utilisez la fiche de coaching correspondante ci-dessous. Chaque fiche est structurée en 5 blocs — symptômes observables, causes profondes, ateliers de facilitation, actions concrètes, erreurs à éviter — pour vous permettre d'agir immédiatement.
- Sprint Goal rarement atteint.
- PBI qui glissent d'un Sprint à l'autre sans discussion.
- Silence pendant le Sprint Planning.
- Sprint Goal imposé, pas co-construit.
- Charge de travail non maîtrisée par les Developers.
- Objectifs individuels contradictoires avec l'objectif d'équipe.
- « Co-écriture du Sprint Goal » : Product Owner + Developers, 30 min avant le Planning.
- « Working Agreements » : formaliser les engagements collectifs de l'équipe.
- Terminer chaque Sprint Planning par une phrase : « Nous nous engageons à… ».
- Suivre le taux d'atteinte du Sprint Goal (pas la vélocité) sur 6 Sprints.
- Confondre engagement (Sprint Goal) et forecast (PBI livrables).
- Imposer un engagement sans négociation.
- Problèmes qui sortent seulement en Retrospective.
- Compromis répétés sur la Definition of Done.
- Silence face à des demandes managériales déraisonnables.
- Manque de sécurité psychologique.
- Culture du « ne pas faire de vagues ».
- Scrum Master trop conciliant.
- « Fears & Wishes » : chacun exprime ses peurs et souhaits sans jugement.
- « Kill the Company » : imaginer collectivement ce qui pourrait faire échouer le produit.
- Instaurer un « bad news first » en Daily Scrum.
- Le Scrum Master modélise le courage en osant nommer les non-dits.
- Confondre courage et agressivité.
- Attendre la Retrospective pour aborder un sujet urgent.
- Sprint Goal oublié dès le Daily.
- Multi-tâches et changements de priorité en cours de Sprint.
- Beaucoup de work in progress, peu de Done.
- Sprint Goal générique ou flou.
- Product Owner qui ne protège pas le Sprint.
- Équipe éclatée sur plusieurs produits.
- « One Sprint = one Goal » : reformuler le Sprint Goal en une phrase testable.
- « WIP limit game » : simuler l'effet des limites de work in progress.
- Afficher le Sprint Goal en haut du board.
- Le Product Owner négocie systématiquement l'entrée de tout nouveau besoin.
- Un Sprint Goal qui n'est qu'une liste de PBI.
- Accepter chaque interruption « juste cette fois ».
- Sprint Review qui masque les difficultés.
- Bugs cachés jusqu'au dernier moment.
- Dashboards partiels réservés au management.
- Culture du blâme.
- Peur de la sanction en cas d'échec.
- Absence de rituels de partage.
- « Lean Coffee » ouvert aux stakeholders pour aborder les vrais sujets.
- « Blameless Post-mortem » après chaque incident important.
- Rendre le Sprint Backlog et les métriques accessibles à tous.
- Présenter en Sprint Review l'Increment tel qu'il est, pas maquillé.
- Ouvrir seulement quand tout va bien.
- Confondre transparence et surveillance individuelle.
- Décisions du Product Owner remises en cause publiquement.
- Feedbacks personnels ou moqueries en Retrospective.
- Scrum Master pris pour un secrétaire.
- Rôles Scrum mal compris.
- Culture organisationnelle très hiérarchique.
- Absence de règles de communication.
- « Rôles clarifiés » : exercice sur les responsabilités du Product Owner, du Scrum Master et des Developers.
- « Feedback framework » : structurer les feedbacks (fait, effet, ressenti, demande).
- Rappeler les time-boxes en début d'événement et les tenir.
- Valoriser publiquement les comportements respectueux.
- Confondre respect et absence de conflit.
- Éviter les feedbacks difficiles au nom du respect.
8 situations d'équipe et valeurs en cause
Chaque situation ci-dessous décrit un cas fréquent, identifie les valeurs Scrum atteintes et propose une action de coaching immédiate.
Deux Developers s'opposent constamment sur les choix techniques, les Daily deviennent tendus.
Retrospective dédiée avec un protocole « fact / feeling / request ». Le Scrum Master facilite, ne juge pas.
Les Developers exécutent les tickets sans challenger le Sprint Goal ni proposer d'améliorations.
Redonner du sens : lier chaque PBI au Product Goal, co-construire le Sprint Goal, faire tourner les rôles en Retrospective.
Le Product Owner ne répond pas aux questions en cours de Sprint, priorise à la dernière minute.
Rendre visible le coût de son absence (indicateurs de blocage). Négocier une disponibilité minimale (ex. 1 h/jour) formalisée dans les Working Agreements.
Le Scrum Master pilote comme un chef de projet, distribue les tâches, contrôle les estimations.
Coaching du Scrum Master : passer de « command & control » à « servant leadership », déléguer la facilitation à tour de rôle.
Fuseaux horaires différents, langues variées, sensation de deux sous-équipes.
Aligner sur un Sprint Goal unique, systématiser l'asynchrone (Loom, notes partagées), Daily hybride avec caméras et tour de parole.
Le management impose des dates de livraison et fait sauter des critères de la Definition of Done.
Le Scrum Master doit oser dire « non » et rendre visible la dette technique produite. Impliquer le management dans les Sprint Reviews.
La vélocité chute, les bugs se multiplient, l'équipe n'ose plus modifier certaines parties du code.
Rendre la dette visible (dashboard), négocier avec le PO un pourcentage stable de capacité, refuser toute nouvelle PBI sans Definition of Done.
Sprint Goal non atteint, plusieurs PBI non terminées, ambiance morose.
Retrospective centrée sur les causes systémiques, pas sur les personnes. Réajuster la capacité, resserrer le Sprint Goal du prochain Sprint.
Checklist universelle
Au-delà du score, une équipe qui vit les valeurs présente 10 marqueurs observables. Cochez ceux que vous constatez régulièrement dans votre équipe.
Les 10 erreurs les plus fréquentes
À quelle fréquence refaire ce diagnostic ?
L'auto-diagnostic n'est utile que dans la durée. Voici une cadence éprouvée sur des équipes coachées par Passe Ton Scrum :
- Baseline : dès la formation de l'équipe ou dès votre arrivée comme Scrum Master.
- Après 3 Sprints : premier point pour ajuster les Working Agreements.
- Tous les 3 mois ensuite, en préparation d'une Retrospective trimestrielle.
- Après un événement majeur : changement de PO, incident critique, réorganisation.
Conclusion
Les valeurs Scrum ne se décrètent pas, elles se cultivent. Cet auto-diagnostic vous donne une lecture honnête de l'état actuel de votre équipe et un plan d'action concret par valeur. La suite se joue dans votre prochaine Retrospective : choisissez la valeur la plus faible, engagez-vous sur deux actions, et refaites le diagnostic dans six semaines. C'est ce cycle inspection–adaptation, appliqué à la culture elle-même, qui distingue les équipes Scrum performantes.