Mois : décembre 2016

Immersion Lego chez OnePoint

Eric LannemajouLaisser un commentaire

J’étais mardi soir chez OnePoint pour une soirée Agile réservée aux participants du MOOC l’entreprise Agile et qui était consacrée à un atelier Lego For SCRUM. Après une présentation succincte des principes de SCRUM, les participants se sont regroupés autour des 3 grandes tables dressées pour l’occasion avec des boîtes de Lego. Pour ceux qui ne connaissent pas, le but est simple (mais la réalisation complexe): chaque équipe ou du moins chaque groupe de personnes regroupées autour d’une table, doit construire une ville selon un Product Backlog et des items définis par un Product Owner (PO dans la suite de l’article). L’énoncé de l’atelier proposait de construire 3 villes :

  • Greencity : la ville verte innovante
  • Medieville : la ville médiévale
  • Cityille : la ville flottante (je ne suis pas certain du nom de celle-ci)

Nous voilà donc par équipes de 7 à 8 personnes pour construire en Lego, les éléments de notre ville en respectant les étapes et rituels timeboxés de SCRUM. Nous avons pu tout de suite noter des différences dans la manière d’appréhender le jeu. Certaines équipes ont choisi des noms alors que d’autres ont gardé les nominations équipe A, équipe B attribuées au début du jeu. Peut être est-ce pour renforcer le sentiment d’appartenance à un groupe ?
Mais commençons la partie en déroulant les différentes phases d’un projet SCRUM :

  • Première étape : la construction du Backlog : 15 min durant lesquelles le PO nous a indiqué ses priorités : un parc, une montagne, un groupe de maisons… Même avec deux boîtes de Lego, la tâche paraissait longue et compliquée d’autant que d’après les premières contraintes, aucun élément ne pouvait être dessiné. « Vous êtes certaine Madame le PO, aucun élément ? « 
  • Deuxième étape, l’estimation selon la suite de Fibonacci jusqu’à 8 (1, 2, 3, 5, 8) et le choix des items du premier sprint (Backlog de sprint). La complexité ici consistait à estimer des éléments encore abstraits. La définition de l’estimation relative nous a très bien été expliquée avec des verres vides de différentes tailles pouvant contenir un nombre de M&Ms. On ne connaît pas la contenance du verre le plus grand mais on estime approximativement celle-ci au double du verre le plus petit. Tout est dit, prenez un item du Product Backlog et estimez le. Puis basez vous sur celui-ci pour estimer les suivants en comparant à chaque fois avec cet item. Ce n’est pas compliqué. Pour ma part, j’ai tendance à choisir un item de complexité moyenne de façon à pouvoir bénéficier d’une grande échelle de valeurs dans la suite de Fibonacci.
  • Voilà, on passa alors à la réalisation avec un sprint de 7 min. Le résultat fut comme nous l’a dit Florent Lothon plus tard dans la soirée, comme une première crêpe; perfectible et riche en enseignement… Heureusement pour nous et après une concertation entre PO, la contrainte de tout réaliser en Lego a changé et nous avons pu dessiner des éléments. Mine de rien, cela nous a quand même pas mal facilité la tâche pour les routes et les rivières…20161206_202657
  • Première revue de sprint : le parc n’a pas été retenu car pas assez grand. Ce n’est pas grave, après avoir questionné le PO, nous l’avons validé au sprint suivant.
  • Lors de la rétrospective de sprint accélérée (3 min), nous nous sommes demandés si nous n’avions pas besoin d’un SCRUM Master; l’équipe n’était pourtant pas trop mal organisée.
    A partir du deuxième sprint et au troisième surtout, la magie de l’intelligence collective et l’auto-organisation du groupe a commencé à opérer et on peut dire que le résultat n’était pas mal au final malgré quelques rebondis-sements dans la priorisation du Product Backlog et même de son contenu : apparition au début du sprint 3 d’une épique sur un port industriel.

Je n’ai pour ma part pas réussi à rentrer dans le jeu, peut être à cause de la taille des équipes. Deux équipes de 7 à 8 personnes travaillant sur le même projet rendent la communication et la synchronisation entre les individus plus compliquée que pour des équipes de taille plus restreinte. L’atelier de ce soir aurait pu me laisser un sentiment d’inachevé si Florent Lothon n’était pas venu pour débriefer avec nous sur le déroulement du jeu. Pendant plus d’une heure, Florent nous a démontré les bienfaits de SCRUM en insistant sur le fait qu’il était tout à fait possible de construire les produits de manière empirique sans avoir besoin de tout planifier et concevoir à l’avance. Il a très bien imagé ce concept à l’aide d’une maison qui ne serait pas terminée mais dans laquelle les habitants viendraient vivre. Il leur faudrait à minima les éléments principaux de la maison; le sol, les murs et le toit. Puis certaines pièces et enfin, ils devraient prioriser les pièces à finir par corps de métier; faire venir l’électricien pour la chambre par exemple, puis le chauffagiste… Florent nous a aussi fait remarquer que nous avions fait appel à l’intelligence collective au cours du jeu. Enfin, il s’est plié à 1h de questions/réponses dans laquelle il a abordé différents sujets comme le reporting, le contrat agile…

Merci Florent pour avoir partagé ta passion et tes connaissances sur SCRUM et merci à OnePoint de nous avoir reçus dans ce cadre agréable. Pour terminer, nous avons noté sur un post-it un mot que la soirée nous évoquait. J’ai noté « complémentaire » car celle-ci nous a vraiment permis de mettre en pratique les concepts abordés dans le MOOC.

Liens et Références :

Publicité