Exécution du PI

Introduction

Suite au PI Planning, les équipes du train ont 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. 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 Retrospective.

Au Team Level, il n’y a donc rien de vraiment nouveau dans SAFe par rapport à ce qu’une équipe Scrum isolée pourrait pratiquer. La différence va s’en doute se jouer au niveau de la Sprint Review où, côté SAFe, les démonstrations se font avec toutes les équipes du train à chaque fin d’itération ; on parle de System Demo. Chaque équipe déploie sa solution dans un environnement partagé dédié à la démonstration et, si possible, très proche de la configuration de l’environnement de production....

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 quand on intègre 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...

Le PO Sync

Le PO Sync 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.

Le RTE ne s’intéresse pas aux US ou au code ; il souhaite savoir si les Features engagées sur le PI sont sur la bonne voie. Au niveau Team, c’est le Scrum Master qui doit veiller à ce que tout se passe bien ; c’est lui qui se débarrasse ou fait débarrasser les obstacles empêchant l’équipe d’atteindre ses objectifs. Cependant, au PO Sync, on s’intéresse à l’avancement de l’incrément au niveau fonctionnel : y-a-t-il des points bloquants sur certaines Features ? Des besoins de réajustement par rapport au planning initié lors du PI Planning ? Des besoins de repriorisation ?

Le RTE est aussi sensible à l’avancement de la préparation du prochain PI Planning. Ainsi...

Scrum of Scrums

Si le PO Sync s’intéresse aux aspects métiers, avec le Scrum of Scrums (SoS), on cible 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 le dernier SoS, ce qu’elle fait et prévoit de faire entre le moment présent et la prochaine réunion SoS. 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, le SoS permet d’identifier rapidement le problème pour employer les grands moyens avec l’aide du RTE.

En cas de problème complexe évoqué lors du meeting, le RTE organise une réunion ad hoc avec les bonnes personnes pour traiter rapidement le problème. Il peut aussi déléguer la tâche au Scrum Master...

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 ci-dessus 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 PI Planning...