🕒 10 minutes de lecture.

PI Planning, Kesako?

Dans tous les frameworks d’agilité dites à l’échelle, il y a toujours un temps consacré pour la synchronisation des équipes sur le travail à faire, pour le ou les prochaines itérations.

Dans LeSS (Large Scale Scrum) c’est le sprint planning 1 qui a cette fonction. Chez Nexus, ils ont ce qu’ils appellent le Sprint Nexus. Et dans SAFe, on parle de PI Planning. Voici comment le décrit le site officiel de SAFe :

« Le PI planning est un événement face à face basé sur une cadence qui sert à rythmer l’agile release train (ART), alignant toutes les équipes de l’ART sur une mission et une vision partagées. »

Vous pouvez trouver l’article complet sur le PI Planning sur le site de SAFe (ici). Le PI Planning se déroule en deux jours. On réunit toutes les équipes qui travaillent ensemble sur le même produit (train).
Le but est de leur donner la vision des 3 prochains mois sur les différents sujets regroupant les besoins du client.
Le product manager présent dans cette projection le besoin client. Les équipes travailleront sur le découpage des besoins pour établir ce qu’ils sont capables de réaliser pour le prochain incrément. Ils auront la possibilité d’éclaircir leurs doutes et de poser leurs questions grâce. La réussite du PI Planning repose en partie sur la présence et la proximité du client et du management.

Notre contexte :

Dans notre cas, nous avons choisi ce format car cela nous permettait de donner une vision à un grand nombre d’équipes (10 équipes) qui travaillent sur le même produit. Le but recherché était de créer de la transparence sur le travail de chaque équipe.
Cette transparence nous permettrait de mieux mettre en lumière les dépendances et les frictions entre les équipes. Mais aussi de rappeler à l’ensemble des équipes les objectifs définis par le top management, et donner plus de sens au travail réalisé.

L’idée de départ était d’aligner les équipes à l’aide de cet outil et de l’adapter à notre contexte. Cette idée nous vient d’Hedi Kallel, sans qui tout cela n’aurait été possible.

Avant d’aller plus loin, je tiens à préciser que SAFe n’est qu’un framework. Suivre ses principes au pied de la lettre sans se poser de questions sur la pertinence n’est jamais une bonne chose. Dans notre cas, nous avons emprunté les outils proposés par SAFe en nous posant la question à chaque étape du « POURQUOI ».

Les préparations avant le jour J:

La préparation de cette journée n’est pas à négliger.

Canevas pour les features:

La première étape clé a été de préparer les différentes features. Chaque PM avait la responsabilité de remplir le canevas (ci-dessous) présentant une feature.

Pour s’assurer de la bonne granularité des features et de leur bonne rédaction nous avons tout au long du program increment N-1 accompagné les PMs dans leur rôle. Nous avons réalisé le même travail d’accompagnement avec le management concernant la vision.
Ce travail est essentiel pour notre l’organisation de notre journée. Nous y avons donc consacré le temps nécessaire.

Préparation de la salle :

Pour le lieu nous avions fait le choix de sortir de notre cadre, et avons privilégié un lieu suffisamment grand et apportant un certain confort à l’ensemble des participants.

Boards des équipes :

Nous avons ensuite préparé les boards de chaque équipe.

Canevas pour les sprints
Canevas pour les objectifs des équipes avec les risques

Le premier board représentera les 6 sprints de notre programme incrément . Chaque équipe y fait apparaître les tâches qu’elle envisage pour cette durée. Le deuxième canevas représentera les objectifs et les risques. Chaque équipe a donné une note de confiance sur les sujets à réaliser.

Modèle de ROAM

Nous avons choisi l’utilisation du modèle de gestion de risques ROAM (ref) :

Modèle de risque ROAM

Le modèle ROAM nous permet de classer les risques en quatre catégories:

Resolved (résolu) : le risque est clairement identifié et une ou plusieurs actions identifiées peuvent déjà être mises en place pour le résoudre et l’éliminer.
Owned (pris en charge) : le risque est clairement identifié et un membre de l’équipe a accepté la responsabilité de traiter ce risque .
Accepted (accepté) : le risque a été clairement identifié mais l’équipe accepte ce risque et décide de ne pas le traiter.
Mitigated (atténué) : Une action a été trouvée pour que le risque soit atténué sans pour autant être totalement éliminé. Mais le risque de survenance et/ou ses conséquences ont été réduits.

Ces deux canevas sont utilisés pour la management review, et sont repris par les équipes à la fin de la journée.

Agenda:

Pour s’assurer que tout se déroule comme prévu, nous avions installé le détails de notre agenda à plusieurs endroit clés

Agenda de la journée

Pour mieux comprendre notre agenda voici quelques explications des cérémonies :

Scrum of scrum (SoS) : Une cérémonie pour synchroniser tous les facilitateurs (Scrum masters) des équipes et éventuellement discuter des difficultés rencontrées par les équipes et leur respect ou non du timing.

Notre check list au moment de SoS

PO of POs (PoP) : C’est un moment privilégié pour réunir tous les POs pour remplir le program board et discuter des dépendances. L’idée étant de faciliter des échanges entre les POs. Cet échange ne se faisant pas de façon naturelle pendant les workshops.

Restitution : chaque équipe présente son planning pour les 3 prochains mois avec les risques détectés, leurs objectifs et leur note de confiance. C’est aussi à ce moment-là que l’équipe peut répondre aux questions des autres équipes, PM et managers.

Management Review : les managers et PMs se réunissent pour discuter des risques et les objectifs fixés par chaque équipe. Ils ajustent le planning si nécessaire par rapport à la vision et aux priorités des managers et clients.

Le déroulé du PI Planning:

Nous avons décidé de faire une partie des préparatifs le matin même du jour J. Nous avons d’abord installé le program board, voici le notre :

Program board

Une fois le program board installé et les emplacement des équipes marquées. Nous avons mis à la disposition de chaque équipe des canevas, des post-its et des marqueurs.

La journée a commencé avec un discours du management sur la vision à long terme. Puis c’était au tour des PMs de présenter les fonctionnalités qu’ils avaient prévues pour le prochain program increment.
Après cela, les équipes se sont lancées dans le raffinement des sujets présentés, lors de deux workshops d’une durée de 1h30 chacun.

A la fin de la journée, une personne de chaque équipe (de préférence pas le PO) a présenté le travail et le planning réalisé par son équipe, incluant les dépendances avec les autres équipes et en mettant l’accent sur les risques identifiés.

Manager review :

Une fois la présentation terminée, les managers se sont réunis pour discuter de la programmation des différents équipes. Ils peuvent éventuellement changer les priorités de certaines équipes, ajuster les plans et trouver des moyens pour réduire les risques. Ils sont accompagnés par un facilitateur (Dans SAFe c’est le rôle du RTE) qui va les aider dans les discussions et les prises de décision. Ensuite, ils travaillent sur leur discours du lendemain matin. Dans ce discours du deuxième jour, ils expriment les changements qu’ils ont envisagés la veille. Puis les équipes se lancent à nouveau pour adapter leurs plans et leur vision par rapport à ce qui a été présenté. Nous avons envisagé un seul workshop pour cette deuxième journée. A la fin du workshop, les équipes font de nouveau une présentation sur les ajustements réalisés en tenant compte des modifications demandées par les managers.

La suite:

Une fois le PI planning terminé, nous avons affiché le program board dans un endroit visible par tous. Ce board est prévu pour que les POs puissent mettre à jour leur avancement et les changements au cours de program increment en cours.

Nous avons aussi opté pour un suivi hebdomadaire toutes les deux semaines (notre cadence de sprints). A chaque début de sprint, nous faisons un point d’avancement pour chaque équipe. Chaque équipe présente son suivi par rapport à ses objectifs. Chacun parle aussi de ses réussites, des difficultés rencontrées, comment il a réussi à les contourner et les points pour lesquels il a besoin d’aide.

Grâce à cet outil et sans utiliser toute la complexité de SAFe, nous avons réussi à partager la vision au sein de nos équipes.
A vous d’adapter les outils à votre contexte, arrêtez le « by the book« .