En plus d’un certain nombre d’artefacts, Scrum s’accompagne de cérémonies notamment le célèbre stand-up meeting ainsi que la sprint review. Elles s’achèvent par la démonstration ce qui a été développé. Savoir tenir correctement ces points de rendez-vous Scrum et les exécuter convenablement sont là aussi essentiels. Après avoir abordé dans le second épisode les erreurs rencontrées lors de la rédaction des user stories, aujourd’hui nous allons voir les erreurs à ne pas commettre lors des cérémonies agiles.
Daily Scrum ou stand up meeting
Le stand-up meeting est la cérémonie la plus fréquente et la plus caractéristique de Scrum. Elle peut être entachée de nombreuses erreurs ou mauvaises pratiques présentées ici dans le tableau suivant :
Concernant le stand-up meeting, il faut garder à l’esprit que cette cérémonie est supposée mettre tous ses participants au même niveau d’information. A cette occasion, ce qui est communiqué s’adresse à toute l’équipe et pas uniquement au SM. L’un des principes de Scrum est qu’il n’y a plus de chef de projet, toute l’équipe est responsable de ses engagements. Le SM intervient en tant que facilitateur et fait en sorte que les processus se déroulent bien. Et que les différents rôles s’exercent dans leur domaine sans empiéter sur ceux des autres (exemple : un PO ne doit pas intervenir au cours d’un sprint pour ajouter une fonctionnalité au sprint back log ou en reprioriser une autre). Le SM doit garder à l’esprit ces bonnes pratiques et les appliquer afin que l’implémentation de l’agilité soit améliorée.
Importance de la « démonstration»
La démonstration ne doit pas être négligée car elle permet de valider si la fonctionnalité est conforme et permet de bénéficier des retours du PO. La démonstration permet aussi parfois de mettre en lumière certains points de désaccord ou de mauvaise compréhension, points qui n’apparaissent pas de prime abord. De plus, sans le retour utilisateur explicite et sa validation, il se produit un effet de transfert des responsabilités qui fait en quelque sorte peser les risques de dysfonctionnement applicatif sur l’équipe de développement alors que cela ne devrait pas être le cas.
Démonstration trop longue à préparer
Les premières démonstrations bénéficient toujours d’une attention particulière et d’un intérêt accru, liés à la livraison des premières fonctionnalités et à l’enthousiasme qui peut découler de ces avancées en début de projet. Cette forte attention permet à l’équipe de développement de consacrer un temps conséquent au vu de la durée du sprint.
Problématique engendrée
Une démonstration trop longue à préparer peut avoir un impact sur les engagements pris en termes de livrable sur sprint en cours.
Recommandation
La démonstration ne doit pas nécessiter un temps de préparation trop important qui déborde sur les US du sprint à finaliser. De plus, son temps doit être comptabilisé et estimé lors du sprint planning afin de limiter les risques de débordement.
Démonstration bâclée, expédiée
Par la suite, il peut arriver que l’intérêt des démonstrations s’en trouve amoindri et émoussé au fil des sprint reviews. Cela peut résulter d’une préparation moindre ou d’une implication moins importante des parties prenantes, notamment de la part du product owner.
Une démonstration peut être bâclée par les deux parties : soit par le PO en y assistant de manière superficielle ou « symbolique », soit par l’équipe de développement en y consacrant trop peu de temps pour tenir les délais et en ne démontrant que des aspects triviaux des US occultant ainsi les aspects complexes de certaines fonctionnalités.
En effet, une démonstration n’est pas toujours « digeste » à suivre pour le PO car pas forcément « visuelle » et souvent technique. Ainsi pour l’équipe de développement, elle peut être fastidieuse tant dans la préparation que dans le déroulement (les environnements de tests ou les outils à disposition pouvant être indisponibles car moins vitaux comparés à ceux de la production). La démonstration n’est pas un test à proprement parler, mais l’effectuer correctement est primordial car c’est souvent l’occasion de confronter ce qui était attendu avec ce qui a été développé.
Recommandation
Pour ne pas tomber dans la démonstration de cas trop triviaux, à faible valeur ajoutée, une manière de procéder peut être de demander en amont aux utilisateurs et au PO, les points qu’ils souhaitent voir en démonstration. Cela permettra aux testeurs de les exposer en se focalisant ainsi sur ce qui importe vraiment. La démonstration n’en sera que plus concise et efficace, évitant ainsi le piège de la dispersion et donc du caractère peu profond et utile de celle-ci.
