Démo système et Inspecter et Adapter

La Démo système a lieu à la fin de chaque itération. Contrairement aux démos d'équipe individuelles qui montrent le travail de chaque équipe de manière isolée, la Démo système présente un logiciel fonctionnel intégré à travers toutes les équipes du train de livraison agile (ART).

Pourquoi l'intégration au niveau du système est importante :

Les démos d'équipe individuelles peuvent sembler excellentes alors que le système global est défaillant. L'équipe A a terminé son API. L'équipe B a terminé son interface utilisateur. Mais elles ne se sont jamais intégrées — et quand elles le font, rien ne fonctionne. La Démo système force cette intégration à se produire toutes les 2 semaines, et non à la fin du PI quand il est trop tard.

Organiser une Démo système efficace :

• Préparation : L'ART intègre tout le travail des équipes dans un environnement de préproduction avant la démo. Les pipelines CI/CD devraient rendre cela automatique — si vous avez besoin d'un « sprint de consolidation » pour intégrer, votre CI est défaillant.
• Public : Parties prenantes, propriétaires d'affaires, direction. C'est leur fenêtre sur la progression du développement. Rendez-la accessible aux personnes non techniques.
• Format : Montrez un logiciel fonctionnel, pas des diapositives. Démontrez des scénarios de bout en bout qui traversent les frontières des équipes. Mettez en évidence ce qui est nouveau, ce qui a changé et quels risques subsistent.
• Durée : 1 à 2 heures, selon la taille de l'ART.
• Rétroaction : Sollicitez activement la rétroaction. Qu'est-ce qui fonctionne ? Qu'est-ce qui manque ? Qu'est-ce qui doit changer ? Cette rétroaction façonne les priorités de la prochaine itération.

La Démo système est le principal mécanisme de responsabilisation de l'ART. Vous pouvez cacher la progression dans des rapports d'état. Vous ne pouvez pas la cacher dans une démo en direct d'un logiciel fonctionnel.

Inspecter et Adapter (I&A) est la rétro au niveau du PI. Elle a lieu à la fin de chaque PI (pendant l'itération d'innovation et de planification) et implique l'ensemble de l'ART. Alors que les rétros d'équipe se concentrent sur les améliorations au niveau de l'équipe, I&A aborde les problèmes systémiques qui touchent plusieurs équipes.

L'événement I&A comporte trois parties :

1. Démo système du PI (1 à 2 heures) — Une démo complète de tout ce qui a été livré pendant le PI. C'est la Démo système finale et définitive montrant l'incrément complet de valeur. Les propriétaires d'affaires évaluent la valeur réelle livrée par rapport aux objectifs du PI.

2. Mesure quantitative (30 min) — Examinez les données objectives :

• Mesure de prévisibilité : Valeur d'affaires planifiée vs réelle (chaque objectif du PI s'est vu attribuer une valeur d'affaires ; combien a été livré ?)
• Tendances de vélocité : Les équipes accélèrent-elles, se stabilisent-elles ou ralentissent-elles ?
• Métriques de flux : Délai d'exécution, débit, tendances du travail en cours
• Métriques de qualité : Tendances des défauts, défauts échappés, couverture des tests

3. Atelier de résolution de problèmes (1,5 à 2 heures) — La partie la plus précieuse. L'ART identifie les principaux problèmes et utilise une résolution de problèmes structurée :

• Remue-méninges sur les problèmes (tout le monde contribue)
• Vote sur les problèmes les plus impactants à résoudre
• Analyse des causes profondes (5 Pourquoi, diagramme en arête de poisson)
• Définir des récits d'amélioration avec des critères d'acceptation clairs
• Ajouter les récits d'amélioration au backlog du prochain PI

Le résultat d'I&A est des éléments d'amélioration concrets qui vont dans le backlog du programme. Ce ne sont pas des intentions vagues — ce sont des récits estimés avec des responsables qui rivalisent pour la capacité dans le prochain PI.

La partie la plus difficile de l'amélioration continue n'est pas d'identifier les problèmes — c'est de les mener à terme. I&A produit des récits d'amélioration, mais ces récits doivent réellement être réalisés.

Stratégies pour faire perdurer l'amélioration :

• Traitez les récits d'amélioration comme des récits de fonctionnalités : Ils vont sur le tableau, ils ont des critères d'acceptation, ils sont démontrés. Ne les cachez pas dans une liste séparée de « dette technique » que personne ne regarde.
• Allouez de la capacité : Réservez 10 à 20 % de la capacité de chaque équipe pour le travail d'amélioration. Rendez cela explicite pendant la planification du PI.
• Suivez les métriques d'amélioration : Les délais d'exécution raccourcissent-ils ? La prévisibilité s'améliore-t-elle ? La qualité est-elle en hausse ? Si vos récits d'amélioration ne font pas bouger les métriques, vous résolvez les mauvais problèmes.
• Rétro des rétros : Examinez périodiquement si I&A génère réellement du changement. Les mêmes problèmes refont-ils surface PI après PI ? Si oui, l'analyse des causes profondes n'est pas assez approfondie.
• Célébrez les victoires : Quand un récit d'amélioration résout un point de douleur de longue date, reconnaissez-le. Cela renforce la culture d'amélioration.

La mesure de prévisibilité :

SAFe utilise une formule spécifique : somme de la valeur d'affaires réalisée ÷ somme de la valeur d'affaires planifiée × 100 %. Un ART en santé obtient constamment un score de 80 à 100 %. En dessous de 80 % suggère des problèmes de planification (surengagement, mauvaise estimation ou trop de perturbations imprévues).

La prévisibilité ne concerne pas la perfection — elle concerne la construction de la confiance qui permet à l'entreprise de planifier autour de la livraison. Un ART qui livre de manière fiable 85 % de la valeur engagée est infiniment plus précieux qu'un qui promet 100 % et livre de manière imprévisible.