Planning Interval : PI (SAFe)
Auteur : © 2010-2023 Scaled Agile, Inc.
Source : Planning Interval (PI)
Date : 07/02/2023 (dernière mise à jour)
Traducteur : Fabrice Aimetti
Date : 21/08/2023
Traduction :
Sans engagement, il n'y a que des promesses et des espoirs, mais pas de plans.
—Peter F. Drucker
Un Planning Interval (PI) est une boîte de temps cadencée dans laquelle les Agile Release Trains (ART) apportent une valeur continue aux clients en accord avec les Objectifs du PI.
Les PI durent généralement de 8 à 12 semaines. Le modèle le plus courant pour un PI est de 4 itérations de développement, suivies d'une itération d'Innovation et de Planification (IP). Le PI est pour un ART ce qu'une itération est pour les Équipes Agiles. Il s'agit d'une boîte de temps fixe pour planifier, construire, valider, fournir de la valeur et obtenir un retour d'information rapide.
Au cours du PI, les Équipes Agiles utilisent la cadence et la synchronisation pour combiner le travail de plusieurs équipes en un ou plusieurs incréments livrables. Les équipes individuelles peuvent également produire de la valeur de manière indépendante, en fonction du contexte. La cadence et la synchronisation du PI permettent à l'ART de :
- Planifier le prochain incrément de travail de l'ART
- Limiter le travail en cours (WIP)
- Résumer la valeur qui mérite d'être communiquée pour obtenir un feedback
- Assurer la cohérence des rétrospectives de l'ART
En raison de sa large portée, le PI fournit une boîte de temps appropriée pour réfléchir au Portefeuille et établir une feuille de route.
Description détaillée
SAFe divise le calendrier de développement en une série d'itérations au sein d'un PI. La vue d'ensemble illustre comment un PI débute par l'événement du PI Planning (fr), suivi de quatre itérations d'exécution et se termine par une itération IP (Figure 1).
Ce modèle est indicatif et arbitraire, et il n'existe pas de règle fixe concernant le nombre d'itérations dans une IP. Toutefois, l'expérience a montré qu'une durée de PI comprise entre 8 et 12 semaines donne les meilleurs résultats, avec une préférence pour les durées les plus courtes. Les organisations qui adoptent le Lean Portfolio Management (LPM) trouvent souvent avantageux de faire coïncider le calendrier des événements de la Revue du Portefeuille Stratégique et de la Budgétisation Participative afin d'améliorer l'alignement de la stratégie sur l'exécution. (Veuillez lire la partie sur les événements dans l'article sur les compétences LPM pour plus d'informations).
Développer en cadence
Les PI fournissent le rythme de développement pour que les trains et les assets qu'ils construisent puissent être développés de manière itérative et incrémentale. L'expression "développer en cadence" désigne un ensemble coordonné de pratiques qui soutiennent les équipes agiles en proposant une succession fiable d'événements et d'activités selon un calendrier régulier et prévisible. Cependant, la cadence de planification est souvent différente de la cadence de livraison. Cette approche aide les entreprises centrées sur le client à créer un flux de valeur continu pour leurs clients.
L'entreprise détermine le calendrier des versions en fonction des besoins du marché et des clients et de la motivation de l'organisation à fournir de la valeur. Certaines entreprises publient fréquemment des versions pendant le PI, tandis que d'autres peuvent être contraintes par la conformité, les dépendances des fournisseurs ou d'autres exigences de l'entreprise et du marché, ce qui conduit à des versions moins fréquentes. Découpler les événements et les activités de développement qui soutiennent la création de valeur de la manière et du moment où cette valeur est livrée favorise encore plus l'Agilité de l'entreprise/du métier.
Les événements de l'ART pilotent le développement
Lors de l'exécution d'un ART, une double séquence d'événements Plan-Do-Check-Adjust (PDCA) crée un système en boucle fermée qui maintient le train sur les rails, comme l'illustre la figure 2. La boucle extérieure représente le cycle PDCA de l'ART pour le PI, tandis que la boucle intérieure représente le cycle PDCA d'une Équipe Agile pour une itération. Dans cet exemple, l'équipe utilise Scrum pour la boucle intérieure. La ligne diagonale (PI Start) montre qu'une fois que l'ART a terminé le PI Planning, les équipes à bord du train commencent la boucle PDCA interne.
Les paragraphes suivants décrivent chaque événement ART. L'article sur SAFe Scrum offre des conseils pour les itérations présentées dans la figure 2, et SAFe Team Kanban décrit le cycle de la boucle interne lorsque l'on utilise cette méthode.
Planifier le PI
Chaque PI d'ART commence par un événement de PI Planning. Au cours de cet événement, les équipes estiment ce qui sera livré et mettent en évidence leurs dépendances avec d'autres équipes Agile et trains. L'un des principaux résultats du PI Planning est un ensemble d'Objectifs de PI détaillant ce que l'ART devrait avoir à démontrer à la fin du PI. De plus, les Équipes Agiles intègrent continuellement leur travail tout au long du PI et démontrent les fonctionnalités lors de l'Iteration Review et des System Demos.
Le PI Planning a un ordre du jour standard qui comprend une présentation du contexte et de la vision de l'entreprise, suivie par des réunions de planification d'équipe - où chaque équipe crée ses plans d'itération et ses objectifs pour le PI à venir. Facilitée par le Release Train Engineer (RTE), le PI Planning inclut tous les membres de l'ART et se déroule dans le cadre de l'itération Innovation et Planification (IP).
Mener des System Demos
L'événement de la system demo test et évalue la solution dans un environnement de type production (souvent recette) pour recueillir les retours des parties prenantes, y compris les Business Owners, les sponsors exécutifs, les autres Agile Teams, les responsables du développement, et les clients (ou leurs représentants). Ce retour des parties prenantes est crucial, car elles seules peuvent évaluer l'efficacité et la facilité d'utilisation de la solution en cours de développement et offrir les indications dont l'ART a besoin pour rester sur la bonne voie ou s'adapter. L'événement de la system demo a lieu à la fin de chaque itération, fournissant une vue intégrée et globale des nouvelles Features livrées par l'ART.
Inspect & Adapt
Chaque PI se termine par un événement Inspect & Adapt (I&A), un moment privilégié pour réfléchir, appliquer des techniques de résolution de problèmes et identifier les actions d'amélioration nécessaires pour augmenter la vélocité, la qualité et la fiabilité du PI suivant. Au cours de l'événement I&A, le Product Management ou d'autres membres de l'équipe présentent toutes les features finalisées au cours de la system demo finale du PI. La démonstration est suivie de mesures quantitatives et qualitatives et d'un atelier de rétrospective pour la résolution de problèmes. Le résultat de l'I&A est un ensemble de features ou de stories d'amélioration que le RTE ou les équipes peuvent ajouter au backlog pour le PI Planning à venir. De cette manière, chaque ART améliore chaque PI, y compris les corrections de trajectoire vers la solution.
Les itérations déterminent la cadence de l'ART
Toutes les équipes agiles contribuent aux itérations de l'ART. Cependant, les modalités de planification et d'exécution pendant l'itération peuvent différer selon que l'équipe travaille en Scrum ou en Kanban. Les équipes Kanban travaillent généralement dans un modèle de flux continu, contribuant à l'incrément de l'ART au cours de chaque itération.
Puisque les équipes Agiles travaillent dans le cadre d'un ART, leur coopération est essentielle pour atteindre les Objectifs de l'équipe et du PI de l'ART. Pour parvenir à cette collaboration, les équipes doivent s'aligner sur la même cadence et la même durée d'itération.
