Cycle en V vs Scrum : les erreurs qui vous font échouer à PSM I / PSM II

Pourquoi les profils cycle en V échouent à l’examen PSM

Vous préparez PSM I ou PSM II après des années en cycle en V ?
Alors vous avez probablement déjà rencontré ce problème : vous connaissez Scrum, mais au moment de répondre, vos réflexes restent prédictifs.

• Prolonger un Sprint pour finir le travail.

• Voir le Scrum Master comme un chef de projet agile.

• Figer le backlog pour obtenir des spécifications complètes.

Ce décalage explique pourquoi beaucoup de candidats expérimentés échouent alors même qu’ils ont une bonne maîtrise théorique.

Le problème n’est pas leur niveau. Le problème, c’est leur grille de lecture.

Scrum.org n’évalue pas un cycle en V accéléré. Scrum.org évalue une logique empirique fondée sur la transparence, l’inspection et l’adaptation.

Dans cet article, vous allez comprendre la vraie rupture entre cycle en V et Scrum, les pièges les plus fréquents à l’examen, et la bonne manière de raisonner pour éviter ces erreurs.

Explication Détaillée : Cycle en V vs Scrum

Le cycle en V, hérité de l'ingénierie des années 70, structure le projet en deux branches symétriques.

La phase descendante part de l'analyse des besoins, passe par la conception de l'architecture, puis le développement des modules.

La phase ascendante remonte par les tests unitaires, l'intégration, les tests système et enfin la recette finale.

Tout est planifié en amont et le triangle temps/coût/périmètre est figé dès la signature du contrat. Cette méthode excelle pour la traçabilité et le contrôle qualité dans des environnements stables. Mais elle montre vite ses limites : elle est rigide face aux changements, et l'effet tunnel fait que les erreurs ne sont souvent détectées qu'en production, où les bugs remontent trop tard.​​

Scrum, framework Agile du Manifeste 2001, adopte une logique radicalement différente. Les sprints timeboxés (1 à 4 semaines) permettent de livrer un Incrément potentiellement utilisable à intervalles réguliers. L'équipe inspecte le travail accompli lors de la Sprint Review et de la Rétrospective, puis adapte le backlog en conséquence.

Trois piliers soutiennent cette démarche empirique :

• la transparence (les artefacts sont visibles de tous),

• l'inspection (les événements permettent d'examiner régulièrement la progression),

• l'adaptation (le backlog évolue en continu selon les retours).

  Trois rôles composent la Scrum Team :

• le Product Owner qui maximise la valeur produit,

• les Developers qui s'auto-organisent pour livrer chaque incrément,

• et le Scrum Master qui maintient le cadre et aide à lever les obstacles.

  Cinq événements structurent Scrum :

• le Sprint:

• le Sprint Planning,

• le Daily Scrum (15 minutes de synchronisation quotidienne),

• la Sprint Review (présentation aux stakeholders),

• et la Sprint Retrospective (amélioration du fonctionnement d'équipe).

La rupture est fondamentale : là où le cycle en V cherche à prédire et contrôler, Scrum assume l'incertitude et apprend en itérant.

À l'examen PSM, "suivre le plan figé malgré le feedback" est toujours faux ; "adapter via l'empirisme" est toujours juste

Les Erreurs Fréquentes à l'Examen

Les profils issus du cycle en V sont particulièrement exposés à ces erreurs.

Voici les cinq pièges les plus fréquents.

Top 5 des pièges :

1. Prolonger le sprint pour finir le travail : Dans le cycle en V, il est courant d'étendre les délais lorsqu'une phase prend du retard. En Scrum, la timebox du Sprint est intangible : on ne la prolonge jamais. Si l'équipe n'a pas terminé le Sprint Backlog, on analyse la cause en Rétrospective et on adapte le Sprint Planning suivant.​

2. Confondre Scrum Master et chef de projet : Le cycle en V centralise les décisions sur le chef de projet. En Scrum, le Scrum Master n'assigne pas les tâches et ne gère pas les performances individuelles. Il est un leader-serviteur : il coache, facilite, protège l'équipe et lève les obstacles sans décider à la place des Developers.

3. Figer le backlog pour des spécifications complètes : Le V exige de tout spécifier avant de développer. En Scrum, le Product Backlog est émergent et se raffine en continu. Vouloir "bloquer le sprint pour specs exhaustives" est une erreur typique qui ignore l'empirisme au cœur de Scrum.​

4. Réserver les tests à la fin : Le V concentre les tests en fin de cycle, avec des risques élevés d'erreurs en production. Scrum exige une Definition of Done respectée à chaque sprint : chaque Incrément doit être potentiellement livrable, testé et conforme avant la Review.​

5. Fermer la Sprint Review aux stakeholders : Le V s'appuie sur des handovers documentaires. En Scrum, la Sprint Review est ouverte aux parties prenantes car leur feedback est essentiel pour inspecter l'Incrément et adapter le backlog pour le sprint suivant.​

Conseils pratiques pour répondre juste

1. Gardez l'empirisme comme boussole : face à toute question ambiguë, raisonnez en transparence/inspection/adaptation. Si un changement survient mid-sprint, la bonne réponse est d'adapter le Product Backlog lors de la prochaine Review, en préservant le Sprint Goal.

2. Respectez la séparation stricte des rôles : le PO maximise la valeur, les Developers livrent l'Incrément, le SM maintient le cadre. Toute réponse qui chevauche ces responsabilités est fausse à l'examen.

3. Considérez la timebox comme absolue : la durée d'un sprint et de chaque événement est fixe et non négociable à la hausse. Prolonger ou annuler sans raison valable est toujours une mauvaise réponse.

4. Entraînez-vous dans les deux langues : les questions PSM I sont en anglais et les formulations sont souvent subtiles. Lisez le Scrum Guide en français et en anglais pour maîtriser la terminologie exacte — les moteurs de recherche traduisent parfois de façon aléatoire et trompeuse. Visez 90%+ aux Open Assessments avant de vous inscrire.

Exemple Question Type PSM I (Style Scrum.org)

Une équipe ne termine pas son Sprint Backlog. Que doit faire le Scrum Master ?

• A. Prolonger le sprint pour finir le travail.

• B. Assigner les tâches restantes aux membres disponibles.

• C. Faciliter la Rétrospective pour analyser les causes et adapter le Sprint Planning suivant.

• D. Alléger la Definition of Done pour valider l'Incrément.

La réponse correcte est C. La timebox du Sprint est fixe (A faux) ; le Scrum Master n'assigne pas de tâches, c'est le rôle des Developers de s'auto-organiser (B faux) ; la Definition of Done est non négociable et ne peut être allégée pour convenance (D faux). Seule C applique l'empirisme : on inspecte en Rétrospective et on adapte le plan suivant

Conclusion : Basculez pour Cartonner PSM

Maîtriser la différence entre cycle en V et Scrum n’est pas un simple exercice théorique. C’est ce qui vous permet de raisonner comme Scrum.org l’attend réellement à l’examen.

Tant que vous gardez des réflexes de plan figé, de contrôle centralisé et de validation tardive, vous risquez de choisir des réponses “logiques” dans votre ancien cadre… mais fausses dans Scrum.

Et c’est exactement ce qui fait la différence entre un échec à 82%… et une réussite dès le premier passage.

Si vous voulez aller plus loin, trois ressources peuvent vous aider à préparer efficacement votre certification :

PSM I : pour travailler les pièges classiques, les questions commentées et les plans de révision.
PSM II : pour vous entraîner sur des scénarios avancés et la posture réelle du Scrum Master.
L’Agilité pour tous : pour consolider les fondamentaux Agile et Scrum avant de viser l’examen.

Vous pouvez retrouver ces e-books en PDF sur ce site, ainsi qu’en version Kindle et brochée sur Amazon.

Choisissez la ressource adaptée à votre niveau et commencez une préparation plus rigoureuse, plus claire et plus rentable.