Velocity
Atelier IT / Dev
VELOCITY.
Un serious game de 90 minutes
Défi destiné aux équipes agiles et scrum teams.
La ville qui change de plan à chaque sprint.
⏱ 90 minutes
👥 6 – 12 personnes
🎮 Minecraft Créatif
✦ Redstone optionnelle
Ancrage Serious Gaming
Pourquoi construire une ville est le bon terrain pour l'agilité
Dans Minecraft, chaque bloc posé est un livrable concret. On ne peut pas prétendre avoir "presque fini" une maison — soit la porte est placée, soit elle ne l'est pas. Ce caractère binaire et visible du résultat transforme le jeu en simulateur de sprint idéalement honnête.
Le paradoxe professionnel
«On sait tous ce qu'est un sprint. Mais est-ce qu'on sait vraiment livrer quelque chose d'utilisable en 20 minutes — avec des specs qui changent entre deux ?» — Pierre-Yves Gadina · Facilitateur Serious Craft
Serious Craft tire profit d'une propriété unique de Minecraft : la dette technique est visible. Une maison construite en urgence au sprint 1, sans fenêtre ni alignement, sera physiquement gênante au sprint 2 quand les jardins devront s'y intégrer. Personne ne peut prétendre que le problème n'existe pas. Tout le monde le voit, dans l'espace, en temps réel. C'est cela que les rétrospectives classiques n'arrivent pas à produire.
Léxique
Minecraft → Agile
Pour le facilitateur — et pour les participants, en phase de debrief.
| Mécanique Minecraft | Équivalent Agile | Ce que ça révèle |
|---|---|---|
| Bloc placé | Story livrée | On livre ou on construit — pas les deux à la fois |
| Zone de sprint (terrain balisé) | Sprint boundary / timebox | La limite n'est pas négociable — même quand c'est inconfortable |
| Panneau in-game | User story / ticket Jira | La précision du langage compte. "Maison" sans spec = 12 interprétations |
| PO qui rejette un bloc | Sprint review / story rejected | DoD réelle vs DoD imaginée. Le moment de vérité |
| Héritage du sprint précédent | Backlog technique accumulé | Le passé contraint le présent. Toujours |
| Repeater clock visible | Timebox / burndown chart | Le temps passe même si on ne regarde pas le chrono |
| Maison à moitié construite à la cloche | Work in progress non livré | 90% terminé n'est pas terminé. Dans aucun sens du mot |
| Jardins à intégrer dans l'existant | Scope creep / évolution produit | Les requirements changent. Ce n'est pas une anomalie — c'est la règle |
| Bannières Keep / Stop / Start | Rétrospective formelle | L'amélioration continue n'est pas optionnelle. Elle a une adresse physique |
| Bloc rouge du mur de vélocité | Story point / métrique d'équipe | Ce qu'on mesure change ce qu'on fait |
Scénario
«CraftCity» · Défi urbanisme agile
L'équipe est mandatée comme squad de développement de CraftCity, une ville en construction.
Le PO (le facilitateur) révèle les user stories au départ de chaque sprint — et fait évoluer les exigences entre deux. Trois sprints de 20 minutes. Une rétro de 5 minutes entre chaque. La dette s'accumule. La velocity se mesure.
Sprint 0 · Backlog & Planning initial
- Le PO présente les user stories sur des panneaux in-game. L'équipe lit, discute, priorise.
- L'équipe vote collectivement ce qu'elle prend dans le Sprint 1 (planning poker simplifié).
- Definition of Done écrite sur un panneau avant de commencer :
«Maison = porte fonctionnelle + au moins 1 fenêtre + toit fermé.» - Le Scrum Master (rôle interne) affiche le chrono.
Le mur de vélocité est vide. Le compteur est à zéro.
Sprint 1 · Quartier résidentiel — 5 maisons habitables — MUST Complete
User story
«En tant que futur habitant de CraftCity, je veux une maison avec une porte, au moins une fenêtre, et un toit fermé, pour pouvoir m'y installer à la livraison.»
Sprint de base. Accessible à tous. La DoD est claire et définie ensemble. L'enjeu n'est pas la complexité technique — c'est la coordination dans le temps imparti. Qui prend quelle maison ? L'équipe s'auto-organise ou non, et cela se voit immédiatement.
Porte (wooden door)
Fenêtre (glass pane)
Toit en pente
Zone Sprint 1 balisée
À la Sprint Review
Le PO mesure chaque maison à la DoD. Un bloc rejeté = un bug. L'équipe compte sa velocity : nombre de maisons acceptées / 5.
Sprint 2 · Jardins + chemin central — les maisons restent — TARGET
User story
«Le client demande maintenant un jardin devant chaque maison et un chemin central reliant toutes les entrées. Les maisons du Sprint 1 ne bougent pas.»
La première vraie friction apparaît ici. Les maisons mal alignées du Sprint 1 compliquent l'intégration des jardins. Les équipes qui ont construit "vite et n'importe comment" découvrent leur dette physiquement. Le chemin central est le premier composant qui nécessite une coordination entre toute l'équipe — il appartient à tout le monde et à personne en particulier.
Chemin (gravel / path)
Jardins (grass + flowers)
Alignement maisons existantes
Intégration sprint précédent
Moment clé :
Qui "possède" le chemin ? Comment les décisions se prennent-elles sur un composant partagé ? C'est la version physique du problème de ownership en agile.
Sprint 3 · Éclairage public — le Graal — Objectif d'équipe
User story
«Les rues de CraftCity doivent être éclairées la nuit. Chaque maison doit avoir une lanterne à sa porte. Le chemin central doit avoir des lampadaires réguliers.»
L'équipe hérite de tout le Sprint 1 + Sprint 2. Elle ne peut plus construire sans composer avec ce qui existe. L'objectif stretch : un système d'éclairage automatique (daylight sensor → torches qui s'allument à la tombée de la nuit). Cela introduit la Redstone de manière organique, sans la rendre obligatoire.
Lanternes (lantern)
Lampadaires
Daylight sensor (bonus)
Redstone optionnelle
Le stretch goal Redstone révèle l'appétit pour l'automatisation dans l'équipe. Certains profils vont le trouver instinctivement. D'autres vont le découvrir. Les deux comportements sont également riches pour le debrief.
Bonus • Tour de vélocité — tableau de bord public — Si le temps le permet
User story
Une tour centrale avec un "dashboard" physique : panneau indiquant la velocity de chaque sprint (blocs acceptés), compteur de rejets, et un signal Redstone vert/rouge indiquant l'état de santé du quartier. Réservé aux équipes qui ont terminé les 3 sprints avec du temps devant elles.
Tour centrale
Panneaux métriques
Signal Redstone d'état
Rôles
6 à 12 personnes
Product Owner
Facilitateur SC
Révèle les user stories au départ de chaque sprint. Accepte ou rejette les livrables selon la DoD. Modifie les exigences entre les sprints. Crée une pression réaliste sur des specs qui évoluent. Joue les edge cases à la Sprint Review.
Scrum Master
1 personne
Tient le chrono. Facilite les mini-rétros entre sprints. Protège l'équipe des distractions. Affiche les métriques sur le mur de vélocité. Peut aussi jouer le rôle de coordinateur d'intégration au Sprint 3.
Squad Dev
4 – 8 personnes
Construisent. S'auto-organisent. Décident qui prend quoi. Gèrent la dette accumulée entre les sprints. Leur manière de se coordonner (ou pas) est la matière première du debrief.
Stakeholder
1 personne
Optionnel • Observe le Sprint 1 sans intervenir. Au Sprint 2, peut poser une question sur le produit (et non sur la technique). Révèle la distance entre ce que l'équipe construit et ce qu'un utilisateur attend. Fort impact sur la discussion de debrief.
Chronologie
⏱️ 90 minutes
0 ~ 10’
Briefing & onboarding
Contexte: CraftCorp, en Creative mode. Tour rapide des composants Redstone. Le facilitateur démontre 1 circuit simple en 2 minutes.
▶️ Pas de Minecraft préalable requis
10 ~15’
Sprint architecture — sur papier
L'équipe dessine le système avant de construire. Qui fait quoi ? Quelles sont les interfaces entre composants ? C'est le "API contract" physique.
❇️ La phase la plus révélatrice du workshop
15 ~ 35’
Build sprint 1 — composants isolés
Chaque sous-équipe construit son composant. Les niveaux 1 et 2 doivent être complétés ici. Travail en parallèle = simulation de développement concurrent.
🟢 Intégration niveau 1 et 2
35 ~ 40’
Sprint intégration — le moment de vérité ✦
Les composants doivent se connecter. C'est ici que tout se joue : les interfaces mal définies, les assumptions non communiquées, les "ça marchait chez moi" apparaissent. Le Graal (niveau 3) est l'objectif.
🟠 Point de friction maximal — or pour le debrief
40 ~ 65’
Demo & stress test client
Le facilitateur (PO) teste le système avec des cas limites. L'équipe présente ce qui fonctionne, et documente ce qui ne fonctionne pas.
🔴 Livraison sprint
65 ~ 70’
Debrief structuré
Le cœur du serious game. Les questions relient l'expérience Minecraft à la réalité de l'équipe.
✅ 70% de l'apprentissage se passe ici.
70 ~ 80’
Debrief structuré
Le cœur du serious game. Les questions relient l'expérience Minecraft à la réalité de l'équipe.
✅ 70% de l'apprentissage se passe ici.
80 ~ 90’
Debrief structuré
Le cœur du serious game. Les questions relient l'expérience Minecraft à la réalité de l'équipe.
✅ 70% de l'apprentissage se passe ici.
