Itérations et qualité intégrée

Les itérations SAFe sont des périodes limitées de 2 semaines (parfois 1 ou 3 semaines, mais 2 est la norme). Chaque itération suit un cycle familier :

Planification d'itération (demi-journée) — L'équipe examine les objectifs de l'itération, tire des récits du backlog d'équipe, les décompose en tâches et s'engage sur ce qu'elle livrera. Dans SAFe, les objectifs d'itération doivent s'aligner sur les objectifs du PI établis lors de la planification du PI.

Exécution (la majeure partie de l'itération) — L'équipe travaille sur les récits, tient des mêlées quotidiennes et intègre en continu. Les récits passent par différents états : défini, en cours, terminé. L'équipe suit la progression par rapport à ses objectifs d'itération.

Revue d'itération / Démo système (1-2 heures) — L'équipe démontre le travail complété. Dans SAFe, cela alimente la démo système au niveau de l'ART où toutes les équipes montrent leur travail intégré aux parties prenantes. La démo d'équipe individuelle est une préparation pour la démo système.

Rétrospective d'itération (1 heure) — L'équipe réfléchit à ce qui s'est bien passé, ce qui ne s'est pas bien passé et ce qu'il faut améliorer. Dans SAFe, les observations de la rétrospective peuvent également alimenter l'événement Inspecter et adapter au niveau du PI.

Ce qui diffère du Scrum autonome : L'itération est synchronisée entre toutes les équipes de l'ART. Tout le monde commence et termine le même jour. Cette cadence partagée crée des points d'intégration naturels et rend la coordination inter-équipes prévisible.

Chaque PI comprend une itération d'innovation et de planification (IP) à la fin. C'est unique à SAFe et l'une de ses innovations les plus précieuses.

Ce qui se passe pendant l'IP :

• Préparation de la planification du PI : La gestion de produit prépare la vision et le backlog pour le prochain PI. Les architectes système préparent la piste architecturale. Les équipes analysent les fonctionnalités à venir.
• Événement de planification du PI : L'événement de planification en personne de 2 jours pour le prochain PI (c'est l'objectif principal de l'itération IP).
• Temps d'innovation : Les équipes utilisent le temps restant pour des hackathons, l'exploration de nouvelles technologies, le remboursement de la dette technique, la formation ou la poursuite d'idées qui ne s'intègrent pas facilement dans un backlog.
• Inspecter et adapter : La rétrospective formelle au niveau du PI où l'ensemble de l'ART réfléchit sur les données quantitatives (mesure de prévisibilité) et les observations qualitatives.

Pourquoi l'IP est importante :

Sans temps d'innovation dédié, la dette technique s'accumule, les compétences stagnent et les équipes deviennent des usines à fonctionnalités. L'itération IP est une garantie structurelle que l'amélioration et l'exploration se produisent — elle ne dépend pas de « trouver du temps » qui ne se matérialise jamais.

L'itération IP fournit également un tampon naturel. Si les équipes rencontrent une complexité inattendue pendant le PI, l'itération IP absorbe le débordement sans nécessiter d'extensions de calendrier ou de réductions de périmètre au milieu d'une itération.

SAFe est intransigeant sur la qualité : vous ne pouvez pas être agile avec du mauvais code. La qualité intégrée n'est pas un plus — c'est une valeur fondamentale et un prérequis pour un flux durable.

Pratiques d'ingénierie logicielle :

• Développement piloté par les tests (TDD) : Écrivez les tests avant le code. Cela produit de meilleures conceptions et des suites de tests complètes. À grande échelle, le TDD est ce qui rend l'intégration continue viable.
• Intégration continue (CI) : Intégrez le code plusieurs fois par jour. Construisez et testez automatiquement. Dans SAFe, la CI s'étend au-delà des équipes individuelles — le système doit s'intégrer à travers toutes les équipes de l'ART.
• Programmation en binôme / Revue de code : Deux paires d'yeux sur chaque changement. Les binômes tournent pour diffuser les connaissances. Les revues de code détectent les problèmes et partagent le contexte entre les membres de l'équipe.
• Propriété collective : N'importe quel développeur peut modifier n'importe quelle partie de la base de code. Pas de silos de connaissances. Cela nécessite que la CI et les tests soient sûrs.
• Refactorisation : Améliorez continuellement la structure du code sans changer le comportement. La dette technique s'accumule plus rapidement à grande échelle parce que plus de personnes modifient plus de code.

Pratiques architecturales :

• Architecture intentionnelle : Ne laissez pas l'architecture émerger uniquement des décisions d'équipe. Les architectes système guident les préoccupations transversales, s'assurent que les équipes construisent sur des plateformes partagées et maintiennent la piste architecturale pour les fonctionnalités futures.
• Piste architecturale : Investissez à l'avance dans l'infrastructure, les frameworks et les facilitateurs techniques dont les fonctionnalités futures auront besoin. Sans piste, chaque fonctionnalité part de zéro.

Pourquoi la qualité à grande échelle compte davantage :

Avec une équipe, une mauvaise qualité signifie une livraison lente. Avec dix équipes, une mauvaise qualité signifie des échecs d'intégration en cascade, des accusations mutuelles et des défauts au niveau du système que personne ne possède. Le coût des problèmes de qualité croît de manière super-linéaire avec le nombre d'équipes.