Connaissez-vous le Lego4Scrum ?

écrit par Alexis publié le mercredi 13 juin 2018

Pour approfondir nos connaissances des méthodes agiles, et notamment Scrum, nous avons eu le plaisir d'accueillir Alfred Almendra, formateur et coach agile, le temps d'une soirée. Nous étions 12 salariés d'Apollo SSC à se prêter au jeu du fameux Lego4Scrum.

Contexte concret des "tickets"

Après une petite présentation générale de la méthodologie scrum, nous nous sommes mis directement au travail. L'objectif ? Proposer, en une heure, une maquette de club-village (mixte entre un club med et un village vacances) pour le compte d'une mairie fictive.

Phase de préparation de la méthode Scrum

Classement par complexité relative et estimation de la charge relative par ticket

Avant le travail effectif, une phase de préparation était nécessaire. Alfred, en qualité de Product Owner (représentant du compte client), nous a fourni une première liste d'éléments (23) à construire sur la maquette avec une valeur métier pour le client. Suite à cette présentation, nous avons pris 3 minutes pour les classer suivant la complexité apparente de chaque ticket. Suite à ce classement, Alfred, avec sa nouvelle casquette de ScrumMaster (animateur de l'équipe), nous a accompagné pour estimer la charge relative de chaque ticket suivant la vision de l'équipe.

Grâce à cet effort collectif, nous avons pu organiser les tickets suivant deux axes : la valeur cliente sur l'axe des abscisses et la charge relative estimée par l'équipe sur l'axe des ordonnées. Ce qui nous donne la figure suivante : Classement des tickets sur l'axe valeur cliente/charge pour l'équipe

Classement des tickets sur l'axe valeur cliente/charge pour l'équipe

Ouvrant une parenthèse, Alfred nous présente la théorie d'analyse sur cette figure grâce à un petit schéma très simple : Schéma Théorique des tickets valeur cliente/charge relative équipe

Schéma Théorique des tickets valeur cliente/charge relative équipe

Cette analyse simple nous permet de classer les tickets en 4 catégories :

  1. R.O.I : Ce sont les tickets ayant la plus forte rentabilité dans le projet. Ces tickets sont apparemment facile à faire et apporte une vraie plus-value pour le client. Nous calculerons la valeur de Retour sur Investissement pour chaque ticket par la suite.
  2. Risque : Ces tickets sont définis avec une forte valeur cliente mais qui demande une grosse charge (effort) pour l'équipe. Ce sont des tickets qui représentent un risque pour le bien être du projet. Pour limiter le risque, une des solutions serait de prendre ces tickets et de les retravailler (découper, mieux définir leur périmètre...) afin de les reclasser dans d'autres catégories en réévaluant leur valeur cliente et l'effort estimé.
  3. Bonus : Cette troisième catégorie regroupe les fonctionnalités faciles mais représentant une petite valeur pour le client. Ces tickets seront piochés durant des sprints (cycle court de développement) si l'équipe a du temps pour les faire.
  4. Reliquats : Enfin, cette dernière catégorie représente les tickets ayant une faible valeur cliente et sont estimés, par l'équipe, comme compliqués à mettre en place. Deux actions sont envisageables pour les gérer : un atelier de réflexion créatif pour changer la mise en oeuvre du besoin et rendre le ticket plus simple à faire et ayant une vraie valeur pour le client ou le supprimer.

Calcul du R.O.I.

Suite à cette meilleure compréhension et approche des éléments attendus dans notre maquette, nous avons calculé le R.O.I (Retour sur Investissement) de chaque ticket grâce à la fameuse formule :

Calcul du R.O.I en scrum

Calcul du R.O.I en scrum & description d'une carte type

Une fois passée cette étape de calcul mental, nous avons fait un macro chiffrage sur 6 sprints en prenant uniquement ce qu'il nous paraissait faisable dans le temps imparti (20 minutes de sprint dont 7 de réalisation concrète).

Prévision des sprints à effectuer

Voici notre tableau prévisionnel de sprint ainsi que notre board de suivi de projet : 

Répartition des tâches sur 6 sprints

Répartition des tâches sur 6 sprints

Tableau de suivi de projet scrum

Tableau de suivi de projet scrum

Selon le prévisionnel, en cumulant les valeurs cliente, nous aurions pu livrer 17 400 unités de valeurs cliente avec une moyenne de 17 points d'efforts par sprint... mais nous verrons à la fin combien ont été livré. Il est important de noter que l'on parle ici de points d'efforts et jamais de jour homme ou d'heure homme. Au vu du temps qui défile (il est bientôt 21h), nous partons sur les trois premiers sprints uniquement. En un coup d'oeil au prévisionnel, nous réalisons qu'il est possible d'inverser l'ordre de certains sprints, car les tickets sont tous indépendants, et que cette inversion nous permet de livrer de la valeur plus tôt. Nous décidons donc d'inverser le sprint 3 et 4 pour produire plus de valeurs dans le temps imparti. Nous avons donc une capacité de production maximale prévisionnelle qui passe de 9300 unités de valeurs cliente à 11500 unités. Dans la méthode scrum, avant de se lancer dans la construction de la maquette, nous devons nous engager sur une valeur assurée pour le client. L'équipe choisit de s'engager pour 9000 unités (soit 78% du potentiel) afin de ne pas se mettre dans le rouge et avoir un petit matelas de sécurité en cas d'imprévu.

Déroulé d'un sprint de 20 minutes

Dans le cadre de cet exercice, notre super ScrumMaster nous propose la répartition du temps ainsi : 3 Sprints de 20 minutes composé de :

  •  3 minutes de planification : Ce temps nous permet de choisir quels seront les tickets sur lesquels nous nous engageons à livrer en prenant en compte la valeur cliente, l'effort pour l'équipe et le respect du résultat (un club village pour rappel).
  •  7 minutes de réalisation : Go, go go ! Tout seul, ou en équipe de 2 ou 3, on prend un ticket et on résout la problématique. On a même le Product owner sous la main. Il ne faut pas oublié d'en profiter pour connaître les critères d'acceptations du client.
  • 5 minutes de revue/démonstration : On présente notre travail au Product owner et il nous fait un retour positif ou négatif en précisant ce qu'il manque, ce qu'il ne correspond pas à ces attentes, etc...
  • 5 minutes de rétrospective : On prends le temps de discuter des points bloquants de la réalisation que l'on vient de faire (organisation interne, avec le Product owner, entre les différents acteurs n'ayant pas le même rôle, etc.)

Trois, deux, un : le chrono est lancé !

C'est parti, on choisit les tickets que nous livrerons à la fin de ce sprint et nous nous lançons dans la construction, découpage, coloriage.

Sprint 1

Sprint 1 - Le début de la fin


L'équipe en action

L'équipe en action

On saute dans le temps et nous arrivons à la fin du dernier sprint. Résultat ? 

Tickets livrés final Tickets livrés final

On regarde le board de suivi final : Tableau de suivi de projet final

Tableau de suivi de projet final

Constat de l'expérience

Comme vous pouvez le constater, à 12, nous avons livré uniquement 2 tickets au premier sprint. Cela s'explique par une non communication avec Alfred (sous sa forme Product owner) durant la période. Nous sommes tous partis tête baissée sans prendre le temps de l'utiliser, le questionner sur des précisions utiles pour avoir des éléments sur la maquette correspondant à son besoin et donc validé lors de la phase de démo. Suite à cela, nous avons identifié les différentes questions à poser au product owner lors des phases de planification et de réalisation pour ne pas passer à côté des caractéritiques de chaque élément que nous construirons (couleurs, forme, taille, type de rendu, emplacement, etc...). Ce premier sprint était une sorte de testeur (phase dit Learn) pour évaluer les liens dans l'équipe, la façon de travailler ensemble, avec le client, etc. A partir de là, nous avançons vite et plutôt bien. Le cadre est respecté. Le client est content. On prends même le temps de lui demander une confirmation durant les 7 minutes de réalisation pour éviter de faire une démo sur un élément ne correspondant pas à son besoin. Au final, après une heure de transpiration, c'est exactement 21000 unités de valeurs cliente qui ont été livré en 3 sprints !

Analyse de cette mise en situation

  • La mise en place est rapide et légère
  • Nécessité d'une forte disponibilité du product owner (ou d'un processus d'interpellation pour récupérer des infos précises en cours de sprint)
  • La méthode Scrum permet la mise en place d'indicateurs de gestion de projets pertinents (performance, qualité...)
  • Cette méthode s'inscrit dans une démarche d'amélioration continue. Le premier sprint fut un échec, mais l'équipe a su rebondir en identifiant les problèmes et les causes de ceux-ci
  • Conséquence de l'application de cette méthode : Meilleure maîtrise des délais et du budget (possibilité de s'arrêter en cours de projet s'il y a suffisamment de fonctionnalités)

Et vous qu'en avez vous pensé ? Est-ce que cela reflète votre expérience dans un cas "réel" ? N'hésitez pas à nous la partager ;)

En prime : la maquette réalisée !

Club village d'Apollo ssc suite à la formation lego4Scrum

Club village d'Apollo ssc suite à la formation lego4Scrum

Vous souhaitez approfondir les méthodes agiles, n'hésitez pas et regardez nos autres articles sur ce sujet : https://blog.apollossc.com/category/tribunes/agile