9 min lecture • Guide 52 of 877
Construire des Rétrospectives de Sprint Efficaces
Les rétrospectives sont la cérémonie la plus sous-utilisée en agile. Bien faites, elles composent les améliorations d'équipe au fil du temps. Mal faites, elles deviennent des sessions de plaintes qui ne changent rien. GitScrum fournit la structure pour exécuter des rétrospectives qui identifient les vrais problèmes, génèrent des améliorations actionnables et trackent le suivi entre les sprints.
Le Problème de la Rétrospective
Pourquoi la plupart des rétrospectives échouent à créer du changement:
| Pattern Commun | Résultat |
|---|---|
| Mêmes problèmes chaque sprint | Rien résolu, équipe perd confiance |
| Défoulement sans solutions | Se sent bien momentanément, pas d'amélioration |
| Actions disparaissent | Items accordés jamais trackés ou complétés |
| Voix les plus fortes dominent | Introvertis et nouveaux ne contribuent pas |
| Pas de données, juste sentiments | Opinions subjectives sans preuve |
| Sauter quand occupé | Amélioration devient optionnelle |
Préparation Rétrospective
Collecte Données Avant Réunion
COLLECTE DONNÉES PRÉ-RÉTROSPECTIVE:
┌─────────────────────────────────────────────────────────────┐
│ RÉSUMÉ MÉTRIQUES SPRINT 24 │
├─────────────────────────────────────────────────────────────┤
│ │
│ VÉLOCITÉ & COMPLÉTION: │
│ ├── Engagé: 42 points │
│ ├── Complété: 38 points (90%) │
│ ├── Reporté: 4 points (1 histoire) │
│ └── Tendance: ↓ depuis 95% sprint passé │
│ │
│ MÉTRIQUES FLUX: │
│ ├── Cycle time moyen: 3.2 jours (↑ depuis 2.8) │
│ ├── Histoires bloquées: 4 (temps bloqué: 6 jours) │
│ └── Violations WIP: 2 occasions │
│ │
│ QUALITÉ: │
│ ├── Bugs trouvés dans sprint: 3 │
│ ├── Bugs échappés en prod: 1 │
│ └── Dette technique ajoutée: 2 items flaggés │
│ │
│ INTERRUPTIONS: │
│ ├── Travail non planifié: 5 points │
│ ├── Changements scope: 2 histoires modifiées │
│ └── Usage buffer: 80% │
│ │
│ SANTÉ ÉQUIPE (sondage pulse): │
│ ├── Satisfaction générale: 3.8/5 (↓ depuis 4.1) │
│ ├── Rythme soutenable: 3.2/5 │
│ └── Clarté objectifs: 4.2/5 │
│ │
└─────────────────────────────────────────────────────────────┘
Pré-Collecte Async
INPUT RÉTRO ASYNC (GitScrum Discussions):
┌─────────────────────────────────────────────────────────────┐
│ 📝 Input Rétrospective Sprint 24 │
│ Date limite: Vendredi 16h (avant rétro 17h) │
├─────────────────────────────────────────────────────────────┤
│ │
│ Veuillez ajouter vos pensées (option anonyme disponible): │
│ │
│ CE QUI A BIEN MARCHÉ (continuer): │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ • Pair programming sur feature auth était super - @Kim ││
│ │ • Daily standups restés sous 10 min - @Alex ││
│ │ • Sprint goal clair a aidé à prioriser - [anon] ││
│ │ • Bonne collaboration avec équipe design - @Jordan ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ CE QUI N'A PAS MARCHÉ (arrêter ou changer): │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ • Bloqués sur spec API pendant 3 jours - @Sam ││
│ │ • Trop de réunions mardi - [anon] ││
│ │ • Histoire beaucoup plus grande qu'estimé - @Kim ││
│ │ • Exigences floues sur feature dashboard - @Pat ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ IDÉES & EXPÉRIENCES: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ • Essayer mob programming pour histoires complexes ││
│ │ • Bloquer matins de mardi pour travail profond ││
│ │ • Ajouter revue contrat API au DoR - @Sam ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Formats Rétrospective
Format Standard (45-60 min)
AGENDA RÉTROSPECTIVE:
┌─────────────────────────────────────────────────────────────┐
│ TEMPS │ ACTIVITÉ │
├───────┼─────────────────────────────────────────────────────┤
│ 5min │ OUVERTURE │
│ │ • Revoir actions rétro précédente │
│ │ • Partager métriques sprint (sans jugement) │
│ │ • Rappel règles de base │
│ │ │
│ 10min │ COLLECTER DONNÉES │
│ │ • Revoir input async déjà soumis │
│ │ • Ajouter items de dernière minute │
│ │ • Clarifier items flous │
│ │ │
│ 15min │ GÉNÉRER INSIGHTS │
│ │ • Vote par points sur items plus impactants │
│ │ • Discuter top 2-3 items en profondeur │
│ │ • Identifier causes racine, pas juste symptômes │
│ │ │
│ 15min │ DÉCIDER ACTIONS │
│ │ • Convertir insights en expériences spécifiques │
│ │ • Assigner owner pour chaque action │
│ │ • Définir critères succès et timeline │
│ │ │
│ 5min │ CLÔTURE │
│ │ • Résumer actions convenues │
│ │ • Feedback rétro (comment était cette rétro?) │
│ │ • Créer action items dans GitScrum │
│ │
└─────────────────────────────────────────────────────────────┘
Format Rapide (20 min)
RÉTROSPECTIVE RAPIDE:
┌─────────────────────────────────────────────────────────────┐
│ POUR: Sprints courts, équipes stables, périodes calmes │
├─────────────────────────────────────────────────────────────┤
│ │
│ 3min │ Statut actions précédentes (rapide pass/fail) │
│ │
│ 5min │ Check-in un mot de chaque personne │
│ │ "Décrivez ce sprint en un mot" │
│ │ Explication rapide pourquoi │
│ │
│ 7min │ Quelle est l'UNE chose qu'on devrait améliorer? │
│ │ Chaque personne écrit une suggestion │
│ │ Vote rapide, choisir item top │
│ │
│ 5min │ Définir action pour item top │
│ │ Qui, quoi, pour quand │
│ │ Critères de succès │
│ │
└─────────────────────────────────────────────────────────────┘
Analyse Cause Racine
Technique Cinq Pourquoi
EXEMPLE: Pourquoi n'avons-nous pas respecté l'engagement?
┌─────────────────────────────────────────────────────────────┐
│ ANALYSE CINQ POURQUOI │
├─────────────────────────────────────────────────────────────┤
│ │
│ SYMPTÔME: On n'a pas complété l'histoire dashboard (4 pts) │
│ │
│ POURQUOI 1: Pourquoi ne l'avons-nous pas complétée? │
│ → "On a manqué de temps; c'était plus gros qu'estimé" │
│ │
│ POURQUOI 2: Pourquoi c'était plus gros qu'estimé? │
│ → "L'API dont on avait besoin n'était pas prête, on a dû │
│ construire solution temporaire" │
│ │
│ POURQUOI 3: Pourquoi l'API n'était pas prête? │
│ → "Équipe backend travaillait sur priorité différente" │
│ │
│ POURQUOI 4: Pourquoi on ne savait pas cette dépendance? │
│ → "On n'a pas revu dépendances en sprint planning" │
│ │
│ POURQUOI 5: Pourquoi on ne revoit pas dépendances? │
│ → "On n'a pas de checklist pour ça, et on est pressés" │
│ │
│ CAUSE RACINE: Manque revue dépendances dans processus │
│ │
│ ACTION: Ajouter "check dépendances" au Definition of Ready │
│ Revoir dépendances cross-team avant engagement │
│ │
└─────────────────────────────────────────────────────────────┘
Tracking Actions
Framework Expérience
ACTION ITEM COMME EXPÉRIENCE:
┌─────────────────────────────────────────────────────────────┐
│ 🧪 EXPÉRIENCE: SLA Revue PR 24 Heures │
│ Amélioration Sprint 25 │
├─────────────────────────────────────────────────────────────┤
│ │
│ HYPOTHÈSE: │
│ "Si on implémente SLA revue PR de 24 heures, alors │
│ cycle time diminuera de 3.2 jours à 2.5 jours ou moins." │
│ │
│ OWNER: @Alex │
│ DURÉE: 2 sprints (Sprint 25-26) │
│ │
│ CRITÈRES SUCCÈS: │
│ ├── 90% PRs revues dans 24 heures │
│ ├── Cycle time ≤ 2.5 jours │
│ └── Pas de diminution qualité revue │
│ │
│ IMPLÉMENTATION: │
│ ├── Ajouter rappel Slack pour PRs ouverts >12h │
│ ├── Équipe accepte vérifier queue PR deux fois/jour │
│ ├── Limiter taille PR à <400 lignes de code │
│ └── Tracker temps revue dans métriques sprint │
│ │
│ MESURE: │
│ ├── Temps revue PR (métriques GitHub/GitLab) │
│ ├── Cycle time global (analytics GitScrum) │
│ └── Bugs trouvés en code review vs. après merge │
│ │
│ PLAN ROLLBACK: │
│ Si équipe se sent pressée ou qualité baisse, revenir et │
│ essayer solution alternative. │
│ │
└─────────────────────────────────────────────────────────────┘
Techniques Facilitation
Assurer Participation
FACILITATION INCLUSIVE:
┌─────────────────────────────────────────────────────────────┐
│ TECHNIQUES POUR PARTICIPATION ÉQUILIBRÉE │
├─────────────────────────────────────────────────────────────┤
│ │
│ 1. ÉCRITURE SILENCIEUSE D'ABORD │
│ Tout le monde écrit pensées avant discussion │
│ Empêche voix fortes d'ancrer │
│ │
│ 2. PARTAGE ROUND-ROBIN │
│ Chaque personne partage un item à tour de rôle │
│ Pas d'interruptions pendant le tour de quelqu'un │
│ Option de passer disponible │
│ │
│ 3. OPTION INPUT ANONYME │
│ Permettre soumission anonyme pour sujets sensibles │
│ GitScrum Discussion commentaires anonymes activés │
│ │
│ 4. VOTE PAR POINTS │
│ Tout le monde a votes égaux (ex: 3 points) │
│ Vote silencieux empêche influence │
│ │
│ 5. BREAKOUTS PETITS GROUPES │
│ Groupes 2-3 personnes pour discussion profonde │
│ Introvertis souvent plus confortables │
│ │
│ 6. ROTATION FACILITATEUR │
│ Personne différente mène chaque rétro │
│ Perspectives fraîches, ownership partagé │
│ │
└─────────────────────────────────────────────────────────────┘
Meilleures Pratiques
Faire
RÉTROSPECTIVES EFFICACES:
✓ PRÉPARER AVEC DONNÉES
Apporter métriques, pas juste opinions
✓ CRÉER SÉCURITÉ
Options anonymes, pas de blâme, regarder devant
✓ SE CONCENTRER SUR PEU D'ACTIONS
2-3 actions bien exécutées > 10 oubliées
✓ FAIRE ACTIONS SPÉCIFIQUES
Owner, timeline, critères succès, tracké dans GitScrum
✓ FAIRE SUIVI
Revoir actions précédentes, célébrer complétées
✓ VARIER LE FORMAT
Garder frais, adapter format à situation
✓ PROTÉGER LE TEMPS
Jamais sauter rétros, même quand occupé
Ne Pas Faire
ANTI-PATTERNS RÉTROSPECTIVE:
✗ BLÂMER INDIVIDUS
Se concentrer sur processus, pas personnes
✗ TOUT PARLER, PAS D'ACTION
Si vous ne pouvez pas vous engager, n'acceptez pas
✗ MANAGER DOMINE
Créer espace pour voix de l'équipe
✗ IGNORER RÉPÉTITION
Même problème = solution précédente n'a pas marché
✗ SE PRESSER
Discussion qualité > cocher une case