L’agilité Scrum au sein des start-up e-commerce : retours terrain

Episode 2 — Les événements Scrum

Dans ce nouvel épisode, nous abordons la mise en place des événements Scrum dans une start-up agile.

Les événements Scrum

La bonne mise en place des événements Scrum est importante car ils instaurent le rythme de travail. Voici quelques erreurs à éviter lors de ces événement.

Daily Scrum, l’exercice de synthèse

Le Scrum Guide préconise un maximum de 15 min allouées à cette cérémonie. Sur une équipe moyenne de 7 personnes, cela ne laisse que 2 min par personne pour s’exprimer, c’est court! Il va donc falloir apprendre à chacun à transmettre les bonnes informations pour répondre à trois questions principales:

• Qu’est ce que j’ai fait hier?
• Qu’est ce que je vais faire aujourd’hui?
• Ai-je identifié des obstacles pour atteindre le sprint goal?

Pour éviter de dépasser le temps, mettez en place ces astuces:

• Reporter les discussions après la cérémonie
• Avoir un time keeper (le Scrum Master peut assurer ce rôle)
• Demander aux membres de l’équipe de préparer rapidement la cérémonie

Même si le Scrum Guide déconseille la présence du PO, il est quand même intéressant qu’il y participe surtout s’il est nouveau dans l’équipe. C’est aussi un bon moyen pour lui de prendre la température du sprint au jour le jour.

Enfin, le daily Scrum est parfois appelé Stand up daily scrum. Comme son nom l’indique, c’est une réunion où les individus sont debout. Cela favorise la motivation et le dynamisme de la réunion. Pour réaliser un stand up daily meeting, mettez vous en rond et éloignez vous de tout élément qui pourrait servir de support (mur, chaise, table). De fait, les collaborateurs seront plus concis dans leur explication afin de regagner rapidement leur chaise!

Sprint Planning, comment préparer le sprint suivant

Le sprint planning est une cérémonie qui réunit la Scrum Team. L’objectif est de choisir les incréments à livrer dans le prochain sprint, et de planifier la manière pour atteindre l’objectif du sprint. Afin que le sprint planning se déroule dans les meilleures conditions il est nécessaire que les éléments suivants soient réunis:

• Les user stories répondent à la DoR (Definition of ready)
• Les développeurs ont préalablement pris connaissance des user stories
• La capacité de l’équipe est calculée

Lorsque l’ensemble des user stories sont sélectionnées, la Scrum Team détermine un sprint goal. Il s’agit de l’objectif à atteindre par l’équipe Scrum à l’issue du sprint. Tous les membres doivent être en adhésion avec cet objectif.

Un des obstacles rencontrés est l’abondance de user stories “prioritaires” à délivrer ou a contrario un manque de user stories.

Dans le premier cas, pas de problème, il s’agira pour le Product Owner de prioriser en fonction de la business value les fonctionnalités. Il n’aura pas de problème à expliquer aux stakeholders que le nombre de fonctionnalités dépasse la capacité de l’équipe même si ceux-ci annoncent une fonctionnalité “Mandatory”. Il faut toujours avoir en tête que c’est bien le Product Owner qui est le responsable du produit et c’est à lui que revient la décision d’embarquer telle ou telle fonctionnalité dans un sprint.

Dans le second cas, c’est de la responsabilité du Product Owner de délivrer des user stories complètes à l’équipe de développement. S’il n’arrive pas à alimenter correctement son équipe, c’est souvent par manque de temps (cas du multi-casquettes, CF E01). Il faudra alors que le Product Owner en discute avec le Scrum Master afin qu’ils puissent identifier des solutions ensemble pour endiguer le problème. Cela peut passer par une délégation de tâches annexes, une réorganisation du travail, ou une formation. Il faudra dans tous les cas que le Product Owner recentre son activité sur l’établissement des user stories en priorité.

Sprint Review, l’heure de la démo

La sprint review est le moment ou l’équipe Scrum et les stakeholders sont réunis afin d’inspecter les incréments livrés pendant le sprint. L’équipe Scrum effectue une démonstration des nouveaux éléments et interagit avec les stakeholders. A l’issue de la démo, il est tout à fait possible que des améliorations futures soient identifiées. Pour l’entreprise, cela peut être un des rares moments où les métiers et les équipes de développement sont réunis. Il est très important d’en tirer le meilleur parti, garder en tête qu’il s’agit de deux mondes totalement différents qui se rencontrent.

Pour l’équipe Scrum, c’est un bon moment pour propager la bonne parole sur la méthode Agile Scrum et valoriser le travail de l’équipe Scrum.

Que faire pour éviter un fail de la démo ?

Il n’y a pas de secret, pour limiter “l’effet démo”, il faut préparer la démonstration en condition réelle. Il s’agit d’un investissement payant, une démo réussie aura un effet très positif sur la perception des équipes IT par les métiers.

Sprint Retrospective, une réunion d’équipe ludique

Le Sprint Retrospective à pour objectif d’identifier les points positifs et négatifs du sprint passé ainsi que les points d’amélioration. C’est un événement de transparence entre les différents membres de l’équipe Scrum. D’une durée générale de 2 heures (pour des sprint de 2 semaines), l’ensemble de l’équipe scrum doit y participer. Pour permettre aux collaborateurs d’exprimer plus facilement leurs sentiments à propos de l’équipe, il est nécessaire d’utiliser des serious game. Par exemple, le Speed Boat est un bon outil de facilitation pour l’expression des individus. Le Speed Boat met en scène un paysage où divers éléments sont associés à des constantes. Chaque membre de l’équipe est invité à positionner son ressenti sur les constantes projet suivantes:

• la vision; le but du sprint: Est-il clair? A-t-il été atteint?
• le vent; ce qui pousse l’équipe: Les éléments qui améliorent la productivité, la motivation, les conditions de travail….
• l’encre; ce qui retient l’équipe: Les éléments qui freinent la productivité, la motivation…
• le rocher; les risques identifiés: Les risques projet à venir

Lorsque les freins et risques projet sont identifiés, il est nécessaire de leur associer une solution par une action qui devra être accomplie par un ou plusieurs membres de l’équipe.

Afin d’éviter la monotonie du Sprint restrospective, ou de l’ensemble des cérémonies, le Scrum Master peut changer le format. Cela permet d’amener de la nouveauté et de découvrir la méthode la plus adaptée à son équipe.

Le site coach agile propose un large panel de serious game classés en fonction de thématiques : Ice breaker, Pour apprendre, Pour construire, Pour s’améliorer.

Pour plus d’information, rendez-vous sur ce lien -> https://coach-agile.com/serious-game-le-recueil/ .

Grooming, spécification des User Stories

Les réunions de grooming ne sont théoriquement pas des cérémonies Scrum, cependant elles font partie intégrante du processus Scrum. Il s’agit en réalité du Product Backlog Refinement. Les réunions de grooming rassemblent l’équipe Scrum pour une durée de 1 à 2 heures maximum. L’objectif est de spécifier les user stories avec les développeurs et d’évaluer la complexité.

Pour qu’une séance de grooming se déroule bien, le PO devra au préalable écrire la user story de la manière la plus claire possible. Pour cela, il est intéressant de mettre en place une DoR (definition of ready), qui permet de mettre toute l’équipe Scrum en adéquation avec le format des stories. Cela permettra d’éviter les frustrations de type “c’est pas clair”, “il manque des informations” de la part des développeurs. Vous pouvez par exemple suivre le format suivant :

• Besoin métier & business: décrire le besoin initial émanant du métier et la plue-value pour l’utilisateur finale (pourquoi cette fonctionnalité est nécessaire au business)
• Besoin fonctionnel: spécification fonctionnelle pour répondre au besoin business et métier
• Besoin technique: spécification technique pour répondre au besoin business et métier / fonctionnel
• Microservices / Briques SI impactées: permet au développeur d’identifier simplement quels microservices/briques sont impactées par la fonctionnalités
• Dépendances et services externes: Identifier toutes les briques qui seront impactées
• Test cases: Ils s’agit des cas de tests a effectuer pour tester le bon fonctionnement de la fonctionnalité.

Pour évaluer la complexité en point, le poker planning est la méthode la plus répandue. Il vous faudra un jeu de carte et sélectionner la suite de fibonacci (0, 1, 1, 2, 3, 5, 8, 13, 21, etc).

En générale, si une estimation dépasse 13 points, cela signifie que la demande est soit trop complexe soit trop vague. Dans ce cas le PO devra découper la user story ou déclarer une investigation pour étayer le domaine de la user story.

Une des limites liée au poker planning est la relativité de l’estimation. En effet, comment peut on évaluer le degré de complexité en fonction des individus? Une complexité à 3 points pour un individu A correspond peut-être à une complexité évaluée à 5 pour l’individu B. Pour éviter cet effet de bord, vous pouvez mettre en place une définition d’échelle de complexité. On pourrait par exemple mettre l’échelle suivante :

• 1- Pas de développement, uniquement la modification d’un paramètre déjà existant
• 2- Développement d’un nouveau paramètre dans un endpoint existant
• 3- Création d’un nouvel endpoint et paramétrage

Pour déterminer la complexité d’une user story, l’équipe de développement doit trouver un consensus. Pour cela, ils voteront en même temps. Tous les individus qui ne sont pas dans la moyenne totale de la complexité votée doivent argumenter leur choix. Ensuite, un nouveau vote est établie pour arriver à un consensus. Enfin, n’hésitez pas à timeboxer les échanges, en général pas plus de 15min par user story.

C’est ainsi que s’achève cette mini-série sur l’application de la méthode Agile Scrum au sein d’une start-up. J’espère que vous aurez trouvé quelques clés afin de débloquer des situations. Dans tous les cas, n’hésitez pas à commenter cet article si vous avez des retours constructifs à partager :)

A très vite et bon projet !