Exécution du PI

Introduction

Nous avons vu que les objectifs du PI Planning (PIP) étaient d’aligner le train avec ses équipes ou les trains pour s’assurer un engagement commun vis-à-vis de la vision stratégique de l’entreprise. Chaque équipe des différents trains, lors du PIP établit un plan pour le développement des fonctionnalités à livrer au cours du prochain PI. La gestion des Dépendances entre équipes ainsi que la gestion des risques ont également été abordées durant le PIP afin d’anticiper les blocages et les retards dans le processus de livraison. Suite au PI Planning, les équipes ont donc une bonne idée de ce qu’elles doivent faire sur les trois prochains mois.

Ainsi, sprint par sprint, elles essayeront d’atteindre les objectifs fixés lors du PI Planning. Rappelons que le PI est simplement une période contenant des sprints et qu’elle peut s’étendre de 8 à 12 semaines, soit 4 à 6 sprints de 10 jours soit environ 3 mois. La configuration la plus pratiquée en France est de 5 sprints suivis du sprint Innovation & Planning (IP).

Tout ce que nous avons vu au niveau de Scrum sera pratiqué durant les sprints du PI. Pour chaque sprint (ou itération), nous retrouverons donc un Sprint Planning, un atelier de Refinement, les Daily, une Sprint Review ainsi qu’une...

System Demo

J’ai vu des équipes SAFe pratiquer chacune de leur côté les démonstrations ; je trouve que c’est une erreur fondamentale. Même si le dernier sprint (IP) du PI impose la System Demo, ce n’est pas une raison pour négliger de faire ensemble les démonstrations à chaque fin de sprint. La règle d’or est de détecter les problèmes au plus tôt et d’obtenir des retours assez rapidement pour une meilleure réactivité. Attendre le dernier sprint du PI pour faire une démonstration générale de la production du train, c’est prendre le risque de découvrir au dernier moment les problèmes d’intégration entre les différentes équipes. Il est donc vital de faire des démonstrations générales à chaque fin de sprint ! Ce n’est pas parce que tout fonctionne à merveille dans chaque équipe que cela signifie que les différents composants s’intégreront parfaitement une fois assemblés ! On rencontre le même souci, lors des tests d’intégration, quand on assemble le travail de plusieurs développeurs d’une même équipe. Ici, on doit intégrer le travail de plusieurs équipes !

Sur le dernier sprint (Innovation & Planning) du PI, comme nous le disions, les équipes doivent effectuer une démonstration de l’ensemble des fonctionnalités qui ont été réalisées par toutes les équipes du train : c’est la System Demo. Les Business Owners, Program Managers, Customers et PO, entre autres, doivent absolument être présents pour faire rapidement des feedbacks. On n’oubliera pas d’inviter quelques membres de l’équipe DevOps au cas où quelques soucis techniques viendraient perturber la cérémonie...

On ne peut pas éviter la System Demo, c’est le seul moyen de constater ce qui a été vraiment produit par toutes les équipes du train. C’est la meilleure mesure qu’on puisse effectuer sur le PI ! Nous disions aussi que certaines entreprises évitent de faire des System Demo à chaque fin de sprint....

La synchro des PO (PO Sync)

La version 6.0 de SAFe parle désormais de la Synchro des PO anciennement nommée PO Sync. Cet évènement permet de synchroniser le feedback de tous les Product Owners d’un train. C’est un événement SAFe qui est normalement organisé par le RTE. De façon hebdomadaire, il convoque tous les PO du train pour sonder l’avancement de la production de l’ART. Le Product Manager (PM) peut également organiser cette réunion qui dure environ 30 à 60 minutes. Le feedback des PO donne de la visibilité sur l’avancement. Selon les problèmes remontés, on peut donc réagir immédiatement pour les résoudre. À ce niveau, nous parlons des problèmes métier essentiellement, on échange sur les fonctionnalités qui bloquent.

Le RTE ne rentre pas dans les détails du niveau US ou du code ; il souhaite savoir si les Features engagées sur le PI sont sur la bonne voie. Au niveau des équipes, c’est le Scrum Master qui doit veiller à ce que tout se passe bien au niveau fonctionnel comme au niveau technique, organisationnel ou relationnel ; c’est lui qui se débarrasse ou fait débarrasser les obstacles empêchant l’équipe d’atteindre ses objectifs. Cependant, à la Synchro des PO, on s’intéresse à...

La synchro des coaches (Scrum of Scrums)

De même, cette cérémonie Scrum of Scrums (Sos) a été rebaptisée Synchro des coaches. Les Scrum Masters sont aussi des coaches agiles dans la nouvelle vision de SAFe.

Si la synchro des PO s’intéresse aux aspects métiers, avec la synchro des coaches, on cible particulièrement les aspects techniques : non seulement les obstacles techniques, mais aussi la maturité des équipes en matière d’agilité. Dans ce meeting, le RTE convoque cette fois-ci les Scrum Masters des différentes équipes du train. La réunion dure de 30 à 60 minutes. Le protocole au niveau des échanges se rapproche un peu de celui du Daily Scrum. Ici, le RTE porte son intérêt sur ce que telle équipe a réalisé depuis la dernière réunion avec ses Scrum Masters, ce que l’équipe a fait et prévoit de faire entre le moment présent et la prochaine réunion. Le RTE doit savoir s’il y a le moindre blocage car il a la haute responsabilité d’éliminer les obstacles qui pourraient faire dérailler le train. Il s’appuie en toute confiance sur les Scrum Masters, mais quand le problème ne peut être réglé au sein d’une équipe, la Synchro des Coaches permet d’identifier rapidement le problème...

IP Itération

Au chapitre « Prenons un train SAFe en marche », nous avons vu un exemple de calendrier planifiant le travail sur le sprint IP. Sur le schéma ci-dessous, voici un résumé de tout ce qu’on peut faire sur ce sprint IP :

L’itération Innovation and Planning (IP) est le dernier sprint de chaque PI. Durant les dix jours de ce dernier sprint, différentes activités sont proposées. L’événement le plus important de ce sprint est évidemment le PI Planning qui se déroule sur 2 jours.

Un autre événement important est l’Inspect & Adapt (I&A) qui se décline en trois parties : une partie dédiée à la System Demo, une autre à la prise de température où l’on mesure la productivité du PI, et la dernière partie qui est une Retrospective où l’on tente aussi de résoudre les problèmes en suspens. Le PI Planning du prochain PI approchant, on est forcément très concentré sur la préparation de ce PI pour régler les derniers points. On profite aussi de cette période pour faire de l’innovation et de la veille technologique. Si le travail n’a pas été fini sur les développements, les équipes peuvent finaliser ici les tâches ; mais ne commettez surtout pas l’erreur de programmer la démonstration générale selon les prévisions de finalisation des éléments restant à développer ! Tout est timeboxé dans l’agilité pour éviter des annonces telles que : « On a pratiquement fini, dans deux jours, on sera prêts !  », suivies d’un retard d’une semaine !

On fixe les dates de System Demo et les équipes s’y alignent pour finaliser ce qu’il reste à faire ; mais autant le reconnaître, prendre du temps sur ce dernier sprint pour les finitions est vraiment une mauvaise habitude. À la rigueur, on peut entamer ce qui avait été prévu en Stretch mais pour le reste, mieux vaut tout boucler avant le dernier sprint IP.

Le mécanisme bien huilé

Le schéma précédent décrit toute la chaîne de fabrication, de l’idée stratégique à sa réalisation.

On part d’une Roadmap globale avec une vision par exemple sur deux ans. Cette Roadmap globale est validée durant le tout premier PI Planning mais les équipes ont déjà commencé à travailler dessus quelques mois auparavant. Encore une fois, on n’arrive pas les mains dans les poches pour construire la Roadmap lors de ce tout premier PI Planning ! Une fois cette vision à long terme définie, chaque équipe commence à décortiquer ses macro Epics. Dans ce but, le meilleur outil est le Story Mapping, qui nous permet de décomposer nos Epics et Features jusqu’au niveau le plus bas, c’est-à-dire le niveau User Story. Nous décomposons suffisamment jusqu’à pouvoir alimenter tous les sprints de notre PI. Arrivés au PI Planning, nous validons notre planning. On remplit ensuite notre Product Backlog avec toutes les US des différents sprints planifiés lors du PI Planning. Une fois le Backlog prêt, on lance notre Sprint Planning et le sprint peut démarrer. On exécute ainsi les différents sprints du PI, jusqu’à arriver au PI Planning suivant.

Durant le PI, on a pris soin de préparer ce futur...