SAFe : et si on faisait un PI Planning à distance ?

Oui, vous avez bien lu, un PI planning à distance pour tout le monde, c’est possible. Conditions sanitaires oblige, il a fallu cette année trouver des solutions pour continuer à faire vivre l’agilité au sein des sociétés et des équipes. Je vais donc vous parler de mon expérience à la Macif qui a organisé un PI planning à distance suite à la création récente d’un nouveau train. Et, ça c’est plutôt très bien passé !

‍

‍

PI planning, késako ?

Pour rappel, le PI planning est un événement de l’agile à l’échelle faisant partie de la méthodologie SAFe. Il permet de planifier la réalisation du prochain Program Increment (PI) d’un train (Agile Release Train).

C’est un événement qui se déroule habituellement sur 2 jours, et regroupe l’ensemble des équipes d’un train (ART).

‍

Le contexte

La Macif est en cours de changement organisationnel, notamment avec la généralisation de la méthodologie SAFe au sein de ses équipes.

Me concernant, je suis PO (Product Owner) au sein d’un train qui a été créé cette année (2020). Nous avons donc dû préparer et réaliser notre premier PI planning à distance.

L’objectif de cet article est de vous partager mon expérience du PI planning à distance, mon vécu. Je l’écrirais donc suivant mon interprétation de PO et tenterais d’être la plus “pratique” possible, ce qui peut parfois différer de la théorie.

‍

La préparation

L’anticipation de ce type d’événement est crucial, et la Macif était très bien organisée. Dès fin août, chaque PO de chaque équipe devait fournir l’ensemble des features détaillées envisagées pour le PI planning. Il était prévu quant à lui… début novembre.

Du côté de l’équipe dans laquelle je suis, nous avons tant pris en compte les idées/envies de la team sur l’évolution du produit que les demandes des collaborateurs. Cela a permis de créer une réelle adhésion de la part de l’équipe de développement.

Une fois les features discutées, il a le PO Sync. C’est un événement hebdomadaire de la méthodologie SAFe permettant à l’ensemble des Product Owners d’un train de se synchroniser sur ce qui est en cours. Cela aide également à mettre en avant les complémentarités entre les équipes, et notamment la notion d’un produit “commun” au sein du train et non le travail de teams individuelles.

Suite à cela, une seconde vague de détails des features eut lieu, avec des réunions sur le WSJF (Weighted Shortest Job First) des features. C’est une méthode de calcul permettant de faciliter la priorisation des fonctionnalités.

Enfin, pour anticiper au mieux le déroulé du PI planning, nous avons découpé chaque feature que nous pensions engager en “macro US” pour perdre le moins de temps possible le jour J. Elles étaient reportées au sein d’un board Klaxoon regroupant l’ensemble des features par équipe du train.

Le planning et le déroulé

Jour 1

• Business context (a.m)

C’est la présentation qui permet de comprendre les enjeux business du train de manière générale.

• Architecture vision (a.m)

Elle donne quant à elle une vision de l’architecture actuelle et comment nous allons la faire progresser.

• Product vision (a.m)

C’est durant ce point que les PO présentent les principales features qu’ils pensent pouvoir prendre en charge pour le prochain PI.

• Team breakouts (p.m)

Cette réunion est dédiée à l’équipe afin d’expliciter, de préciser les features un maximum pour qu’elles soient claires pour l’ensemble de la Scrum Team. De plus, elle fait émerger des dépendances, permettant de contacter les autres équipes du train en conséquence. Cela aide à l’alignement des équipes sur les dates de mise à disposition des features concernées.

• Management review (p.m)

C’est comme un bilan rapide sur l’avancée de l’équipe. Il permet également de signaler des points bloquants.

‍

Jour 2

• Team breakouts (a.m)

L’objectif est que chaque équipe finalise sa planification pour les 4 prochains sprints (tout en prenant en compte les congés, disponibilités des ressources, dépendances internes et externes etc…). Ce qui fut le cas.

• Revue du planning final (p.m)

Cela permet d’avoir un vue d’ensemble des équipes, la vision globale de ce qui est engagé sur le train ainsi que les différentes dépendances entre les équipes.

• Le vote de confiance (équipe et train) (p.m)

C’est le moment où, d’abord par équipe, chaque membre indique sa confiance à réaliser ce qui a été engagé sur une échelle de 1 à 5. Puis, tout le monde vote, toujours de 1 à 5, la confiance qu’il a envers la réalisation de l’ensemble de ce qui a été engagé au sein du train.

• La rétrospective (p.m)

Elle permet à chacun de dire rapidement ce qu’il a aimé, moins aimé et les pistes d’améliorations pour le prochain PI.

‍

Les outils

Klaxoon

Nous l’avons utilisé pour la mise en avant des features, tâches et dépendances associées. Personnellement, je n’ai pas trouvé que cela permettait d’avoir une vue d’ensemble claire. Le tableau se retrouve vite surchargé avec des liens un peu dans tous les sens. C’est une piste d’amélioration pour le prochain PI.

Meet

Il y avait différents liens permettant de participer aux points génériques, par équipe ou encore de se connecter avec une autre équipe pour parler des dépendances potentielles. C’était très bien organisé.

Drive

Beaucoup de supports PPT étaient à disposition sur le déroulé, les liens des meets et Klaxoon, les visions… permettant de ne pas se perdre malgré le distanciel.

‍

Mon ressenti

L'anticipation

Malgré le fait qu’elle est toujours bonne à prendre, et que nous avions la pression du “premier” PI, je trouve que nous avons trop anticipé.

Les priorités, les volontés bougent et nous nous sommes retrouvés trop rapidement avec un support obsolète. De plus, le fait de se plonger trop en amont ne permet pas d’avoir le recul nécessaire sur la fin de la préparation.

En revanche, nous avons mis en place des sessions d’entraînements, notamment pour la réunion product vision pour que la présentation des différentes équipes soit fluide et c’était très efficace le jour J.

Le timing

Un PI de 2 jours est suffisant. Non seulement pour les échanges et la construction produit mais également pour ne pas épuiser les équipes car ces 2 jours sont déjà très intenses.

De plus, aucun problème de connexion ne fut à déclarer ce qui a permis de maintenir un bon rythme.

Les rôles

J’ai remarqué qu’une implication sans faille du PM (Product Manager) est nécessaire. Cela permet de pouvoir évoluer rapidement sur la précision des features. Il répond aux différents besoins de “trancher” quand on se rend compte que l’équipe ne va finalement pas pouvoir embarquer toutes les features que nous pensions.

Le rôle du SM (Scrum Master) est également très important pour rediriger les discussions dans le bon sens quand l’équipe commence à s’éparpiller. Il permet aussi de recadrer au niveau du timing quand nécessaire.

D’autre part, il peut également s’absenter quand il s’aperçoit d’un point bloquant pour tenter de le résoudre en parallèle. Cela permet à l’équipe de continuer d’avancer sur la planification en attendant son retour.

Pour conclure, malgré quelques appréhensions, je trouve qu’un PI planning à distance peut très bien se dérouler. Le plus important est que chaque étape soit bien anticipée et cadrée. Les supports de repères ont également été d’une grande aide pour connaître le déroulé des 2 jours ainsi que les liens sur lesquels se connecter.

Si vous souhaitez en savoir plus sur SAFe, vous pouvez regarder l’article dédié à cette méthodologie ici.

‍