Participer aux événements Scrum

Introduction

Ce dernier chapitre n’est pas destiné à apprendre ou comprendre Scrum, mais à contribuer efficacement aux évènements Scrum au sein de la Scrum Team, en tant que Product Owner.

Le Sprint planning

Cet évènement se décompose en trois thèmes (Why, What, How) et la présence du Product Owner est obligatoire.

1. Le thème Why

C’est toute la Scrum Team qui définit l’objectif du Sprint et pas uniquement le Product Owner. En revanche, l’impulsion initiale, l’orientation donnée au Sprint provient du Product Owner car c’est la seule personne de l’équipe qui est responsable de la vision du produit.

Si le Product Owner décide que c’est le bon moment pour accroître la qualité du produit, alors cette orientation a peu de chance d’être négociable.

Ce qui est négociable, et ce sur quoi le reste de la Scrum Team dispose d’une forte marge de manœuvre, c’est l’ampleur potentielle de l’accroissement de la qualité. Cette ampleur dépend de la capacité des Developers et de leur perception de l’état actuel du produit.

a. Marie alerte sur la définition de « Fini »

La Scrum Team dans laquelle Marie travaille a décidé que SonarQube serait un indicateur majeur de sa définition de « Fini ». Chaque incrément doit respecter entre autres, les contraintes suivantes :

Ne pas dépasser 7 jours de dette technique.
Avoir une couverture des tests unitaires d’au moins 40 %.
Ne pas avoir plus de 10 % de duplication de code.
Ne pas avoir un score de sécurité inférieur à B.
N’avoir aucune anomalie bloquante et pas plus de trente anomalies au total.

Depuis plusieurs Sprint, la Scrum Team constate qu’elle se rapproche progressivement des limites de sa définition de « Fini ». Les anomalies s’accroissent ainsi que la dette technique. D’un autre côté, les utilisateurs peinent à s’approprier pleinement les nouvelles fonctionnalités mises à leur disposition.

Dans un flux poussé, l’équipe aurait suivi son plan initial et aurait commencé à développer de nouveaux services. Mais dans un flux tiré, de nouvelles fonctionnalités ne sont développées que si les utilisateurs en ont réellement besoin et ont déjà assimilé les précédentes. Ce n’est...

Le Daily Scrum

Durant de nombreuses années, il était clair que le Product Owner n’avait aucune raison valable de participer à cet évènement. Il devait potentiellement être disponible pour pouvoir échanger avec l’équipe, mais n’avait pas d’autre valeur ajoutée.

Si le Product Owner avait des activités permettant de produire une partie de l’incrément de produit, alors il pouvait participer à cet évènement. Mais c’était le seul cas de figure admis. Concrètement, si le Product Owner était également Developer, alors il avait sa place au Daily Scrum, sinon ce n’était pas utile qu’il y participe.

Pourtant, en tant que membre de la Scrum Team, le Product Owner pourrait parfaitement participer au Daily Scrum, afin de donner de la visibilité sur ses activités aux autres membres de la Scrum Team. Cela renforce la cohésion de la Scrum Team et accroît la transparence (pilier de Scrum). En revanche, le fait de participer à cet évènement peut également provoquer une confusion au sein de la Scrum Team. En effet, durant le Sprint, l’activité du Product Owner ne consiste pas à accroître la valeur de l’incrément, mais à préparer les Sprints suivants. Il rencontre les parties prenantes, affine les éléments...

La revue de Sprint

De la même manière que la revue de Sprint est organisée autour de différents thèmes, chacun pouvant donner lieu à une réunion spécifique, la revue de Sprint peut être organisée en diverses réunions. Cet évènement doit permettre d’aborder deux sujets :

Faire le point sur le Sprint en cours et inspecter l’incrément livré par la Scrum Team.
Faire de la prospective par rapport à l’évolution de l’incrément, du Backlog de produit et du marché.

Concrètement, la revue de Sprint peut se substituer aux historiques comités de pilotage ou de direction de projet. Cet évènement est destiné à donner de la transparence sur les Artefacts Scrum et particulièrement sur le Backlog de produit ainsi que sur l’incrément.

1. Les bonnes pratiques

Cet évènement peut être organisé en au moins deux réunions. Une première réservée à la Scrum Team, afin d’inspecter le Backlog de produit et l’incrément. Lors de cette réunion, la Scrum Team s’assure que l’incrément est réellement « Fini », que tous les éléments du Backlog de Sprint le sont également, que l’objectif est atteint, ou pas, que l’amélioration de processus a bien été mise en œuvre, et enfin l’équipe fait le point sur l’écart entre ce qu’elle avait planifié et ce qu’elle a réellement réalisé.

a. La revue de la Scrum Team

A minima, l’équipe peut mesurer le nombre d’éléments qu’elle s’était engagée à livrer pour atteindre l’objectif du Sprint et ce qui est réellement livré, conforme à sa définition de « Fini ». Mais elle peut également mesurer la complexité initialement estimée et la complexité réellement produite. Enfin, elle peut mesurer le nombre de tâches non planifiées mais qu’elle a dû réaliser durant le Sprint.

Ces mesures n’ont pas pour objectif de désigner un coupable ni un sauveur, mais permettent de mieux planifier...

La rétrospective de Sprint

Si le Product Owner a une lourde responsabilité dans la bonne conduite de la revue de Sprint, il participe à la rétrospective en tant que simple membre de la Scrum Team, au même titre que chaque Developer. Son avis n’a pas plus de poids ou de force que celui des autres. Avec des équipes matures, cet évènement n’a pas besoin d’animateur ou de leader. Dans un premier temps, c’est généralement le Scrum Master qui joue un rôle de facilitateur, s’assurant que chacun puisse prendre la parole.

Le Product Owner a un intérêt personnel à ce que les processus pouvant potentiellement accroître le plus possible la capacité de l’équipe à délivrer de la valeur soient traités en priorité.

Plus l’objectif du produit et la manière d’en mesurer la valeur sont clairs, et plus l’équipe pourra progresser rapidement. Du point de vue du Product Owner, les tous premiers processus à améliorer sont ceux qui permettent de rendre clairs et transparents les indicateurs de valeur ainsi que les objectifs du produit.

Tant qu’il n’a pas l’assurance que ces éléments sont parfaitement clairs, le Product Owner n’a aucun intérêt à ce que d’autres processus soient améliorés en priorité....