Regardons de plus près de la cérémonie du PI Planning et, se faisant, éclairons peut-être pourquoi il est considéré avec un tel respect.
Unravelling PI Planning
https://www.digite.com/blog/unravelling-pi-planning/ par Anshuman Singh
Il y a une citation présentant le contenu du PI Planning sur Scaled Agile Framework : “Il n’y a aucune magie dans SAFE® sauf peut-être pour le PI Planning”.
Regardons de plus près de la cérémonie du PI Planning et, se faisant, éclairons peut-être pourquoi il est considéré avec un tel respect.
La plupart des organisations qui mettent en œuvre SAFE® ne le mettent pas entièrement en œuvre. Mais s’il y a un dénominateur commun entre toutes ces mises en œuvre de SAFE®, c’est le PI Planning. Ainsi qu’est-ce que le PI Planning ? Et que signifie ‘PI’ dans PI Planning ?
Eh bien, PI signifie Programme Increment, un Incrément de Programme. Un Incrément de Programme entre dans une fenêtre de temps (timebox) de 8 à 12 semaines (le défaut étant 10 semaines comme recommandé par Scaled Agile Inc.). Cette timebox de 10 semaines encapsule 5 Sprints Agiles ou Itérations de 2 semaines. La 10ème semaine du PI se termine avec la Démonstration de PI où le travail construit pendant le PI est présenté aux parties prenantes. (Il est utile de noter ici, qu’un PI est un incrément d’un Programme entier. Un Programme est là où les équipes et autres ressources sont investies d’une mission de développement importante. Un Programme consiste donc en de multiples Incréments de Programme.
Comme le PI a 5 itérations avec des équipes multiples travaillant en cadence pour réaliser une vision commune, il est important pour ces équipes de se rassembler et planifier le cours des actions pour la durée entière du PI. La réunion aide aussi les équipes à comprendre quelles sont les dépendances entre elles et les risques à adresser. Cette réunion est appelée PI Planning. C’est une réunion complexe et détaillée d’une durée de 2 jours pendant la semaine 10 du PI.
Alors, qu’est-ce qui entre dans un PI Planning ?
La Vision du Programme et le Programme Backlog sont deux entrées principales et essentielles pour conduire une réunion de PI Planning. La Vision fournit le contexte à l’équipe entière sur pourquoi et comment le travail fait dans le PI aidera dans la construction de la Solution complète. Le Programme Backlog comprend des 10 premières fonctionnalités classées par priorité et accompagnées de descriptions courtes des bénéfices business que la fonctionnalité génèrerait.
Le Programme Backlog appartient au Product Manager qui est aussi responsable de s’assurer qu’on l’ordonne selon la priorité business en fonction de la réalité du marché et d’autres facteurs exogène. Les 10 premières fonctionnalités sont aussi accompagnées de Starter Stories (beaucoup d’histoires peuvent manquer, beaucoup ont besoin d’être décomposées ou sont des duplications dans les backlogs d’autres équipes). Ces Starter Stories permettent aux équipes de démarrer rapidement leur planification pour le PI.
PI Planning
La réunion de PI Planning s’applique à l’équipe entière allouée au Agile Release Train et on s’attend à ce que chacun y participe. Si certains des membres d’équipe sont à d’autres emplacements géographiques, ils doivent participer à distance. La réunion de PI Planning est divisée en différentes sessions sur un créneau de 2 jours.
La réunion de PI Planning est organisé par le Release Train Engineer (RTE, aussi appelé le Scrum Master du Agile Release Train). Le RTE présente la Vision et les 10 premières fonctionnalités à la session inaugurale du PI Planning. Après cela, toutes les équipes entrent dans leurs sessions respectives où elles évaluent leur propre vélocité pour au moins les 2 premières itérations sur les 5. Les équipes mûrissent les fonctionnalités et les Starter Stories et évaluent leur taille. À la fin du premier jour, les équipes se réunissent avec les Business Owners, des architectes système et d’autres parties prenantes pour obtenir des clarifications et mettre en avant leur compréhension.
Le deuxième jour, les équipes entrent de nouveau dans des sessions spécifiques et détaillent encore davantage leurs backlogs respectifs. Chaque équipe formule une liste d’objectifs appelés des Objectifs d’Équipe et les Business Owners donnent chacun des objectifs un score de Valeur Business. Le score de Valeur Business est un chiffre entre 1 à 10 (10 pour la Valeur la plus élevée côté business, 1 pour la plus basse). Plusieurs objectifs peuvent avoir le même score de Valeur Business.
Après cela, chaque équipe présente son plan au groupe assemblé en entier. Le plan met en évidence les risques identifiés, les dépendances prévues et les objectifs agréés avec leur Valeur Business. Une fois que chacune des équipes a achevé sa présentation, une liste agrégée d’objectifs d’équipe est présentée et une liste agrégée de risques de Programme est aussi compilée.
L’équipe discute chacun des risques et les adresse avec l’approche ROAM (Resolved, Owned, Accepted, Mitigated). Finalement, il y a un vote de confiance où chaque équipe donne son score (entre 1 et 5) de confiance d’atteindre les divers objectifs. Si une équipe donne un score de moins de 3, ses membres doivent exprimer leurs réserves qui sont discutées avec le groupe entier. Le problème pourrait ajouter à la liste de risques ou exiger un peu de re-planification ou être simplement informatif. Si nécessaire les équipes retravaillent leurs plans jusqu’à ce qu’un fort niveau de confiance puisse être atteint.
Productions du PI Planning
Les productions de la réunion PI Planning sont les suivantes
- Une liste d’Objectifs d’Équipe avec la Valeur Business, où les objectifs sont les résumés business de ce que chaque équipe a l’intention de livrer dans le prochain PI.
- Il y a aussi des Objectifs additionnels que chaque équipe peut avoir choisi au cas où elle serait capable d’achever son travail et qu’une certaine bande passante resterait.
Les objectifs d’équipe sont agrégés et raffinés pour former les Objectifs complet du PI avec sa Valeur Business. C’est réalisé par le RTE après que la réunion de PI Planning soit finie et pas pendant la réunion.
- Nous gagnons une compréhension de la vitesse de chaque équipe au minimum pour l’Itération 1 et 2, avec des histoires d’utilisateur de taille identifiée pour ces itérations sur lesquelles les équipes travailleront.
- Une production importante du PI Planning est le tableau de Dépendance de Programme qui dépeint les Fonctionnalités / Histoires, les Dépendances et les jalons marquants. Les architectes et des membres d’équipe UX jouent un rôle clef pour aider à identifier ces dépendances.
- Le PI Planning donne aussi une liste de Risques identifiés et comment ils ont été adressés à travers le mécanisme ROAM.
Rôles Principaux dans le PI Planning
Les rôles clefs et leur fonction pendant le PI Planning sont mis en évidence ci-dessous.
- Business Owner – fournit la Valeur Business et l’approbation des Objectifs de l’Équipe PI
- Product Manager – fournit les 10 premières fonctionnalités priorisées du backlog
- RTE – présente le processus de planification et les résultats attendus
- Product Manager et ScrumMasters – supportent les sessions d’Équipe et la décomposition des histoires
- Équipes Agiles – mûrissent les fonctionnalités des Histoires d’Utilisateur pendant les sessions d’Équipe, identifient les risques et donnent le crucial vote de confiance
- Architecte Système / – aide à établir des dépendances inter-équipe et les risques
Épilogue
Le PI Planning sert la fonction importante de rassembler l’équipe entière et d’aider ses membres à gagner une perspective unifiée sur le travail qu’ils vont accomplir.
Les équipes entendent directement des Business Owners, les leaders organisationnels, comment le PI en cours de planification aidera l’organisation à s’approcher des ses objectifs finaux et quel est l’avenir attendu de la solution en construction.
Sur une note plus banale, les équipes sont capables de mettre en évidence les interdépendances et comment elles prévoient de les adresser avec succès. Ayant formulé les objectifs du PI, les équipes développent un sentiment d’appropriation pour les livrer.
La réunion de PI Planning est organisée dans la 5ème itération du PI qui est l’Itération de l’Innovation et de la Planification et n’a ainsi pas à être planifiée sur un créneau de temps complémentaire. Elle répond au besoin de perspective que les équipes désirent souvent mais obtiennent rarement. Elle distribue la planification et le contrôle du travail aux équipes qui sont en fin de compte responsables de sa livraison.
Et c’est une bonne chose!
Anshuman Singh, Product Manager, SwiftEASe
Regardez comment SwiftEASe aide dans les réunions de PI Plannning et suit les objectifs, risques et le statut d’achèvement de fonctionnalités du PI.
SAFe® et Scaled Agile Framework sont des marques déposées de Scaled Agile, Inc.
