M-Lab a testé … le Lego 4 Scrum

Dans l’univers des méthodes de gestion de projet, les jeux sérieux ne manquent pas. Quand il s’agit de méthode agile de gestion de projet, transmettre et faire adhérer à la philosophie gestionnaire de l’agilité, notamment celle émise dans le Manifeste Agile de gestion de projet n’est pas si simple. Le lego4scrum est une technique de simulation de la méthode Scrum créée par Alexey Krivistky en 2009. Utilisant, comme son nom l’indique, des briques Lego, la simulation requiert au minimum neuf personnes et peut être mise à l’échelle pour jouer jusqu’à plusieurs centaines de personnes. L’objectif de cette simulation est principalement de sensibiliser et de former de manière ludique des futurs praticiens de la méthode Scrum tout en pratiquant de nombreuses techniques. L’équipe de Recherche M-Lab a pu tester cette approche pédagogique le temps d’une après-midi au sein du Lab agile de Daylight Consulting.

Pour rappel, la méthode Scrum se compose de 3 grands acteurs. Le Product Owner, qui est le garant de la vision du produit à livrer ; l’équipe de réalisation, chargée de construire le produit de manière auto-organisée, et enfin le ScrumMaster, dont le rôle est de faciliter le fonctionnement de l’équipe de réalisation en levant les barrières rencontrées. Le produit à livrer dans cette simulation est une ville, et la règle principale imposée à tous les participants porte sur le partage commun des responsabilités. Lors de l’expérimentation avec les membres de l’équipe M-lab, les participants étaient 9 répartis en 3 équipes mais un seul produit était à livrer.

Phase 1 : Présentation de la vision et préparation du Backlog

Durant la première phase du jeu, l’animateur prend le rôle du Product Owner qui le joue de façon suffisamment ambigüe pour simuler l’incertitude régnant dans les débuts d’un projet. Il présente le produit attendu et émet une liste de besoins assez déconcertante.

Les participants ont 10 minutes pour préparer le carnet des exigences (appelé Backlogdans la méthode Scrum). Ils doivent s’organiser dans un premier temps afin d’estimer l'effort lié aux tâches à réaliser en utilisant des métriques variées : les participants peuvent utiliser la suite de Fibonacci ou simplement une suite du type XS, S, M, L, XL, XXL. Cette étape permet de mettre en pratique des techniques d’estimation rapide (le planning poker par exemple) et la notion de complexité relative.

Une fois les tâches estimées, les participants doivent les classer par ordre de priorité : en utilisant la technique MoSCoW (pour Must, Should, Could Want) ; l’idée est d’émettre des priorités claires découlant d'une compréhension commune du travail à venir.

Phase 2 : Lancement des Sprints.

Un Sprint, dans la méthode Scrum, est une période courte consacrée à la construction d’un incrément de produit potentiellement livrable. Dans cette deuxième phase, les participants ont pu ainsi vivre les différents rituels d’un sprint qui se divise en quatre sous-parties :

1. Le Sprint Planning (Planification d'un sprint) : les participants ont 2 minutes pour planifier les tâches à réaliser durant les 7 prochaines minutes de construction. Cette étape permet d’organiser le sprint et de préparer la coordination des équipes.

2. Construction de l’incrément : durant cette étape les participants peuvent enfin se lancer dans la construction avec les Lego pendant exactement 7 minutes.

3. Sprint Review (évaluation de l’incrément) : à la fin des 7 minutes, les participants doivent présenter l’incrément de produit livré. Cette réunion se fait avec l’ensemble des participants autour de la table où la ville prends forme pendant une durée de 4 minutes. Cette étape révèle souvent les dysfonctionnements de l'acceptation tardive des fonctionnalités et l'importance de construire une coopération étroite entre le Product Owner et les équipes de réalisation.

4. Quatrième et dernier rituel d’un sprint : le Sprint Retrospective (rétrospective du sprint), pour s’initier aux principes d’amélioration continue du fonctionnement des équipes. Ce rituel a pour but de tirer des enseignements du mode de fonctionnement des équipes. Les participants doivent ainsi réfléchir sur « l’optimisation de l’ensemble » en faisant émerger ce qui a bien fonctionné, ce qui a moins bien fonctionné et les actions à mettre en place pour s’améliorer, l’idée étant d’éviter les optimisations locales.

Au cours du jeu, nous avons pu mettre en oeuvre 4 sprints donnant le résultat suivant :lors du second Sprint, le Product Owner complique le projet en ajoutant des exigences, obligeant ainsi les participants à s’adapter aux contraintes imposées en priorisant à nouveau régulièrement les tâches.

Phase 3 : Debriefing et célébration

L’animateur propose un récapitulatif du jeu en répertoriant les éléments du processus suivi : sprint planning, construction, sprint review et sprint retrospective. Il laisse place ensuite à un debriefing avec les participants, au cours duquel chacun partage les leçons apprises afin d’analyser ce qui les a aidés à atteindre les résultats malgré la complexité du projet (beaucoup de personnes, exigences peu claires, temps restreint).

L’idée, enfin, est d’échanger avec les participants sur la manière dont ils peuvent appliquer le même fonctionnement et les mêmes idées pour gérer leurs initiatives de développement de produits.

Avis de l’observatoire :

La phase 1 de présentation de la vision et de dialogue entre les participants sur le carnet des exigences est une phase bien plus importante qu’il n’y paraît. Même si le développement agile autorise et stimule du feedback en boucles courtes, un accord préliminaire des participants au projet sur les priorités, la faisabilité (le temps mis pour réaliser certaines tâches) et surtout le niveau d’ambiguïté attachée à certaines exigences, est essentiel pour que les phases de sprint soient performantes.

Une grande partie de l’intérêt de ce type d’atelier est dans la pédagogie de l’ambiguïté : apprendre à avancer et à s’organiser en focalisant l’attention sur la réduction de l’ambiguïté plutôt que sur l’obtention du résultat final. Ceci implique de considérer que livrer des choses inachevées au client (le product owner) est une pratique acceptable. Naturellement, un réflexe de type PMI (Project Management Institute), planificateur, peut empêcher cela (le souhait de vouloir planifier l’ensemble des tâches, sur 4 sprints).

Un autre intérêt réside dans la pédagogie de l’intégration, composante fondamentale du management, en général. Bien que répartis en plusieurs équipes, l’atelier n’est pas une compétition et nécessite une coordination entre participants bien plus forte qu’il n’y paraît au début du jeu, lorsque chacun croit qu’une simple division du travail suffira à développer le projet de façon satisfaisante. Les participants découvrent les nécessités d’introduire des mécanismes d’intégration, notamment l’intégration des propositions coopératives qui émergent spontanément de chacun, et qui permettent de contrer les effets pervers de la différenciation que la division du travail conduit à introduire.

Naturellement, le jeu a des limites. L’accès aux enjeux liés à l’agilité n’est pas possible si l’équipe reste empêtrée trop longtemps dans les problèmes de coordination élémentaires. Autrement dit, les difficultés que peuvent éprouver les participants sont d’abord des difficultés ordinaires de communication, de leadership, de coopération, etc. Par ailleurs, le Lego® renvoie potentiellement à un univers de jeu dans lequel une réalisation n’est réussie que si elle est réaliste, esthétique, etc. Or, la réalisation doit être efficace et non nécessairement esthétique. Comprendre cela peut faire perdre un ou deux sprint(s) alors que ce n’est nullement l’enjeu.