Une approche pragmatique de Scrum

Je suis tombé récemment sur cet article : Scrum, what is it good for? d’Hannah Kane. En plus d’être fun (on y découvre l’existence d’un site permettant aux couples d’implémenter Scrum dans l’organisation de leur mariage), ce papier très bien rédigé m’a fait réaliser que nous n’avions jamais parlé de Scrum. C’est aujourd’hui chose faite.

Section intitulée une-approche-pragmatique-de-scrumUne approche pragmatique de Scrum

Chez JoliCode, nous avons fait le choix d’utiliser Scrum pour nous aider à produire des projets Web de manière responsable et mesurée. Nous appliquons cette méthode en l’envisageant comme une boîte à outils : en venant y piocher seulement les éléments (artefacts et événements) qui nous semblent nécessaires pour apporter une certaine discipline à notre équipe et assurer une bonne mise en place des pratiques modernes du développement. Nous pensons qu’avancer avec cet « esprit » agile est le meilleur moyen d’apprendre et de travailler avec enthousiasme.

Je pense que Scrum n’est pas une réponse à tous les maux, mais son usage continue d’apporter des résultats pertinents et intéressants à observer. Comme Hannah, ce sujet continue donc de me passionner et c’est pourquoi j’adore échanger à ce sujet.

Par où commencer ? Je souhaite débuter cet article en vous présentant les guidelines que nous utilisons afin de mener au mieux nos projets :

Le planning meeting : Longue réunion au début du projet puis, de manière ponctuelle selon l’évolution du projet. Notre objectif : Prioriser la liste des fonctionnalités pour permettre à l’équipe de développer ce qui apporte le plus de valeur au projet.

Le sprint planning meeting : Réunion avant chaque début de sprint. Notre objectif : Définir le périmètre du sprint qui arrive en respectant la vélocité du sprint précédent.

Daily-meeting : Tous les jours, à heure fixe et avec durée maximale stricte (10 min). Notre objectif : Avoir une communication efficace et responsabiliser tous les membres de l’équipe sur les tâches qui seront menées dans la journée.

Review de sprint : Réunion après chaque fin de sprint. Notre objectif : Voir si les engagements ont été maintenus, discuter des difficultés rencontrées, monitorer le projet en estimant la vélocité de l’équipe sur la période.

Grooming session : Réunions ponctuelles organisées avec l’ensemble des acteurs Notre objectif : Affiner le backlog pour anticiper les problèmes comme le manque de priorisations ou le manque de clarté sur certaines user stories.

Vers la fin de projet, il nous arrive d’arrêter Scrum au profit de Kanban, lorsque les tâches s’orientent majoritairement sur une gestion des tickets d’incidents, résolution de bug, SAV, etc)

Section intitulée retour-et-ressenti-de-l-equipeRetour et ressenti de l’équipe

Section intitulée benefices-rencontresBénéfices rencontrés

Moins de stress, avec une mise en production stable à chaque sprint

À la fin de chaque sprint, nous avons pour habitude de procéder à une mise en production intermédiaire sur le serveur de pré-production. Ainsi, tout au long du projet, une version stable de l’application est disponible pour le client à des fins de tests. Évidemment, la couverture fonctionnelle peut être faible en début de projet, mais au gré des sprints, elle s’est étoffée progressivement, et permet rapidement de mener des actions de sensibilisation/formation, de tester les développements livrés, et de ne pas attendre la fin du projet pour tout tester d’un coup. Toutefois, nous conseillons de faire cette mise en pré-production le matin pour pouvoir réagir rapidement sur les derniers retours.

Une plus grande facilité pour estimer et planifier les tâches du projet de manière générale

Suivre la méthodologie au quotidien nous a permis de développer une certaine routine bénéfique au projet. Un suivi régulier des métriques et des réunions récurrentes nous ont permis de faciliter les exercices d’estimation et de planification sur le long terme. À savoir, GitHub propose un système de tickets puissant, mais dont l’interface graphique est parfois jugée simpliste. Nous préconisons l’emploi de la surcouche Waffle ou ZenHub, qui permet d’organiser de manière visuelle les retours de bugs et les tickets afin de gagner en lisibilité sous la forme d’une board Kanban.

Une meilleure capacité à gérer les changements de priorité

Même si le cahier des charges devient variable et dynamique avec Scrum, nous sommes plus confiants sur les projets qui fonctionnent en suivant cette méthodologie et c’est normal : le fonctionnement en découpage par Sprint nous permet de réagir rapidement sur les urgences sans mettre en danger le projet dans son ensemble.

C’est un moyen permettant de transmettre à l’équipe la vision projet

Avec Scrum, la proximité avec le product owner est garantie. Les échanges sont ainsi fluidifiés et permettent aux développeurs de comprendre, d’anticiper et de se familiariser avec la vision court terme et encore plus important, la vision long terme du projet. Un avantage qui permettra au final de mieux gérer sa dette technique.

Section intitulée points-de-vigilancesPoints de vigilances :

La pêche aux informations

La plupart des éléments à produire nécessitent souvent une collecte d’informations auprès du product owner, qui devra dans les plannings définis, répondre aux besoins des développeurs (collecte du code, informations bases de données, accès aux instances de tests éventuels etc…) Or, il arrive parfois que certains éléments manquent, sans que vous ne puissiez le prévoir à temps. Dans votre application de Scrum, faites attention à ce point, afin de ne pas vous retrouver dans une position délicate.

La gestion de tickets trop volumineux

S’il vous arrive sur des sprints de vous apercevoir au dernier moment que certains tickets sont sous-évalués, c’est que le travail de découpage n’a pas été correctement effectué. Pour pallier à cela, le meilleur moyen est de suivre minutieusement la règle INVEST (Independant, Negociable, Valuable, Estimable, Small, Testable) : chaque représentation d’une feature (user story) doit respecter cette règle. Par expérience, nous préconisons également d’éviter d’avoir des tickets avec un nombre de jour estimé supérieur à 4 jours. La gestion de tickets trop volumineux entraîne habituellement des reliquats sur les semaines suivantes, difficile à gérer par la suite, soyez donc vigilant sur ce point.

Le débordement en temps sur les réunions d’équipe

Que ce soit pour les points quotidiens ou les reviews de sprint, il peut être difficile pour l’équipe de respecter les délais convenus lors du kick-off, ce problème fausse souvent les statistiques du projet, il convient de bien monitorer ces temps forts.

Section intitulée conclusionConclusion

Ce que j’apprécie particulièrement en utilisant Scrum chez JoliCode, c’est que cela nous permet de commencer un projet en partageant une définition commune des rôles et objectifs de chacun, et mine de rien, c’est déjà un pas de géant. Ainsi, on peut retrouver 3 piliers :

L’équipe projet : Doit être inférieure à 5 personnes (sinon complexe à gérer) / Auto-organisée / Capable de livrer une feature complète

Scrum master : Retirer les blocages / gérer l’esprit agile / faciliter la communication

Product Owner : Parle au nom du client / Le seul ayant l’autorité de trancher (ownership backlog) / partage la vision du product backlog dans le CT, MT et LT.

Scrum se découvre par l’expérience. Je vous invite à découvrir cette méthodologie par vous-même, et aussi à jouer avec d’autres schémas d’organisation comme a pu le faire l’équipe d’Évaneos par exemple. L’objectif ? Trouver par tâtonnement un workflow qui correspond à votre équipe.

Un dernier point que je souhaite partager sur Scrum

L’implication du client est primordiale dans le projet. Dès le premier rendez-vous, nous consacrons du temps pour exposer notre manière d’opérer et pour sensibiliser le client sur ses futures responsabilités. Même si cela prend du temps, nous pensons que cela reste l’un des meilleurs moyens de construire une relation saine avec un client. Si vous souhaitez aller plus loin sur ce point, je vous invite à consulter l’article de Thibault Jouannic, car, parler agile avec son équipe c’est bien, mais avec un client, c’est une autre paire de manches !

Bon courage.