Menu
Les méthodes agiles ont jusqu’à présent prouvé leurs bénéfices au sein des grandes entreprises : réduction du Time to Market, réactivité face au changement, amélioration de la collaboration… Si nombre d’entreprises ont pris le parti d’adopter une méthode de delivery agile, seule une minorité semble avoir adopté le framework de l’agilité à l’échelle, aussi appelé SAFe. Si vous êtes ici, alors c’est que vous cherchez à mieux comprendre les implications de ce framework. Suite à notre premier article d’introduction au sujet, nous souhaitons vous présenter dans cet article les principes du PI planning, un des rituels fondamentaux du framework SAFe.
Qu’est-ce qu’un PI Planning ?
Pour comprendre ce qu’est un PI planning, il faut avant tout comprendre ce qu’est un PI.
Un « Program Increment » (PI) est une période de temps destinée à « livrer de la valeur » en développant, testant et obtenant des retours pour améliorer le produit final.
Le PI planning est ainsi une cérémonie du framework SAFe permettant de planifier la prochaine période de temps (le « Program Increment ») en s’alignant sur les objectifs à atteindre et les travaux à réaliser. Cette cérémonie dure en moyenne deux jours, et s’intercale entre chaque PI qui dure en général 8 à 12 semaines.
Au même titre que les sprints dans la méthode agile scrum classique qui durent 1 à 4 semaines, les PI permettent de définir une cadence de delivery. Pour beaucoup d’entreprises, les PI sont organisés de manière à se caler sur les trimestres sur une année.
Qui participe à un PI planning ?
Les participants à chaque PI planning sont les membres de l’« Agile Release Train » (ART). Un train agile inclut toutes les personnes permettant de définir, développer, valider et livrer en continu.
Ainsi, par définition, le train agile doit inclure les membres suivants :
- Product Owner (PO), qui est responsable de la définition des fonctionnalités, des priorités et de la vision globale du produit
- Product Managers (PM) ou responsables de produit, qui peuvent contribuer en apportant des précisions sur les besoins des utilisateurs et les objectifs commerciaux
- Directeurs / Managers, qui partagent les directives stratégiques, résolvent les problèmes ou fournissent des ressources supplémentaires si nécessaire
- Équipe de développement, qui travaille sur le développement du produit, et informe sur les efforts nécessaires, les dépendances et les risques
- Scrum Master, qui veille à ce que la méthodologie agile soit respectée et joue un rôle de facilitateur
- Responsables de l’Architecture et de la Qualité, qui garantissent la cohérence des décisions prises avec la vision architecturale et technique
- Release Train Engineer (RTE), qui contribue au bon déroulement des rituels et process du framework SAFe. En tant que facilitateur, il contribue à la coordination entre les équipes, remonte les alertes aux managers ou stakeholders afin d’adresser les problèmes et risques pouvant freiner le train agile.
La participation de l’ensemble de ces membres permet de garantir l’agilité du train et sa capacité à livrer en continu.
Comment se déroule un PI planning ?
Les deux jours dédiés au PI planning se déroulent habituellement de la manière suivante.
Premier jour : alignement de la vision et définition d’une première proposition pour le PI
Le PI débute par une introduction du contexte business, de la vision produit et de la vision architecturale (technique). Ensuite, le RTE présente la démarche pour la suite du PI planning ainsi que les attentes en termes de livrables.
L’après-midi est ainsi dédiée la co-construction d’une proposition de plan. Les acteurs chargés du delivery estiment la charge, la capacité, les objectifs, les risques potentiels et les dépendances.
Le management revoit en fin de journée cette proposition et prépare ses retours.
Deuxième jour : ajustement et validation collective de la proposition
Le lendemain, le management partage ses retours, puis les équipes travaillent sur le réajustement de la proposition. Cette proposition révisée est ensuite présentée, réajustée une dernière fois si besoin puis validée.
Les équipes identifient et évaluent ensuite les risques et potentiels obstacles à la réalisation des objectifs. Cette étape permet d’anticiper les réactions et solutions à mettre en place en cas de réalisation de ces risques. Elle permet en outre de confirmer avec le management si ces risques sont acceptables ou non.
S’ensuit un vote de confiance. Dans un premier temps, chaque personne indique sur une échelle de 1 à 5 (5 pour une confiance élevée) si elle pense que le plan proposé pour son équipe est réalisable et acceptable. Si la moyenne est inférieure à 3, alors le plan doit être réajusté. Une fois la confiance obtenue pour chaque équipe, un second vote permet de valider la proposition pour l’ensemble des équipes.
Enfin, la journée se termine sur une rétrospective du PI planning : chacun partage ses retours afin d’améliorer la prochaine session.
Réussir son PI planning
Plusieurs conditions sont nécessaires au bon déroulement d’un PI planning :
- S’assurer de la participation de l’ensemble du train agile, et notamment du management : leur participation donne du poids au rituel et permet de fédérer les équipes
- Préparer des supports de présentation de la vision business, produit et architecturale : il est crucial que l’ensemble du train agile comprenne et soit en phase avec ces visions
- Mettre à disposition les outils et canaux de communication nécessaires : aujourd’hui, de nombreuses plateformes en ligne telles que Miro ou Klaxoon incluent des supports d’échanges adaptés pour les rituels agiles. Celles-ci incluent également des fonctionnalités utiles (ex : minuteur, sondages, etc.). Les plateformes de communication Slack et Teams sont également connues pour faciliter l’organisation en ligne, avec des systèmes de salles ou canaux dédiées.
Exemple d’un board pour le PI Planning (Klaxoon)
Enfin, il faut garder à l’esprit qu’un PI planning ne peut être parfait ! La rétrospective en fin de session permet de recueillir du feedback pour s’améliorer. Chaque PI planning doit se dérouler en adressant au maximum les retours obtenus à la rétrospective précédente.
Pour aller plus loin sur le framework SAFe, n’hésitez pas à vous référer à notre offre de conduite du changement.
