La revue de sprint n’étant pas uniquement une démonstration du produit livré, il est nécessaire d’apporter les données pertinentes pour prendre des décisions éclairées et éviter ainsi le pilotage au feeling.
Au fil du temps et de mon expérience, j’en ai défini le modèle / programme suivant avec 2 temps :
- L’inspection par les faits et les indicateurs présentés,
- Puis la partie atelier pour prendre des décisions.
Chapitre 0 : Qui faut-il inviter ?
Il n’est pas rare de voir des équipiers fatigués de venir à une présentation où il n’y a qu’eux et des managers. La revue de sprint est alors là pour coller au “modèle” mais on en obtient pas grand chose. Pourquoi ? Le public n’est généralement pas le bon.
Certains scrum masters défendent coûte que coûte l’idée qu’il faille des utilisateurs finaux en revue de sprint. Ce n’est pas tout le temps la bonne manière de faire. Dans le meilleur des cas, nous sommes sur une solution avec des interfaces qu’ils auront par la suite dans les mains, mais seul l’aspect fonctionnel sera regardé. Pourtant nous faisons des produits IT.
La Scrum Team présente les résultats de son travail aux principales parties prenantes et les progressions vers l’Objectif de Produit sont discutées.
Guide Scrum
Plus que les utilisateurs finaux, les invités doivent être les bénéficiaires de vos livrables. Mais qui sont-ils alors ? Plusieurs possibilités :
- Vous présentez des interfaces ou fonctionnalités : ce seront des opérateurs fonctionnels, des métiers, product managers, et autres personnes curieuses de votre produit.
- Votre équipe a livré des API ou autres services exposés: Vous invitez les équipes qui consommeront ces services et qui vous demanderont des bouchons par exemple.
- Vous avez livré de la documentation, comme un doc d’exploitation avec des fiches consignes en cas d’incident, ce seront les ops des équipes de production qui seront intéressés.
- Besoin de support, de cadre, de décisions managériales : invitez le management adéquat.
Favorisez les échanges entre ceux qui produisent et ceux qui en bénéficient. Créez de la confiance et décidez ensemble du meilleur chemin pour atteindre les objectifs de l’entreprise.
Vous avez une invitation qui vise large. Très bien ! Affinez votre public à chaque sprint. Vous avez défini des objectifs et un plan en sprint planning, à mi-chemin de votre sprint vous êtes plutôt au clair sur ce qui devrait être livré. Mettez à jour votre invitation en conséquence à ce moment.
Chapitre 1 : place à l’inspection
Redonner du contexte
Comme dirait Simon Sinek : “Start with Why”. Tout le monde n’a pas vécu les 15 jours avec vous, il faut les réintégrer pour aider à la compréhension de ce qui suivra.
Dans quel but : Évoquer les faits marquants et les objectifs que l’équipe s’était fixés pour permettre à chacun de se reconnecter au(x) sujet(s) et adopter la bonne posture durant ses interventions dans la suite de l’atelier.
L’équipe vient de travailler d’arrache pied pendant 1, 2 ou 3 semaines, selon la durée de vos sprints (La bonne valeur étant 2 semaines 😛). Elle avait un ou plusieurs objectifs et a logiquement plutôt suivi son plan.
Il s’est certainement passé des choses à partager (exemples : incident majeur, nouvelle arrivée dans l’équipe, livraison tant attendue, changement de priorité etc.).
Comment : 1 slide en 1 minute maximum. C’est de l’information pas une invitation aux débats.
Note : Ce n’est pas le slide qui crée la valeur, il vous aidera à suivre un fil et afficher de la data. N’y passez pas longtemps dessus.
Show must go on!
Pas question de faire attendre, après l’introduction, la démonstration embraye tout de suite !
“Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée”
Dans quel but : Inspecter le livrable sur le plan fonctionnel et récolter leurs appréciations positives comme négatives. Faites parler les bénéficiaires de leur quotidien et de leurs problématiques, ça intéressera votre équipe.
C’est l’occasion de créer un lien entre les producteurs et les consommateurs.
Comment : Chaque démonstration doit être structurée, répétée et cadrée.
2 règles
Règle 1 : Elle ne se fait pas sur un environnement local. Elle se fait, à minima, sur un environnement intégré ! Faites vos vérifications le matin ou la veille au soir et, n’y touchez plus !
La préparation coûte du temps et c’est normal pour réussir l’atelier. 80% de préparation pour 20% de temps effectif de démonstration.
Si elle est trop chronophage notamment vis-à-vis des environnements, alors il y a un sujet de fond à travailler en rétrospective à une ou plusieurs équipes (CI/CD, règles d’usages, process etc.).
Règle 2 : Les scénarios ont été posés sur papier et répétés au moins une fois. Le jour J, c’est fluide : chacun sait ce qu’il fait, il n’y a pas d’effet démo par manque de données ou de service disponible ou de saisie du texte “toto” qui va générer une erreur car ce n’était pas la donnée attendu…
A défaut d’un pitch ultra clair, faites une slide simple par scénario : Titre + objectif parent + Contexte 😉
Règle 3 : Les scénarios remettent le public dans le contexte. Narrez le quotidien des bénéficiaires ou du processus métier présenté.
Cette partie n’a pas besoin d’être présentée mais doit être évoquée.
Un exemple de scénario
Démonstration d’exigence non fonctionnelle :
- Scénario : Réaliser un tir de performance Kafka en conditions “réelles”
- Contribuant à l’objectif d’incrément : “Améliorer le processus de recette afin d’ouvrir le service à des clients pilotes supplémentaires.”
- Contexte du scénario : Simulation d’une journée de match à enjeux importants dans des conditions de fonctionnement nominales du DataHub, à savoir :
- Le test reproduit une soirée de données provenant des stades durant le mondial (20h00 à 21h30)
- En environnement de pré-production, au plus proche possible de la production
- Le test simule la connexion simultanée de 50 000 parieurs
- Le test est joué en vitesse accélérée x8 pour que le DataHub reçoivent en 10 minutes l’ensemble des données reçues sur la période, pour recréer des conditions « extrêmes » de fonctionnement
Factualiser votre delivery
Vous êtes là pour inspecter votre produit et prendre des décisions sur le Product Backlog et la roadmap. Vous êtes sur un produit technologique, vous soulevez à présent le capot pour montrer en toute transparence (#piliers) la réalité de votre delivery.
Apportez un côté rationnel à l’effet Waouh de la démonstration avec 3 catégories d’indicateurs :
- La productivité ou l’efficacité
- La qualité logicielle
- Fiabilité de l’usine
En 4eme partie, ouvrez sur les dépendances et les risques.
1. La productivité ou l’efficacité
Dans quel but : L’entreprise mise sur votre équipe pour créer un produit ou un service et générer des bénéfices ou un gain opérationnel.
En tant qu’équipe agile, vous devez vous améliorer au fil du temps mais cela appartient plus à la rétrospective qu’à la revue de sprint. Ici vous présentez les données qui permettent de projeter la roadmap et indiquez les sujets pour lesquels vous avez besoin d’aide.
Comment : 5-7 minutes sur 1 slide incluant : 3 indicateurs maximum, votre courte analyse écrite et les éventuelles actions correctives en cours.
Vous choisissez les indicateurs les plus pertinents pour pouvoir se projeter (hint : Il n’y a pas que le burndownchart dans la vie d’un scrum master…).
Exemple : La vélocité seule n’apporte pas suffisamment d’informations, personnellement j’aime la coupler avec le coût du point et la prédictibilité. Vous pouvez creuser autour du focus factor, des temps de cycle de la recette ou de la conception aussi. Tout dépend de ce que vous jugez le plus pertinent à ce moment de votre histoire.
2. La qualité logicielle
Dans quel but : Sauf si vous faites un POC, votre produit doit être maintenable, robuste et évolutif. Gardez ces éléments aux yeux de tous et surtout auprès de ceux qui tiennent le business. C’est le moment idéal pour les acculturer à vos enjeux techniques ou la dette déjà présente. Si le produit ne tient pas la charge ou n’est pas évolutif, c’est leur image qui en pâtira.
Comment : 5 minutes avec 1 slide incluant 2 à 3 indicateurs. Votre but est de vulgariser et prendre connaissance de vos succès ou recommandations.
La définition de ces indicateurs viennent de 2 sources :
- Héritage : L’entreprise a des exigences qualités, vous en héritez, affichez-les. Votre DSI ou CTO est votre meilleur sponsor.
- Expertise : Les équipiers sont les sachants, ils sont experts du produit et des technologies utilisées. Faites leur choisir les 2 à 3 indicateurs à suivre.
Exemple : Présentez le portfolio SonarQube du produit ou directement la page du dépôt de code concerné avec les critères les plus pertinents (Reliability, Sécurité, Maintenabilité, vulnérabilités, code smells, duplications…).
Vous avez actuellement des enjeux de performance, peut-être, serait-il plus pertinent de montrer l’évolution des tirs de performance ? Pour un produit Data, serait-il plus utile de montrer le temps de mise à jour d’un dataset ? Enfin, vous avez un sujet autour de la maintenabilité, alors l’évolution de votre backlog de dette technique pourra être un de vos alliés facile à constituer avant de mettre en place un outil d’analyse. A la scrum team de décider !
Dans tous les cas, configurez vos outils et vérifiez les données avant de les présenter. Avec de mauvais indicateurs, l’assemblée prend de mauvaises décisions.
3. Fiabilité de l’usine
Dans quel but : A quoi bon réussir à livrer si vous dégradez la production ? La satisfaction des bénéficiaires, le chiffre d’affaires ou votre image en sera dégradée.
Comment : 5 à 10 minutes sur 1 slide d’indicateurs liés à la continuité de service. D’expérience, la durée varie en fonction des débats qu’il pourrait y avoir sur un incident.
Attention, à ce moment de la revue de sprint, vous présentez le passé et le présent basé sur des faits, ne laissez pas trop débattre maintenant.
Exemple : Vous pourriez choisir de présenter 3 indicateurs
- “Change failure rate” : Le taux de mises en production générant un incident ou un rollback
- Time to restore service : Le temps durant lequel vos bénéficiaires verront le problème.
- Evolution du stock d’incidents et tenue des SLA
4. Dépendances et risques
Dans un contexte d’agilité à l’échelle, la gestion des dépendances, des risques de programme et des grands livrables se feront plus souvent au trimestre. Gardez-les visibles.
Dans quel but : Évaluer le respect des dates de livraison des dépendances et l’état des risques afin d’adapter le plan avec le product manager ou l’équipe consommatrice.
Comment : En 10 minutes vous allez présenter le release plan avec les dates, périmètres et enjeux, les risques de l’équipe et leur état, les objectifs du trimestre et le burnup chart du trimestre.
Chapitre 2 : Place à l’adaptation
Vous avez présenté un bon nombre d’éléments, et avez eu des retours en live que vous avez notés pour introduire cette deuxième partie. Tout le monde ne sera pas nécessaire, vous pouvez en libérer certains.
Au regard de ce qui a été dit (productivité, qualité, fiabilité, roadmap et objectifs…), que faut-il adapter dans le Product Backlog pour atteindre les objectifs :
- Est-ce que le produit ou le service présenté répond aux attentes des bénéficiaires qui étaient présents ? Faut-il inclure des correctifs dans le product backlog ?
- Est-ce que la qualité actuelle offre un produit maintenable, robuste et évolutif ? Faut-il inclure de nouveaux éléments dans le product backlog tels que des NFR ? Faut-il améliorer notre usine ou mettre de nouvelles règles ?
- Avons-nous des sujets à mettre à l’ordre du jour de notre rétrospective ou un atelier spécifique à créer pour améliorer notre productivité ou notre continuité de service ? (En tant que bon scrum master ces sujets sont déjà identifiés et vous avez éventuellement conviés les bonnes personnes extérieures à l’équipe le cas échéant)
- Au rythme actuel, devons-nous modifier le plan pour atteindre les objectifs dans le respect des échéances ?
Si vous touchez au reste à faire avec ces premières questions. Vous aurez dans ce cas d’autres sujets à traiter :
- Comment respecter les dépendances attendues par les autres équipes ?
- La planification des démonstrations est-elle toujours bonne ? Devons-nous prévenir les invités du changement de programme ?
- Est-ce que la roadmap a besoin d’être actualisée et recommuniquée ?
Ce moment est clé dans la collaboration entre les différentes parties prenantes et doit avoir une place conséquente dans cet atelier de travail. Dans son animation, le Scrum Master se concentre sur la prise de décisions et utilise les rôles délégués pour tenir le temps, mettre à jour les supports et s’assurer qu’on ne diverge pas.
Conclusion
La revue de sprint est un atelier de prise de décisions visant à dérisquer le produit et sa roadmap dans lequel les personnes conviées dépendent du livrable et des arbitrages souhaités.
D’ailleurs dans la version 2020 du Scrum Guide on peut y lire :
“La Sprint Review est une session de travail et la Scrum Team doit éviter de la limiter à une session de présentation.”
Nous y présentons le produit dans son ensemble, le fonctionnel comme l’efficacité de l’équipe et la qualité livrée. C’est un excellent moyen pour sensibiliser le public aux difficultés, enjeux ou recommandations de l’équipe. C’est le moment idéal pour faire parler ceux qui savent : les développeurs pour le réalisation, les bénéficiaires pour faire les meilleurs choix.
A la fin du fin, le but est de savoir si le produit tiendra la route, et à quelle date il sortira. Grâce aux informations des différentes équipes, le Product Manager (ou Owner selon le contexte) pourra faire une roadmap consolidée et s’engager auprès de sa direction en toute connaissance de cause et organiser son plan de déploiement et de communication du produit final. L’équipe ne subit plus les roadmaps pressurisées car elle évoque au plus tôt tous les sujets.
Nelson
Nelson commence sa carrière en tant que développeur puis rejoint Xebia en 2016 pour réaliser des produits data et digitaux.
Durant sa carrière, Nelson intervient dans des entreprises telles que BNP, Galeries lafayette, Société Générale, Orange jusqu’à assumer la direction de l’ingénierie d’une partie du PMU.
Ses 10 ans d’expérience et son rôle de Release Train Engineer de 14 équipes, lui ont confirmé l’importance de garder au coeur des préoccupations et à tout niveau de l’entreprise : la qualité logicielle, la mesure (Efficience, Qualité, Produit et Compétence) et le release management.
C’est ainsi qu’il décide de rejoindre le collectif KōKan pour créer le pure player en delivery management regroupant des consultants experts (coach, scrum master et RTE) sur Paris et Rennes.
Publié le 23 avril 2024
