Un jeu de Lego pour apprendre à travailler en mode agile ? Les appre­nants du MOOC L’en­tre­prise agile s’y sont essayé lors d’une soirée un peu parti­cu­lière.

A tout âge, l’être humain n’ap­prend jamais mieux que par le jeu. Alors pour complé­ter le MOOC "L’en­tre­prise agile," Florent Lothon, coach agile et expert de la forma­tion et les coach de onepoint ont voulu invi­ter quelques uns des appre­nants à une soirée spéciale. Un jeu, conçu spécia­le­ment pour apprendre l’une des méthodes agiles les plus connues et large­ment utili­sée dans des projets de déve­lop­pe­ment logi­ciel : Scrum. 

Chez Unow, nous avions aussi un projet secret : orga­ni­ser un événe­ment pour que les appre­nants du MOOC se rencontrent, dans une ambiance sympa­thique et chaleu­reuse, pour échan­ger entre eux et avec Florent Lothon. 

Sélec­tion­nés par l’in­ter­mé­diaire d’un quiz dédié lors du module 3 du MOOC, ils étaient une quaran­taine un mardi soir, à se présen­ter dans les magni­fiques locaux de onepoint. Ils ne savaient pas préci­sé­ment ce qui les atten­dait car nous avions été on ne peut plus évasifs sur le déroulé. 

Seule infor­ma­tion : ils allaient parti­ci­per à un jeu et la soirée s’an­nonçait … intense. 

Qu’est-ce que la méthode Scrum ?

L’objec­tif de Lego for Scrum est d’ap­prendre la méthode de travail agile bapti­sée Scrum, qui se défi­nit comme un schéma de déve­lop­pe­ment de produits complexes. Conçue pour amélio­rer le proces­sus de déve­lop­pe­ment infor­ma­tique, Scrum s’op­pose au cadre tradi­tion­nel (cahier des charges / plan­ning / rendu) en propo­sant un cadre holis­tique et itéra­tif. Les équipes livrent des proto­types à inter­valles régu­liers et le projet se dessine au fur et à mesure. La métho­do­lo­gie repose sur des cycles, des boîtes tempo­relles : les sprints, qui rythment la livrai­son des proto­types.

Product Owner, Scrum master… : le jargon agile  

• Product Owner : le « PO » est le client. Il défi­nit le cadre du projet et les prio­ri­tés et valide ou non le travail des équipes de déve­lop­pe­ment à la fin de chaque sprint. 
• Back­log : c’est le tableau auquel chacun se réfère. Il liste l’en­semble des livrables et les classe par ordre de diffi­culté et de prio­rité. C’est à partir de ces éléments que l’équipe pourra établir ses objec­tifs pour chaque sprint.
• Sprint : unité de temps. Avant le sprint, l’équipe défi­nit les livrables qu’elle devra réali­ser pendant le sprint et à la fin, elle réalise une démons­tra­tion de ce qui a été produit au Product Owner. Lors de la rétros­pec­tive, l’équipe discute de ce qui a plus ou moins bien fonc­tionné dans le travail d’équipe. 
• Scrum master : il n’est pas un mana­ger, mais fait le lien entre l’équipe de déve­lop­pe­ment et le product owner. Son rôle : garan­tir que la demande du client est bien comprise et défi­nie et qu’avant chaque sprint, les déve­lop­peurs connaissent bien leurs objec­tifs.

Lego for Scrum : lear­ning by doing

Les parti­ci­pants sont mis sous pres­sion : en seule­ment 3 sprints de 10 minutes, ils doivent construire en équipe une ville en légo. Le product owner change d’avis, ajoute des éléments, se montre intrai­table. Mis en état de stress, le carac­tère de chaque joueur/déve­lop­peur se révèle et les dysfonc­tion­ne­ments dans le travail d’équipe appa­raissent clai­re­ment, rendant chaque « rétro » instruc­tive. A la fin du jeu, qui dure entre 2 et 3 heures, les parti­ci­pants ont en mémoire des sensa­tions : des souve­nirs bien ancrés qui valent tous les cours théo­riques du monde. En effet, il est prouvé qu’on n’ap­prend jamais mieux que lorsqu’on est engagé dans le proces­sus d’ap­pren­tis­sage. 

Le résul­tat : des villes conçues en mode agile

Nos appre­nants ont construit trois villes : Cit’Île, la ville flot­tante, Green­ville et Médié­ville. Elles sont inter­con­nec­tées entre elles, ce qui signi­fie que les équipes ont dû se coor­don­ner au cours du jeu.