Le Release Planning est incontestablement l’un des cérémonials le plus important du framework SAFe. Bien que son nom est changé, dans la version 4.0 (Release Planning deviens PI Planning), ses objectifs et son déroulé reste globalement les mêmes.

Je vous propose de vous présenter comment s’est déroulé le Release Planning de l’organisation que j’accompagnais et surtout les difficultés que nous avons rencontrés dans son application. Pour cela, j’ai découpé cette description en 4 articles, décrivant chacun une demi-journée du PI Planning. Cet article représente la première demi-journée.

Pour ne pas créer de confusion avec la dernière version 4.0 de SAFe, j’utiliserais le terme PI Planning, dans le suite de cet article.

Nota : contrairement à ce que j’ai pu lire dans un récent article, PI ne signifie pas Product Increment, mais Program Increment. Cela fait sens, étant donné qu’un programme peut contenir plusieurs produits et que SAFe a justement pour objectif de gérer des programmes à l’échelle.

Vous pouvez lire le premier article de cette série : SAFE from the inside : #1 Big Picture.

Pour commencer, un peu de théorie

Le PI Planning est avant tout l’événement majeur permettant, à intervalle régulier, la rencontre de l’ensemble des parties prenantes d’un programme (Managers, Développeurs, Business Owner, Product Owner, Architectes, Testeurs, …). Elle se base sur l’une des 4 valeurs du manifeste agile, qui veut que l’on va privilégier la communication directe entre les personnes.

Plusieurs PI Planning peuvent avoir lieu (en général 3), à une cadence de 8 à 12 semaines (selon que vous fassiez des sprints de 2 à 3 semaines), au sein d’un même ART (Agile Release Train).

Le PI Planning se déroule sur une période de 2 journées (eh oui, 2 jours ou sont réunis dans une même salle, ou en visio-conférence, de 50 à plus de 100 personnes. Aération en état de marche et fenêtres pouvant s’ouvrir en grand conseillées !!!) et se base sur l’agenda standard suivant :

Les bénéfices attendus d’un tel cérémonial, tels que décris dans la documentation SAFe, sont les suivants :

• Etablir un fort niveau de communication entre toutes les équipes SAFe et les parties prenantes ;
• Aligner les équipes de développement et le business, via la vision, le contexte et les objectifs du PI pour le programme et les équipes ;
• Identifier les dépendances entre les équipes et encourager la coordination entre celles-ci ;
• Intégrer la bonne dose d’architecture et de User Expérience (UX), dans les activités et pratiques des équipes ;
• Adapter le travail à la capacité à faire des équipes et éviter le gaspillage ;
• Accélérer les prises de décision.

Bien entendu, cela sous-entend qu’un certain nombre d’éléments devront être fournis en entrée du PI Planning, comme :

• La roadmap du programme, sur les 3 prochains PI Planning ;
• La vision du business ;
• Le top 10 des features, du Program Backlog, à réaliser dans le PI Planning.

Pour ce qui est des résultats attendus d’un tel événement, je les aborderais un à un dans le déroulé de ces 2 journées.

Voilà pour la théorie.

Il y a une vie avant le PI Planning

Comme dans tout projet, qu’il soit agile ou non, on ne se lance pas dans la phase de delivery (développement), sans un minimum de préparation et notamment sans avoir identifié, à minima, la cartographie de votre produit/programme. Et c’est bien la où j’ai été un peu surpris (pour ne pas dire déçut) par le framework SAFe. Lui qui a tendance à embarquer toutes les pratiques agile existantes, ne fait pas la moindre référence au story mapping, n’y à son utilisation. SAFe parle de roadmap, mais à mon sens une roadmap ne peut avoir le même objectif qu’un story mapping, qui est avant tout de partager une compréhension mutuelle du besoin métier, entre toutes les parties prenantes.

Lorsque vous êtes sur un programme stratégique, touchant au coeur de métier de l’entreprise, avec autant de représentant métier que de filiales, un legacy complexe et des équipes de développement découvrant à peine les locaux, vous ne pouvez vous passer d’une cartographie vous permettant d’identifier les besoins de vos métiers, ainsi que les risques et les impacts techniques.

C’est pour cela que j’ai immédiatement proposé d’animer une session de story mapping, qui a finalement eu lieu sur 2 journées pleines (09h – 19h, avec juste une pause plateau-repas d’1 heure !!!), tant le sujet était d’ampleur et la priorisation complexe à réaliser. Ce travail a permis d’alimenter le Program Backlog du niveau Program.

En théorie, SAFe veut que le Program Backlog soit alimenté avec les Features, qui sont ensuite priorisées et gérées par le Product Management. A ce stade, les features en sont encore à l’état brute, avec une documentation légère, permettant de les présenter lors du PI Planning. Vous verrez par la suite que ce mode d’organisation a généré une certaine incompréhension et un grand stress au niveau des équipes, notamment des Product Owner et comment le travail effectué sur le Story Mapping nous a permis de traiter cette étape.

Mais, il est temps de passer au vif du sujet et vous décrire comment s’est passé mon PI Planning.

PI Planning – Day 1 AM

Nous y voila, mon premier PI Planning va commencer. Même si j’ai un certaine habitude des cérémonials agile et de l’animation d’équipe, je ne peut m’empêcher d’être un peu stressé par un tel événement, qui va rassembler environ 60 personnes sur 2 jours, d’autant que je dois, ma certification SAFe Agilist en poche (ça y est, je suis un expert!!), accompagner l’une des Team Agile SAFe.

Pour ces 2 jours, nous sommes accompagnés par 3 coachs certifiés SAFe CSP, ayant déjà une première expérience dans la mise en place du framework.

Je suis surpris de croiser des personnes que je n’avais encore jamais rencontrées et qui pourtant font partie, à part entière, du programme. Un bon point pour SAFe, au moins cela permet de réunir des personnes qui dans une organisation en silos ne se seraient peut-être jamais parlées, à part par mail ou téléphone.

9:30 – 9:45 Introduction

L’animateur (je devrais dire le facilitateur) de l’événement, qui n’est autre que le RTE (Release Train Engineer) accompagné du lead coach, commence par faire une présentation rapide des raisons pour lesquelles nous sommes tous réunis, à savoir « Obtenir un alignement entre tous les acteurs du programme, formalisés sous formes d’objectifs communs, ayant valeur d’engagement, au niveau du programme et de chaque équipe ». Voila qui est clair, net et précis.

Ensuite nous somme passés rapidement à :

• Un rappel des 4 principales valeurs agiles, comme mode d’inspiration pour réussir notre PI ;
• Une présentation du planning des 2 jours (celui présenté au chapitre précédent) ;
• Une présentation de l’ensemble des acteurs au niveau Program et au niveau Team ;
• Un rappel des règles de bonne vie en communauté (à ne pas négliger) ;
• Une liste d’éléments clés pour bien appréhender ce PI :

9:45 – 10:15 Contexte

On rentre dans le vif du sujet, pourquoi sommes nous réellement la ? Qu’est ce qui justifie un tel investissement humain, logistique, organisationnel et financier ? Une transformation à l’échelle n’est pas gratuite et n’est pas faites pour suivre un effet de mode.

La, ce sont les Business Owner qui prennent la main. Nous avons droit à une description détaillée du contexte business de l’entreprise, ses diversifications, ses choix stratégiques de croissance, le contexte économique dans lequel elle évolue et la pression concurrentielle à laquelle elle est soumise.

Ensuite viennent les enjeux business du programme pour l’entreprise et les challenges que celle-ci doit relever, en terme de transformation digitale, d’innovation du business, de respect du TTM (Time To Market) et de réduction de l’obsolescence technologique.

La, je prend une grande claque. Cela fait plus de 4 mois que je suis présent dans l’entreprise, à accompagner une équipe projet, et jamais je n’avais eu accès à ces informations de premières importances. Celles-ci me permettent de comprendre concrètement pourquoi un tel programme a été lancé et pourquoi il a été décidé d’utiliser les pratiques agiles en générale et SAFe en particulier.

Second bon point pour SAFe. Le PI Planning permet indéniablement d’aligner tout le monde sur une compréhension mutuelle et partagée du contexte et des objectifs d’une entreprise.

La seule chose qui me gêne, à ce stade, c’est que je me rend compte que nous mettons en œuvre une démarche de transformation (sur un framework qui bien qu’« agile » apparaît quand même lourd), avec des équipes qui n’ont aucune expérience des projets agile et encore moins de la culture et du paradigme qui va avec. Cela me semble simplement dangereux de se lancer dans une telle aventure, sans avoir au préalable travailler sur la montée en maturité de l’organisation (à tous ses niveaux, IT, Métier, RH, Marketing, Direction, …), sur un nouveau mode de travail agile. Comment les participants vont-ils appréhender ce nouveau mode de fonctionnement, ne risque t-on pas de voir revenir les anciennes habitudes (ou plutôt les habitudes actuelles) de « command & control » que nous voulions justement voir disparaître ? Je reste septique et inquiet pour la suite de ce PI Planning.

10:15 – 11:15 Vision : Produit/Solution

Au tour du Product Management d’entrée en piste, pour présenter la vision du programme qui nous réunis.

Avec la partie vision on rentre un peu plus dans le coeur de se PI Planning, à savoir :

• Une description du périmètre et de la chaine de valeur du programme ;
• Une présentation de la cartographie des briques fonctionnelles du programme ;
• Une analyse SWOT de l’ensemble des produits constituant le programme ;
• La Roadmap à 9 mois ;
• En enfin, une présentation des Features proposées sur ce PI Planning.

Cette phase a permise aux Team Agile de découvrir, plus en détail, l’ensemble des produits constituant le programme et par la même d’en savoir un peu plus sur le fonctionnement du métier (un peu, car en 1 heure difficile de faire des miracles).

La matrice SWOT, a permise de montrer, de façon factuelle et transparente, les menaces et faiblesses du programme auxquelles nous allions devoir faire face, mais également la force de l’architecture et l’opportunité de l’utilisation des pratiques agiles au service de l’innovation et des enjeux métier. L’agilité est bien perçut comme un moyen d’atteindre un objectif business et non comme l’objectif lui-même et ça j’achète (faut vraiment que j’arrête de regarder « Danse avec les stars »).

Par contre, j’ai été un peu déçu par la présentation des Features, que j’ai trouvé trop succincte, dans un délai il est vrai très court (1 heure pour tout ça, c’est chaud). D’autant que nous avions affaire à des Teams Agile novice dans le coeur de métier très particulier de l’entreprise. Au total, 10 Feature fonctionnelles et 7 Feature techniques ont été présentées dans ce PI Planning, pour une organisation composée de 2 Team fonctionnelles (FeatureTeam ?) et une Team Technique.

Un 1/2 point donc pour SAFe sur cette partie. Je préférerais, personnellement, que les features soient partagés avec les parties prenantes, lors d’une phase de Story Mapping, afin d’éviter de les découvrir en 1 heure, dans le contexte intense qu’est le PI Planning.

Bon allez, il est temps de faire une petite pause et de prendre un café bien serré. Je sens qu’on va tous en avoir besoin !!!

11:30 – 12:15 Vision de l’architecture & pratiques de développement

Au tour de la System Team & de la Team Architecture & Méthodes de contribuer à ce PI Planning.

En 45 minutes chrono, nous avons droit à une présentation de :

• L’architecture applicative existante ;
• L’intégration continue & les outils qui seront utilisés dans la gestion de configuration, les serveurs de développements, … ;
• La méthode d’intégration continue qui sera mise en place ;
• Le processus de tests unitaires, fonctionnel, technique, sans bien sur oublié la place de l’automatisation des test unitaires (TDD) et fonctionnels (BDD) ;
• Les enjeux d’architecture à moyen & long terme (un indice, y a du DevOps dedans) ;
• Les règles d’ingénierie à appliquer par toutes les Team

La encore un point pour SAFe. On fait enfin la place à l’architecture dans une démarche agile. Les architectes ne sont plus considérés comme de empêcheurs de tourner en rond, mais comme faisant partie intégrante de la Team Agile et apportant une vraie plus value en matière de stratégie d’architecture logicielle du SI. Idem pour la Team en charge de la stratégie de test, bien souvent considérée comme la cinquième roue du carrosse. La, elle fait partie intégrante de la stratégie du PI Planning et est un acteur majeur dans la mise en oeuvre et la mesure de la qualité fonctionnelle du programme.

L’autre élément positif est le partage des pratiques de développement, que l’ensemble des Team Agile aura à déployer sur le programme. Ce n’est pas anodin, car cela va à la fois permettre de garantir une cohérence dans la qualité de l’ingénierie logicielle et est un des premiers éléments de mise en place des communautés de pratiques au sein du programme SAFe (PO, SM, Développeurs, Testeurs, …). La, on commence à toucher au modèle Spotify (comme quoi, il semble inutile d’inventer des buzzword du type SpotiSafe. Ce modèle semble déjà intégré dans SAFe. C’est ça un framework, la possibilité d’y implémenter ce dont on a besoin, à l’intérieur d’un cadre existant ;)).

12:15 – 12:45 Contexte du planning

Le RTE reprend la main et présente, dans cette phase, les livrables attendus de ce PI Planning, à savoir :

• Les Objectifs du PSI, par Team Agile, qui alimenterons les Objectif du PSI pour le Program
• Les livrables de chaque Team Agile :

• Le Program Board du Program, qui reflète les features à livrer, les dépendances entre Team Agile et les jalons

• Et une présentation de la façon dont devra se dérouler le Team Breakout, dont je vous parlerai en détail par la suite.

Et la c’est le drame !!! Je me disais bien que tout cela ne pouvait pas être aussi parfait, aussi magique qu’on nous l’a présenté.

Tout d’abord, je m’aperçois dans le schéma que l’on associe Vélocité (ou capacité) et charge en j/h. Aie, ça commence à piquer les yeux !!! Ensuite, je suis surpris de lire que la première vélocité (pardon capacité) à indiquer est une simple multiplication du nombre de membre de la Team Agile (développeurs et testeurs) par 8. Pourquoi 8 ? Et bien parce que les sprints sont sur 2 semaines, soit 10 jours ouvrés et que l’on considère que l’équipe va coder et tester pendant 8 jours. En plus, si un membre de l’équipe est en vacances et bien il suffit de retirer 1 point par jour d’absence.

Bien sur mon esprit suspicieux et râleur, me fait faire un calcul tout simple. Si je dit qu’une personne peut faire 8 points sur un sprint de 2 semaines et que lorsqu’il est absent on doit retirer 1 point, alors … cela signifie que 1 point = 1 jour !!! Du coup, à quoi bon mesurer une capacité (ou vélocité, je sais plus !!!) alors qu’il est tellement plus simple de faire une bonne veille mesure de charge en j/h, comme on les aimes tant !!! A quoi bon tout se travail à aider les manageurs et les équipes à changer de paradigme et ne plus penser en j/h, pour y revenir de façon aussi insidieuse ?

L’autre élément qui me surprend, dans cette présentation, est le Program Board qui représente les dépendances entre les Features. Si jusque la, rien de problématique, ce qui l’est est qu’une Feature semble devoir être réalisée dans un sprint et par une seule équipe !?!?! Autant par une équipe, cela ne me pose pas plus de problème (à la condition que l’on soit vraiment dans un mode Feature Team et pas Component Team), autant sur un sprint, je crains que cela pose des problèmes et apporte certaines déconvenues.

Mon feedback sur cette première demi-journée de PI Planning

Ce que j’ai aimé

• La réunion, en un même endroit, de l’ensemble des parties prenantes d’un programme, durant 2 jours, afin de renforcer le sentiment de Team building ;

• Le partage d’une compréhension commune de la vision et des objectifs de l’entreprise et du programme ;

• L’implication des architectes et des testeurs ;

• L’émergence de communautés de pratiques PO, SM, Développeurs, …

• Etre accompagné par des coachs ayant déjà une expérience dans la mise en oeuvre de SAFe. C’est un conseil que je ne saurais que trop donner aux organisations souhaitant passer sur ce type de framework. Aujourd’hui, de nombreuses sociétés se présentent comme des experts sur ce marché (juteux ?) qu’est SAFe, sans nécessairement avoir l’expérience pratique de sa mise en oeuvre. Un formateur SAFe ne fait pas un coach SAFe, alors attention à privilégier la pratique à la théorie. C’est un avis personnel.

Mes regrets

• L’absence de mise en oeuvre d’un véritable Story Mapping, permettant d’avoir une vision globale de la cartographie du programme et ainsi de partager ensemble une compréhension commune du besoin métier et des impacts techniques ;

• Le mode d’estimation de la première vélocité (ou capacité) des Team Agile, en mode mi-story point, mi-j/h, contraire à l’esprit et ne me semblant pas permettre un véritable engagement des équipes ;

• La présentation en séance des Features, aux Teams Agile, de façon très macro, sur une heure. Cela n’a pas permis de dégager une vraie compréhension du besoin et des impacts fonctionnels et techniques de chaque feature et a laisser les équipes de développement dubitatives ;

• La mise en place d’un framework majeur comme SAFe, sans au préalable avoir travailler sur la montée en maturité agile de l’ensemble de l’organisation.

La suite

Dans le seconde partie de cet article, je vous décrirais le déroulé de la seconde demi-journée, avec notamment le fameux Team Breakout.

Pour aller plus loin

Si vous voulez en savoir plus sur la préparation du PI Planning, voici quelques récents articles que je vous conseille :

Les 5 choses à ne pas oublier avant un PI Planning SAFe

Les 4 clés pour réussir son PI Planning