PI Planning: préparer le grand jour de votre premier ART

Un premier PI Planning mal préparé compromet tout l'ART. Trois dimensions à maîtriser avant de réunir 50 à 125 personnes dans une même salle pendant deux jours.

Pourquoi le premier PI Planning est un moment charnière

Le PI Planning est l’événement fondateur de tout Agile Release Train (ART, ensemble de 50 à 125 personnes qui planifient et livrent ensemble dans le cadre SAFe). Pendant deux jours, toutes les équipes se retrouvent pour aligner leur travail sur le prochain Program Increment (PI), une période de planification de 8 à 12 semaines composée de plusieurs itérations. Quand cet événement fonctionne, il produit un plan partagé, un réseau de dépendances visibles et un engagement collectif. Quand il échoue, il laisse derrière lui des équipes désorientées et un management sceptique sur la transformation agile.

Le paradoxe du premier PI Planning est que les organisations qui s’y préparent le plus méticuleusement sont souvent celles qui réussissent le mieux à le rendre fluide et naturel. Ce qui ressemble à un atelier collaboratif spontané repose en réalité sur un travail de fond considérable, réparti sur plusieurs niveaux de préparation que cet article détaille.

La dimension organisationnelle: des rôles en place, pas sur le papier

Avant de fixer la date du PI Planning, il faut s’assurer que les rôles clés sont pourvus et que les personnes qui les occupent sont formées. Le Release Train Engineer (RTE), facilitateur et servant-leader de l’ART, doit être opérationnel: c’est lui qui orchestre l’événement, gère le timing et résout les blocages en temps réel. Le Product Management doit être capable de présenter la vision et le backlog de programme de manière cohérente. Les Scrum Masters de chaque équipe doivent comprendre le format et savoir guider leurs équipes dans la formulation des PI Objectives (objectifs de résultat que chaque équipe s’engage à atteindre pour le PI).

L’erreur fréquente consiste à considérer ces formations comme un détail à régler “quand on aura le temps”. Or, un RTE qui découvre son rôle le jour J transforme le PI Planning en improvisation. La formation doit être finalisée au moins deux semaines avant l’événement, avec si possible une répétition du déroulé entre les facilitateurs.

Les Business Owners (responsables métier qui valident les objectifs du PI) sont un autre point critique. Leur présence physique pendant les deux jours n’est pas négociable: sans eux, les équipes ne peuvent ni valider leurs objectifs ni arbitrer les compromis. Obtenir cet engagement managérial en amont est souvent le plus grand défi organisationnel.

La qualité des entrants: le facteur le plus sous-estimé

Un PI Planning ne peut pas produire un bon plan à partir de Features (fonctionnalités de niveau programme) et d’Enablers (capacités techniques comme l’architecture ou l’infrastructure) immatures. Si le backlog de programme ressemble à une liste de souhaits vagues, les équipes passeront leurs deux jours à essayer de comprendre ce qu’on attend d’elles plutôt qu’à planifier.

La maturité des entrants signifie que chaque Feature candidate au PI dispose d’un énoncé clair, de critères d’acceptation identifiés et d’une estimation grossière de sa taille. Le Product Management doit avoir priorisé le backlog et être prêt à expliquer pourquoi telle Feature passe avant telle autre. Les Enablers architecturaux doivent être suffisamment définis pour que les équipes puissent les décomposer en stories pendant le planning.

En pratique, la préparation du contenu commence quatre à six semaines avant le PI Planning. Des sessions de raffinement de programme (refinement) permettent au Product Management et aux architectes de présenter les Features aux équipes, de recueillir leurs questions et d’affiner les descriptions. Ces sessions réduisent l’effet de surprise le jour J et permettent aux équipes d’arriver avec une compréhension préalable du périmètre.

Selon la documentation officielle SAFe, la préparation du contenu est explicitement identifiée comme un prérequis au PI Planning. Ce n’est pas un détail méthodologique: c’est la condition sine qua non d’un événement productif.

La logistique: ce que personne ne veut planifier

La dimension logistique est la plus prosaïque et pourtant celle qui génère le plus de frictions le jour J. Un PI Planning réunit physiquement 50 à 125 personnes pendant deux jours. La logistique de cet événement s’apparente davantage à l’organisation d’une conférence qu’à la réservation d’une salle de réunion.

Le plan de tables mérite une réflexion stratégique. Chaque équipe a besoin d’un espace de travail dédié avec un tableau ou un mur pour afficher ses plans. Les Business Owners doivent être positionnés de manière à circuler facilement entre les équipes qui les sollicitent. Les équipes qui interagissent fréquemment gagnent à être proches les unes des autres pour faciliter la négociation des dépendances.

Le tableau des dépendances (program board) est l’artefact central du PI Planning. Sur un tableau physique, chaque équipe y représente ses Features et les liens avec les autres équipes à l’aide de ficelles ou de fils de couleur. La taille de ce tableau dépend directement du nombre d’équipes et d’itérations: avec huit équipes et cinq itérations, le tableau peut atteindre plusieurs mètres de large. Sa hauteur doit rester accessible sans escabeau, ce qui impose parfois des compromis sur la disposition.

La boîte de matériel est un classique que les praticiens expérimentés standardisent: Post-its de plusieurs couleurs (avec un code couleur défini à l’avance et communiqué aux équipes), marqueurs à pointe fine et épaisse, ficelle ou fil de laine, ruban adhésif, feuilles de paperboard. Chaque équipe reçoit le même kit. Ce niveau de détail peut sembler trivial, mais un PI Planning où les équipes perdent vingt minutes à chercher des Post-its de la bonne couleur est un PI Planning qui prend du retard dès la première heure.

Les consignes PI Planning: le document que personne ne lit mais que tout le monde cherche

Un document de consignes distribué en amont (et affiché dans la salle) clarifie les règles opérationnelles: comment formuler un PI Objective, comment identifier et déclarer une dépendance, quel est le rôle de chacun pendant les différentes sessions. Ce document évite que le RTE passe la moitié de son temps à répondre aux mêmes questions.

Pour un premier PI Planning, ce document est d’autant plus critique que les participants n’ont aucune expérience de l’exercice. Y inclure un exemple concret de PI Objective bien formulé et un contre-exemple aide les équipes à calibrer le niveau d’abstraction attendu.

Documenter pour amplifier

Un dernier aspect souvent négligé: la documentation de l’événement. Photos du program board, vidéo de la présentation de la vision, témoignages des participants. Ces éléments servent la communication interne sur la transformation agile bien au-delà du périmètre de l’ART. Un PI Planning réussi est un argument puissant auprès du management pour soutenir la suite du déploiement SAFe.