La revue de sprint n’est pas une démonstration !

La revue de sprint est l’un des 5 événements de SCRUM. Chacun en a sa compréhension et son implémentation. Des équipes font juste des démonstrations. D’autres choisissent de ne pas du tout en faire. Et pour finir il y a ceux qui, au fil du temps, ont vu ce moment se transformer en une réunion de reporting. 

Elle est pourtant bien plus stratégique qu’une simple observation de l’artefact déployé ou une revue d’indicateurs. Si vous la faites pour faire plaisir à un manager ou pour suivre la méthode, vous vous plantez…

Pourquoi faisons-nous cette revue ?

Mais avons-nous réellement compris l’angle avec lequel doit être prise la revue ? 

L’avons-nous suffisamment bien expliqué aux équipes et aux managers ? 

Ou serions-nous restés sur : “Parce que Scrum le dit, à chaque sprint, il faut présenter aux utilisateurs finaux ce que nous avons réalisé pour avoir du feedback” ? 

Dans ce cas, 2 remarques : 

1. Plus que les utilisateurs finaux, il est préférable de viser ceux qui vont réellement bénéficier des livrables. Ex : l’équipe qui livre des API Backends for Frontends devrait plutôt faire une démonstration aux équipes fronts qu’aux métiers, managers ou utilisateurs finaux ;
2. Parfois (et non “souvent”), il n’y aura pas de fonctionnalités à chaque sprint et c’est ok. Il ne sert à rien d’être dogmatique. Profitez-en plutôt pour transformer l’objectif de cette session afin d’apporter plus de valeur. Exemples :
   1. prendre le temps de présenter en détail vos indicateurs votre roadmap;
   2. ou simplement vulgariser des sujets business ou techniques pour obtenir une compréhension commune. 

Comment aborder la revue de sprint ?

Deux mots pour entrer dans le sujet : Inspection et Adaptation

Respectivement deuxième et troisième piliers de Scrum, ils ne sont possibles que si le premier, à savoir la Transparence, est présent. 

Lorsqu’on s’intéresse à Scrum, fréquemment on parle du 353 : 3 rôles, 5 cérémonies événements et 3 artefacts. Pourtant ce n’est que la face visible de l’iceberg. Sans comprendre les valeurs et les piliers, ces événements vont logiquement perdre leur intérêt. 

La revue de sprint est un atelier de travail visant à inspecter :

• l’incrément du produit livré,
• le sprint
• et le Product Backlog associé.

L’idée est d’en cerner son fonctionnement, son état d’avancement et sa projection aussi bien fonctionnelle, temporelle que technique. Devons-nous rappeler que cet atelier de travail n’est pas une réunion où seule l’équipe présente ?

Selon les résultats, cet atelier de travail doit aussi permettre d’imaginer collectivement des options permettant de répondre à des exigences, respecter la date ou de redresser la barre dans un domaine souvent oublié : la fiabilité et la maintenabilité des solutions développées. Les décisions ou actions liées aux options imaginées sont prises ensemble durant l’atelier. De cette manière, face au principe de réalité que le delivery va affronter, l’équipe n’est plus dans une relation de quasi client fournisseur, les deux “camps” collaborent. 

Élément important, nous devons répondre ou atteindre des exigences et non des solutions. Les solutions (techniques, graphiques, de processus métier ou autres) sont les options possibles pour répondre aux exigences afin d’atteindre les enjeux visés. Si la solution est figée, alors il n’est plus envisageable de proposer des options alternatives au fil du delivery et des découvertes. L’équipe en devient déresponsabilisée… 

Ce qu’il faut garder en tête

C’est en travaillant la confiance à l’intérieur et avec l’extérieur de l’équipe que la transparence devient possible. Et cela touche nos succès, problèmes et notre data. 

Chaque événement Scrum est un moment privilégié pour exposer les sujets en transparence. Et alors, nous pouvons inspecter certains éléments et en adapter d’autres. 

La revue de sprint permet d’inspecter l’incrément, le Sprint et le Product Backlog pour adapter le Product Backlog et la roadmap associée. 

Il est primordial d’analyser la productivité, la qualité technique et la fiabilité de notre usine pour déterminer notre réelle capacité à faire et les impacts sur la roadmap.

Au-delà de cette adaptation, la revue est un excellent moment pour favoriser la transparence. Elle permet de communiquer, fédérer et acculturer des populations non techniques à ce qui compose un produit technologique. A ce titre, je vous parlerai dans un prochain article des éléments à présenter dans une revue.

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.