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