Haut de page

Mener un PI Planning durant la crise du Covid-19


Publié par
Dean MacNeil

13 mai 2020

Le Program Increment (PI) Planning, c’est un peu l’ingrédient mystère de la méthode SAFe (Scaled Agile Framework). Evénement de grande ampleur, réunissant jusqu’à 100 personnes, il permet la synchronisation et la coordination, en face à face, de l’Agile Release Train (ART) composé d’équipes travaillant habituellement à distance. L’objectif de cette cérémonie est de définir collectivement l’objectif du prochain Program Increment (PI), d’aligner les équipes sur la stratégie, d’éliminer les dépendances et de formuler un Program Board (Tableau de Programme) des fonctionnalités à développer au cours du prochain trimestre : généralement en 5 Sprints (Itérations) suivi d’un Innovation & Planning Sprint. Il s’agit en fait d’un savant mélange de personnes, de pratiques et d’outils, avec un équilibre presque parfait entre organisations et chaos. Son résultat ? De la magie pure : alignement, synergie et confiance.

Agile at scale (L’agilité à l’échelle) préconise que cet événement soit toujours organisé dans un même lieu mais la réalité du terrain est autre : le Program Increment est souvent co-organisé dans 2 endroits différents. Mais comment le gérer lorsque chaque individu est confiné chez lui ? Comment conserver les synergies d’une Big Room (salle de conférence) et des réunions d’équipes lorsque personne n’est ensemble ? C’est le défi que nous devons relever actuellement avec la crise du Coronavirus.

SAFe® (Scaled Agile Framework®) soutient que les outils sont l’épine dorsale du PI Planning et que la dispersion géographique des membres d’une équipe complexifie la coordination d’un tel événement (cf PI Planning à distance avec SAFe). Un PI Planning dispersé implique donc d’avoir recours à davantage d’outils mais également d’être plus rigoureux sur la pré-planification et la coordination. C’est là qu’interviennent le Release Train Engineer (RTE) et les Scrum Masters : pour orchestrer tout ça.

En cette période de distanciation sociale, il est nécessaire de rappeler les valeurs et les principes qui nous unissent. En effet, toute personne qui pratique l’Agilité le sait : un bon Agiliste accorde plus de valeur aux individus et aux interactions plutôt qu’aux processus et aux outils. De ce fait, en nous appuyant sur les outils, nous ne devons pas oublier qu’ils sont là pour nous servir, relier les individus et faciliter les interactions et non l’inverse. Nul besoin de nouveaux outils, nous pouvons exploiter les outils existants qui sont mis à notre disposition dans l’entreprise. Tout est question d’humain et de planification, même s’il existe des outils qui peuvent particulièrement nous aider.

Dans cet article, nous partons du principe que votre entreprise suit déjà le programme SAFe ou qu’elle organise des événements de planification trimestrielle d’après la méthodologie SAFe en utilisant un outil EAP (Enterprise Agile Planning). D’après Gartner en mai 2019, Jira Align est le principal outil de support de SAFe. Jira Align s’appuie sur Jira Software, l’outil le plus performant pour collaborer de manière agile au niveau d’une équipe, en diffusant et collectant l’information projet à tous les niveaux de votre entreprise.

Enfin, cet article part également du principe que vous utilisez un outil de visio tel que Zoom ou WebEx, un outil de messagerie instantanée tel que Slack ou Microsoft Teams ainsi qu’un outil de création de contenu collaboratif tel que Confluence. Ils sont essentiels pour interagir à distance.

Sept conseils pratiques

Le RTE (Release Train Engineer), en tant que principal facilitateur du PI Planning, les Scrum Masters ainsi que toutes les personnes fournissant un soutien logistique vous prodigueront les conseils suivants :

  1. Travaillez avec votre équipe informatique interne pour vous assurer qu’il existe un espace collaboratif pour chaque équipe agile et pour l’ensemble de l’ART.
  2. Comme dans la vie réelle, laissez vos outils accessibles à tous pour donner l’opportunité à vos équipes d’accéder à tous les espaces collaboratifs et de consulter les tableaux de bord.
  3. Veillez à ce qu’il y ait un groupe de conversation ou un canal de discussion pour chaque équipe agile, ainsi qu’un groupe pour les Scrum Masters, les Product Owners, les Facilitateurs, etc. Encore une fois, laissez les canaux ouverts pour que chacun puisse poser des questions. Enfin pour faciliter l’accès, regroupez dans une page Confluence l’ensemble des liens vers ces canaux de discussion.
  4. Assurez-vous que tout le monde connaisse les outils et comment les utiliser. Les Scrum Masters peuvent être utiles dans ce cas-là pour les former.
  5. Vérifiez que les licences et bandes passantes de vos outils sont suffisantes pour accueillir un nombre important de participants. D’ailleurs, testez les outils en amont en fonction du nombre de personnes qui assisteront au PI Planning. Par exemple, vous pouvez inviter vos collègues à jouer à un jeu de 15 minutes via votre outil de visio afin de faire un test de charge et de se familiariser avec celui-ci. Un récent webinar SAFe sur le PI Planning à distance recommandait les puzzles communautaires tels que jigsawpuzzle.io.
  6. Disposez d’une assistance technique dédiée. Les participants qui perdent l’audio, par exemple, doivent être en mesure de leur envoyer un message. En plus d’un canal de discussion ouvert, publiez une FAQ guidée.
  7. Enfin, comme dirait les Scouts, « Soyez prêts » et prévoyez un plan B pour chaque outil en cas de bug technique. Par exemple, exportez chaque jour les données de votre outil EAP ou ALM (Agile Lifecycle Management) vers des feuilles de calcul et sauvegardez-les dans le cas peu probable d’une panne système.

Le Pre-planning

Le pre-planning (la planification préalable) est la clé du succès dans le cadre d’un événement dispersé géographiquement. Le RTE et les Scrum Masters doivent anticiper les attentes, apporter les modifications appropriées au format standard du PI Planning et réaliser un test pour garantir une exécution sans soucis.

Il faut tout d’abord se renseigner sur la localisation des participants au train. Rassemblez et publiez dans Confluence la listes des participants et des équipes de l’ART regroupant pour chacun leurs adresses, leurs coordonnées, leurs numéros de mobile ainsi que leurs coordonnées de sauvegarde ou de proxy. Le RTE devra, avant l’événement, leur envoyer l’ensemble de ces informations.

Conseil pratique : la communauté Scaled Agile met à disposition, sur son site, une liste d’équipes modifiable dans sa boîte à outils du PI Planning.

A tous les Scrum Masters : gardez une trace écrite de la localisation des participants ainsi que de leur état d’esprit. En ces temps difficiles, il est important de se rappeler les 4 B : Be of service (soyez utile), Be flexible (soyez flexible), Be responsive (soyez réactif) et Be understanding (soyez compréhensif). Le télétravail est nouveau pour beaucoup d’entre eux. En effet, ils doivent relever de nouveaux défis : occuper le même espace de travail que leurs enfants, combattre la solitude et le temps trop important passé devant l’écran.
A tous les membres de l’équipe : veuillez également prendre soin de vos Scrum Masters.

Voici quelques questions auxquelles les Scrum Masters doivent réfléchir : comment fonctionne un breakout (séance d’équipe) de 3 ou 4 heures lorsqu’elle est dispersée géographiquement ? Comment les Scrum Masters peuvent s’assurer à distance que l’équipe est toujours concentrée ?

Lors des briefs du premier jour expliquant le contexte, les RTE doivent prévoir trois animateurs par présentation : un présentateur, un modérateur pour trier et répondre aux questions et un support technique dédié.

Les Working Agreements

Les Working Agreements (charte de travail) devront être modifiés pour tenir compte de divers facteurs. Il faudra peut-être prévoir un délai de réponse plus long en tenant compte de l’éloignement géographique. Vous pouvez proposer les actions suivantes : « Faire une pause après avoir parlé », « Lever la main » et « Passer le micro au prochain intervenant ». SAFe propose les exemples suivants :

  • « Parlez uniquement lorsque votre micro est activé »
  • « Un échange à la fois »
  • « Respectez-vous les uns les autres »

Mais d’autres points pourraient être ajoutés dans les Working Agreements :

  • « Changez votre statut de présence en fonction de vos actions ».
    Dans une salle de conférence, vous pouvez observer les actions des autres participants : sont-ils en train de discuter, de manger ou de faire une pause ? Il est donc utile de changer votre statut de présence afin que les participants puissent savoir s’ils peuvent vous contacter ou non.
  • « Gardez vos caméras allumées ».
    Non seulement cela permet de garder les gens concentrés, mais cela soutient le principe n°6 du Manifeste Agile : « La méthode la plus simple et la plus efficace pour transmettre de l’information à l’équipe de développement et à l’intérieur de celle-ci est le dialogue en face à face ».
  • « Surveillez à tour de rôle le canal de discussion de l’équipe ».
    Vous garantissez ainsi des réponses rapides aux questions des autres participants. D’ailleurs, il pourrait être utile de convenir d’un outil standard tel que WebEx pour les événements principaux, tandis que les équipes pourraient échanger à travers leurs outils préférés tels que Slack ou Hangouts pour leurs breakouts. Attention, cette dernière condition est valable si les canaux de discussions sont ouverts et transmis sur Confluence.

Le brief du planning par les RTE lors du premier jour est donc important pour présenter également les Working Agreeements et les méthodes de communication.

L’Agenda

L’agenda du PI Planning devra être adapté aux fuseaux horaires afin de tirer le meilleur parti du temps de collaboration. Évitez donc que les participants veillent toute la nuit en s’engageant à atteindre des objectifs alors qu’ils manquent de sommeil. En d’autres termes, pas de vote de confiance à 4 heures du matin !

Il est également recommandé de réduire les journées et d’allonger l’agenda de 3 ou 4 jours car il est difficile pour les participants de se concentrer lorsqu’ils regardent un écran pendant de nombreuses heures. Prévoyez des pauses d’au moins 5 à 10 minutes par heure et tenez compte des pauses repas dans les différents fuseaux horaires. Les Scrum Masters peuvent collaborer plus étroitement avec les personnes qui ne peuvent pas assister à certains événements de l’agenda.

Dans un scénario dispersé géographiquement, SAFe recommande d’ajouter dans l’ordre du jour des points de synchronisation d’équipe. Chaque équipe peut utiliser un formulaire de réservation ou un calendrier en ligne pour les planifier avec les participants et les équipes avec lesquels elle collabore. Un second point de synchronisation devrait également être planifié avec les Business Owners afin que ceux-ci évaluent la Valeur Business (BV – valeur commerciale) des objectifs du Program Increment (PI). Encore une fois, privilégiez une méthode en ligne pour planifier avec eux ce point recommandé de 10 minutes.

Le RTE doit également prévoir d’envoyer l’ordre du jour à l’avance. Enfin n’oubliez pas de partager des moments de détente avec les autres en planifiant un moment d’échange à distance à la fin de cette première journée.

SAFe propose un exemple de planification du PI répartie sur deux fuseaux horaires (Los Angels et Delhi) s’étendant sur trois jours :

 

 

Conseil pratique : la communauté Scaled Agile met à disposition, également sur son site, cet agenda modifiable dans sa boîte à outils du PI Planning.

Le brief sur le contexte

Lors de cette première journée, la première partie est consacrée à présenter le contexte commercial, la vision du produit, ses fonctionnalités prioritaires, la vision de l’architecture ainsi que les pratiques de développement du PI à venir. Le RTE doit envoyer en amont le brief pour que les participants puissent suivre sa présentation même si le son coupe. Mieux encore, enregistrez et envoyez une présentation du brief puis prévoyez un créneau plus court pour les questions. Les Scrum Masters peuvent prévoir du temps avec leurs équipes pour consulter de nouveau l’enregistrement et noter les questions à poser dans la Big Room virtuelle. Cette approche permet de rationaliser le calendrier et d’en réduire sa complexité.

Conseil pratique : la communauté Scaled Agile met à disposition, également sur son site, des modèles de présentation du brief modifiables dans sa boîte à outils du PI Planning. Le Product Manager pourrait vouloir inclure aussi une roadmap (feuille de route) exportée depuis Jira Align.

La répartition des équipes

Les équipes débutent par réaliser un premier breakout en estimant leur capacité pour chaque sprint sur la base de leur vélocité historique (visible dans Jira Align ou Jira Software) et de leur disponibilité, en tenant compte notamment des congés, des absences et des formations.

Dans Jira ou Jira Align, elles identifient et dimensionnent ensuite les tâches en attente dans le backlog pouvant être nécessaires pour développer les fonctionnalités prioritaires afin de les déplacer dans les sprints à venir. Le meilleur moyen est peut-être d’utiliser le « Backlog Kanban – Sprint View » de Jira Align. Cela permet de faire glisser les stories et les tâches du backlog non assignées (visibles sur la droite) dans les différentes colonnes de gestion des sprints (visibles sur la gauche). Celles-ci affichent le total des « story points » de chaque sprint ainsi que la vélocité moyenne de l’équipe des 5 derniers sprints. C’est un bon indicateur pour montrer la charge de travail réelle de chaque sprint en se basant sur les données chiffrées de leur disponibilité et d’autres facteurs. Notez qu’à l’aide de la fonction « override » (neutralisation), les équipes peuvent ne pas tenir compte de leur vélocité moyenne.

 

 

Tous les détails de cette approche sont disponibles dans cet article écrit par Rob Phillips.

Note : les utilisateurs de Jira Software à l’échelle d’une équipe sont considérés comme des « utilisateurs intégrés » de Jira Align. Leurs données sont synchronisées avec Jira Align et leur permettent d’accéder à ses fonctionnalités, tel que le Backlog Kanban – Sprint View (image ci-dessus).

Au cours d’un breakout, les équipes ajoutent également les fonctionnalités et les dépendances associées au Program Board. Dans une réelle Big Room, les post-its et ficelles permettent de mieux les visualiser. Pourtant, les plus grandes entreprises utilisent depuis longtemps le Program Board de Jira Align pour le PI Planning. La première raison est qu’il permet de gagner du temps en entrant les données physiques du tableau dans l’outil. La deuxième raison est que Jira Align dispose d’une fonctionnalité relative aux dépendances qui permet de faire respecter un contrat (documenté et traçable jusqu’à sa résolution) entre les équipes, fournissant des illustrations visuelles utiles lors du Management Review (Comité de révision) et de la session de Problem Solving (Résolution de problèmes). Par exemple, un nombre trop important de dépendances sur une seule équipe peut justifier une redistribution de ses membres pour réduire les silos de connaissances.

Le Program Board de Jira Align est utilisé par tous pour suivre le statut du PI car il permet de visualiser les sprints de livraison des fonctionnalités et de ses dépendances. Par exemple, le rouge signifie qu’une tâche est bloquée et l’orange indique des problèmes de programmation. Au fur et à mesure que les Product Owners rédigent des Stories pour chaque fonctionnalité, celle-ci (représentée sous forme de rectangle) atterrit dans les swimlanes (couloirs d’activité) de leurs équipes. Les tâches n’ayant pas de stories associées lors du PI Planning peuvent être affichées dans la colonne « non assignée » à gauche des colonnes de sprints. Les équipes peuvent ainsi les lier à un sprint même si les stories ne sont pas encore écrites.

Contrairement à un tableau physique pouvant être encombré de fils rouges pour les dépendances, Jira Align représente les dépendances par des symboles en chevron dans les swimlanes des équipes dont dépendent d’autres équipes (y compris les équipes d’autres ART). Si vous souhaitez toutefois voir des liaisons, essayez la dependency wheel (roue des dépendances), l’une des nombreuses visualisations proposées par Jira Align :

Cette visualisation a aidé de nombreuses organisations à ajuster la structure de leurs ART pour réduire les dépendances et améliorer le flux de livraison.

Les conversations sur les dépendances pourraient également être ajoutée aux Working Agreements étant donné l’importance de la collaboration entre les équipes. Il est facile de traverser la Big Room ou de se rendre dans une salle de réunion, mais comment gérer les discussions de manière virtuelle ? Les autres équipes sont-elles autorisées à se rendre dans les salles de réunion ou doivent-elles le planifier en amont ? Une première recommandation est d’afficher les « office hours » (heures de passage autorisées) pour le passage des autres équipes. Une autre est d’utiliser les points de synchronisation d’équipe recommandés par SAFe. Dans ce cas-là, n’oubliez pas de prévoir du temps à l’avance. Les règles de courtoisie habituelles sont toujours de mises lors du PI Planning. Par exemple, avant d’entrer une dépendance dans Jira Align, assurez-vous d’en avoir discuté en amont avec les personnes concernées, pour que son suivi jusqu’à sa résolution se fasse dans la bienséance.

Au fur et à mesure de la progression du breakout, gardez à l’esprit les résultats que chaque équipe communiquera lors de l’ébauche de la revue de planning (draft plan review) et de la révision finale du planning (final plan review) :

Après avoir pris en considération la capacité et la charge de travail, abordons désormais les objectifs du PI adressés aux équipes, synthétisé par le RTE en Program Objectives (Objectifs du programme). Une fois ajoutés par les équipes dans Jira Align, ceux-ci apparaissent dans le Program Board sous forme d’hexagones au-dessus des swimlanes des équipes, et reliées aux fonctionnalités associées. Les Business Owners déterminent la valeur business de chaque objectif sur une échelle de 1 à 10 et l’ajoutent dans Jira Align. Les Key Results (résultats clés) pourraient également être ajoutés, bien que SAFe ne les recommande actuellement que dans le cadre des thèmes stratégiques de plus haut niveau. Les équipes et le RTE peuvent appliquer des filtres sur la liste de leurs objectifs pour une meilleure visualisation ou lors d’un export.

Enfin, examinons comment les équipes peuvent gérer les risques.

Program Risks

Pendant les pauses, les équipes identifient les risques et les obstacles liés aux programmes qui pourraient avoir un impact sur leur capacité à atteindre leurs objectifs. Ceux-ci sont examinés en toute transparence ensemble dans le cadre d’un ART, facilité par le RTE (servant leader), et classés dans un tableau ROAM, disponible dans Jira Align :

  • Resolved (Résolu) – Les équipes conviennent que le problème n’est plus préoccupant.
  • Owned (Attribué) – Un membre de l’ART s’approprie le point puisqu’il ne peut être résolu lors de la réunion.
  • Accepted (Accepté) – Certains risques ne sont que des faits ou des problèmes potentiels qui doivent être compris et acceptés.
  • Migrated (Atténué) – Les équipes peuvent identifier un plan pour réduire l’impact d’une tâche.

 

 

Après le final Plan Review et l’évaluation des risques, l’ART et ses équipes sont prêts pour le vote de confiance.

Le vote de confiance

Les Scrum Masters peuvent recueillir les votes de confiance de leurs équipes en amont afin de réduire la complexité du dépouillement en temps-réel. Puis toutes les équipes communiquent leurs votes en direct lors du « Combined ART confidence vote » (vote de confiance cumulé de l’ART) via un système de points basé sur les doigts de la main devant leurs webcams.

 

 

La planification rétrospective

Enfin, la RTE mène une brève rétrospective de l’événement du PI Planning afin de mettre en avant ce qui a bien fonctionné, expliquer ce qui n’a pas fonctionné et comment l’améliorer la prochaine fois. Cette rétrospective peut être effectuée en ligne dans les jours qui suivent l’événement afin de raccourcir le calendrier et de permettre aux équipes de se reposer. Envisagez de recueillir des informations à l’avance en utilisant un outil comme Survey Monkey pour mener une réunion en ligne plus courte et plus productive.

Réflexions finales

Face au Covid-19, la communauté agile fait émerger des réponses tant au niveau des pratiques que des outils. Nous continuons à découvrir de meilleurs moyens de planifier et de fournir des services de manière efficace et efficiente tout en étant géographiquement dispersés. Nous vous invitons à nous faire part de vos commentaires et des leçons apprises de vos efforts d’amélioration continue. Notez également que Scaled Agile et Atlassian ont créé des sites web qui seront mis à jour au fur et à mesure que les pratiques s’amélioreront grâce à des actions d’inspection et d’adaptation. Je vous invite également à lire les bonnes pratiques et FAQ proposées par la communauté Scaled Agile pour adapter la méthode SAFe durant cette crise du Coronavirus ainsi que par la communauté Atlassian pour mener un PI Planning virtuel.

Nous pouvons vous aider

Souhaitez-vous obtenir de l’aide pour mettre en œuvre les outils Atlassian afin de soutenir votre travail d’équipe à distance ? En tant qu’expert de la transformation digitale, Valiantys met à votre disposition des consultants SPC qui vous aideront à réaliser des audits pour vous donner le pouls de vos équipes agiles. Repartez avec une analyse complète des individus, des interactions, ainsi que des outils qui les relient. Contactez-nous dès maintenant.