SCRUM ? Cycle en V ? Tout cela vous parle et vous voyez grossièrement les différences ? Ou bien non ? Ou bien vous les voyez précisément ? Et si, au lieu de se référer encore à la théorie, on échangeait entre professionnels de niveaux hétérogènes ? Et si vos connaissances pouvaient aider celles des autres ? Le jeu DeltaSCRUM vous propose un cadre d’échange “différence Cycle en V et SCRUM” qui permet aux joueurs et joueuses d’apprendre ou transmettre collectivement et de profiter de leurs différences

1. DeltaSCRUM : Points communs et différences
Alexandre QUACH
Pauline GARRIC
Cycle en V
& Chefs de
Projet
SCRUM
& Product
Owners
ou
10-15 joueurs
Niveaux d’XP variables
#OpenSeriousGame
Nils LESIEUR

2. Je ne m’y connais pas
trop en cycle en V et rôle
de chef de projet
Je suis très expérimenté
(e) en cycle en V et rôle
de chef de projet

3. Je ne m’y connais pas
trop en SCRUM &
Product Owners
Je suis très expérimenté
(e) en SCRUM & Product
Owners

4. Déroulement d’aujourd’hui
Présentation
du Gameplay
A vous de jouer ! Debriefing

5. Cycle en V SCRUM

6. Chef de
projet
Product
Owner

7. Gameplay
1. Placement : Chaque équipe découvre une liste de
caractéristiques à disposer dans une des zones
2. Une autre équipe pointe ses désaccords sur les dispositions
3. Nous discutons ensemble des désaccords
Cycle en
V & CdP
SCRUM &
PO
Les 2
Aucun des
2
Lorem
ipsum
Lorem
Ipsum

8. A vous de jouer !

9. Placement : Conseils
1. Indiquez à votre équipe POURQUOI vous placeriez un ticket dans
une zone donnée
2. Si vous ne pouvez pas deviner, passez à un autre ticket en criant
“Pass”, traitez les à la fin

10. Tour de revue par une autre équipe
Nous ne sommes pas
d’accord
Nous ne sommes pas
sûrs et aimerions
vraiment discuter de ce
point là au débriefing

11. Debriefing
1. Reprendre ticket marqué par ticket marqué

12. Merci et Bravo à tous !

13. Mauvaise expérience Super

14. Annexes pour l’animation

15. Public des professionnels du V : Ce meetup s’adresse aux professionnels habitués à la fonction de Chef de Projet et à la
méthodologie cycle en V (a priori majorité du marché français en informatique d’entreprise par le passé).
Apprendre le SCRUM et le Product Ownership : Il vise à familiariser ce public avec le rôle de Product Owner et avec le
framework SCRUM (a priori le framework en vogue depuis 200x).
Particulièrement, il s’agit de dépasser la surface des rôles et responsabilités formels. Le but est à la fois :
- De bien distinguer des éléments de posture (auprès de ses collègues), des pré-supposés, des contextes économiques
- D’identifier les points communs, de manière à rendre confortable d’éventuelles transition
L’important dans ce jeu n’est pas l’accord, mais plutôt l’échange autour de notions nouvelles ou difficiles.
Neutralité : Il n’y a pas de prise de position pour un framework ou pour l’autre, ou pour une posture ou pour l’autre. Au
contraire, le jeu cherche à rendre plus neutre la comparaison entre les deux frameworks, en faisant confiance aux
participants pour se faire leur avis (et prendre responsabilités de leurs risques) dans leurs contextes respectifs.
Humour : une petite partie des cartes remet en avant les stéréotypes et l’humour pour le plaisir du jeu, et également pour
encourager, par l’absurde, une plus grande profondeur de réflexion.
Objectifs pédagogiques de ce jeu

16. Mécanismes choisis
Apprendre par les échanges (vs présentation) : On fait l’hypothèse sur le public qu’il a un niveau hétérogène en SCRUM ou
Cycle en V. Cette hétérogénéité permet de générer des échanges dans les phases de disposition, d’expression de désaccord
et de debriefing. Ces échanges permettent aux “débutants” d’apprendre via un processus plus informel et naturel que le suivi
d’une présentation magistrale.
Apprentissage désordonné : On invite le public à apprendre de manière non structurée pour rendre plus dynamique les
échanges, c’est au public de trouver la cohérence entre ses réponses.
Par petites équipes : L’organisation en petites équipes permet de créer un contexte familier où on osera échanger un peu
plus (vs seul dans un public face à un coach)
Désaccord et “crowd intelligence” : Le mécanisme de faire tourner les équipes pour noter les désaccords permet d’impliquer
tous les participants dans la réflexion (vs un “coach” qui dit vrai ou faux). Cela permet aussi de préparer un débriefing plus
riche et cultive l’acceptation d’altérité des avis, essentielle dans un tel exercice.
Régulation de dernier recours : L’animateur/-trice doit maîtriser les aspects des deux frameworks, sans non plus être
dogmatique sur certains points. Cela permet de gérer le cas où l’ensemble du public est débutant et où l’essentiel du jeu se
fait en “devinant”. La confirmation des réponses repose alors sur l’animateur/-trice dans les phases de debriefing
(Facultatif) Course au temps et mesure de points : pour stimuler des tours de jeu et accélérer les décisions, on peut ajouter
une mécanique de temps limité connu à l’avance et de compétition de points. A la discrétion de l’animateur/-trice

17. A faire pour l’animateur/-trice
En amont :
● Imprimer les cartes, les découper et les mélanger.
● Imprimer la feuille de jeu où les cartes seront placées par les équipes, idéalement en A3. Les disposer aux
emplacement des équipes en amont
● Préparer feutres et stylos (pour la phase de désaccords)
Animation du jeu :
● Constituer des équipes de niveau (les questions de jauge au début peuvent aider), idéalement de 3 pour maintenir une
qualité d’échange et moins de dispersion dans les groupes
● Phase placement : Présenter le gameplay et distribuer des petits tas de cartes à chaque équipe. Les cartes peuvent
être distribuées en plusieurs tours. Si besoin (en cas de grands débutants partout par exemple), les documents de
référence peuvent être distribuées dans les équipes. Le jeu devient alors un jeu d’investigation / placement, dans un
temps limité.
● Phase désaccord : Faire tourner les équipes (ou bien les feuilles) pour le tour de d’expression de désaccord
● Debriefing : Dépiler les questions et les désaccords, exprimer son avis. S’appuyer sur des docs de référence si besoin.

18. Extension de gameplay : jouer avec les points
Ce mode est applicable aux avancés uniquement, pour creuser le sujet plus loin.
L’objectif pédagogique est de montrer que les équipes qui prennent régulièrement l’avis extérieur construiront un produit
plus facilement cohérent, et qui aura plus de valeur.
Dans ce mode de jeu,
- Des points de valeur (aléatoires) ont été attribués à chaque ticket.
- Les trois premiers tours (répartition, expression de désaccord) sont joués tel que dans le jeu de base, mais seulement
avec une partie des cartes (1 feuille sur 3)
- Ensuite, les équipes sont réparties en 2 types :
- Un type “Chef de Projet” : dans un temps imparti, ce type d’équipe devra finir TOUS ses tickets. Un Chef de projet
est désigné dans cette équipe pour faire le suivi et informer le client (l’animateur) de l’avancement des tickets. Le
chef de projet ne demande pas validation au client, il peut négocier le temps total imparti grâce à ses calculs
d’avancement.
- Un type “PO” : à intervalles réguliers courts, ce type d’équipe devra montrer sa feuille au client (animateur) pour
contrôle de cohérence (équivalent au tour de débriefing dans le jeu de base). Le PO dans cette équipe devra
prioriser aussi les tickets à faire évaluer à son équipe en amont, selon la valeur, son équipe doit pouvoir être
capable de participer à la priorisation en indiquant le niveau de facilité à placer “a priori”. Cette équipe suit la
valeur produite.

19. Extension de gameplay : jouer avec les points
Pour pimenter ce mode,
- Briefer séparément les 2 types d’équipes
- Ne leur dites pas qu’elles sont type PO ou bien type CdP, gardez les en type 1 ou type 2
- Lorsque l’équipe de type CdP vient vous voir pour négocier du temps en plus, prenez aléatoirement du temps pour leur
répondre, et accordez leur ou non un bonus/malus en délai de taille aléatoire.
- Lorsque l’équipe PO vient vous voir pour exposer ce qu’ils ont déjà fait. Demandez à voir le backlog et modifiez les
points sur ce qu’il y a à venir

20. Plateau de jeu
Imprimer en A3
Aucun des
deux
Cycle en V
et chef de
projet
SCRUM et
Product
Owner
Les deux

21. Cartes du jeu (à imprimer & découper)
Né en Allemagne
dans les années 80
1
Une phase de
“build” suivie d’une
grande mise en
service suivie d’une
phase de run
2
On peut demander
des changements
au dernier moment
sans que ça se voie
trop
3
Prévu pour des
environnements à la
prédictibilité forte
(besoin,
technologie,
contraintes, …) 2
Demande
l’excellence de la
planification,
prévision,
projection
5
Le besoin doit être
complètement
décrit
1
Né aux Etats-Unis
dans les années 90
2
Une petite mise en
production au plus
tôt, suivie de
“run-build” avec des
mises en service
régulière
5
Ca se voit tout de
suite lorsqu’on
change quelque
chose au dernier
moment
9
Prévu pour des
environnements à la
prédicbilité faible
7
Demande
l’excellence de
l’adaptation
4
Le besoin doit être
suffisamment
détaillé pour les
prochains
développements,
mais pas complet
sur tout le produit 2
Contrôle d’abord ce
qui se passe à
l’intérieur de l’
équipe. Ex: Qualité
/ Coût / délai
3
Est responsable
d’attribuer les sujets
aux développeurs
7
Spécifie
fonctionnellement
dans un premier
temps
4
Implique les
développeurs
3
Priorise d’aboard
selon la faisabilité
et la promesse
2
Mesure
régulièrement
l’avancement d’une
roadmap ou d’un
backlog
3
Contrôle d’abord ce
qui se passe à
l’extérieur de l’
équipe. Ex:
Acquisition, usages,
etc 6
Laisse les
développeurs
s’auto-organiser
8
Spécifie un usage
2
N’implique pas les
développeurs
3
Priorise d’abord
selon la valeur ou le
R.o.I
1
Mesure
régulièrement
l’impact du produit
existant
4

22. Cartes du jeu (à imprimer & découper)
Est beaucoup utilisé
dans le milieu du
Système
d’Information et
l’informatique
d’entreprise 4
L’Excellence de la
documentation est
nécessaire
3
Contrôle qualité à
la livraison finale,
en très peu de fois
3
Repose beaucoup
sur la mutualisation
de coûts
7
Sera forcément
lourd en processus
et comitologie
3
Sera forcément plus
léger en processus
et comitologie
1
Est beaucoup utilisé
dans le Web B2C, le
mobile
9
L’excellence de la
documentation est
facultative
2
Contrôle qualité en
continu
4
Repose sur le
rework
5
Ne peut qu’échouer
2
Ne peut que réussir
5
Est garant du bon
fonctionnement de l’
équipe de
développement
6
Nécessite de
bonnes
compétences de
commandement et
de contrôle
3
Ne se pratique que
dans le domaine IT
6
Doit s’habiller en
costume élégant
parce qu’il/elle
s’adresse aux
clients
9
Est beaucoup plus
humain par
construction,
permet de se
reposer sur les
processus 7
Traite plus souvent
les autres ou bien
comme des
sous-fifres ou bien
comme des
contraintes vivantes
2
Est surtout garant
de la bonne
compréhension de
la vision
7
Nécessite de
bonnes
compétences de
vente et de design
8
A un salaire très
souvent plus élevé
que l’autre
2
Est un passage
obligatoire entre les
développeurs et le
reste de la
hiérarchie
stratégique 7
Est forcément
soumis à la
hiérarchie
6

23. Cartes du jeu (à imprimer & découper)
Intègre des tests
unitaires, des tests
d’intégration, et des
tests de validation
6
Est suivi
régulièrement
4
On observe
régulièrement
l’utilisateur et ses
retours sur le
produit existants
lors de reviews 3
Permet de projeter
dans le temps la
complétion d’un
périmètre donné
2
Abuse de post-its et
permet de rester en
forme grâce à des
réunions debout
3
Les spécifications
sont rigides
4
Intègre beaucoup d’
échanges sur ce
qu’il y a à venir
7
A plus de chance de
subir un “effet
tunnel” (et ses
conséquences :
courses au dernier
moment, surprises…)
3
On ne voit
l’utilisateur qu’au
début et à la fin du
projet
6
Permet de plus
facilement de
communiquer un
cap, une ligne
directrice
4
Les “spécifications”
sont d’abord
centrées utilisateurs
pour déclencher le
dialogue 5
On n’engage que ce
qui est prêt
6
Intègre des
moments de
rétrospectives pour
s’améliorer au fur et
à mesure
6
Permet beaucoup
plus de souplesse
9
“Ce n’est pas de ma
faute si ça foire”
5
Les développeurs
n’ont pas à avoir de
vision globale du
projet, et
interviennent juste
pour le
développement 3
Prioriseur(-se) et
Concepteur(-trice),
filtre à requêtes
extérieures
6
Ca ressemble plus
au personnage de
Batman
2
Favorise la
communication
8
Très discipliné
9
“Le projet/produit,
c’est mon bébé”
8
Les développeurs
développent une
vision globale du
projet grâce à
lui/elle 7
Contrôleur(-se)
d’avancement,
d’utilisation du
budget, et de la
qualité 9
Ca ressemble plus
au personnage de
Superman
4

24. Cartes du jeu (à imprimer & découper)

25. Docs de référence (en cas de grands débutants partout)

26. Docs de référence (en cas de grands débutants partout)
Source : http://lucyinthescrum.com/checklist-pour-product-owners/
https://openclassrooms.com/courses/gerez-votre-projet-avec-une-equipe-scrum/challengez-
votre-equipe-avec-le-product-backlog-grooming