vendredi 30 novembre 2012

Scrum Café 12 : Lego4Scrum


Il y a quelques jours, nous avons joué le fameux atelier de simulation Lego4Scrum décrite sur le site http://www.lego4scrum.com/ et que j'avais joué à un rendez-vous du SUG ( le Scrum Wine Bordelais).


Ce fut une très bonne session, aussi stressante que prévue pour tous les participants.



Auto-organisation


Le Product Owner vient de présenter la liste des choses qui doivent constituer sa ville et 3 équipes de 5 personnes s’auto-organisent afin fabriquer cette ville pour le client.



L’auto-organisation se met en place avec 3 Scrum Masters.

Estimation 

Finalement les fonctionnalités de la ville sont estimées selon une technique d’estimation relative en complexité : Faible, Moyen, Complexe


Valeur métier

Les équipes ont demandé au Product Owner de classer les fonctionnalités par importance en plaçant un « 1 bleu » sur celles que je voulais avoir en premier, puis un 2 sur les autres, et enfin un trois sur celles que je ne voulais pas trop rapidement.

La complexité des fonctionnalités a été reportée à partir de la suite suivante : 
  • Faible= 2, 
  • Moyen = 5, 
  • Complexe =8


Des prototypes ont ensuite été présentés aux équipiers afin de mieux visualiser ce qu’il fallait faire.



Certains ont pensé à demander au Product Owner ce qu’il en pensait : il a tout refusé, mais l’information n’a ni été partagée avec le reste de l’équipe, ni suffisamment comprise par les équipiers.


Les itérations

La première des trois itérations a commencé et les assemblages de briques s’enchainent :
Conception du plan de la ville, premiers bâtiments produits







Rétrospective Sprint 1

« Ou est ma ville ! » crie le Product Owner dans la salle à la recherche de sa ville.
Au bout d’un moment, une timide construction vient se poser sur le terrain nu, quelques fondations décorent le bord de la table.


Un plan de la ville a pu être proposé au Product Owner qui a accepté le plan sous réserve que certaines modifications soient prises en compte


Itération 2

Le terrain est préparé et les premières fonctionnalités voient le jour :
  • Le jardin public, 
  • Les routes et intersections, 








La fin de l’itération approche : 

Les équipiers préparent le bilan du Sprint : 
  • Les fonctionnalités produites sont placées sur le terrain 
  • On déplace les post-its initialement prévus dans le Sprint de la colonne « En cours » à la colonne « Fait » 







Rétrospective Sprint 2

Cette fois, le Product Owner n’a pas besoin de demander ou se trouve sa ville :


Les fonctionnalités sont parcourues unes à une et la plus-part sont acceptées par le Product Owner qui réclame tout de même que l’herbe pousse plus vite dans le jardin public….

Sprint 3 : le dernier





La validation des fonctionnalités du Produit est faite au fur et à mesure que les fonctionnalités sont produites (ci –dessus, image en bas à droite avec Benoist et Guillaume qui présentent leur avancement de l’hôpital) : 
  • « Plus grand l’hopital » 
  • « Plus grand le lieu de culte interconfessionnel » 
  • « Plus haut les étages du bâtiment de bureaux »
Les produits sont corrigés et améliorés au fur et à mesure de leur fabrication










Rétrospective finale



Toutes les fonctionnalités sont produites en fin de jeu. La ville et belle et un peu de pelouse a poussé dans le jardin public




Débriefing

Les équipes ont désigné des Scrum Masters pour qu’ils gèrent la relation avec le client, mais ça n’a pas empêché tout le monde de lui poser des questions. Un beau bazar !

La période d’auto-organisation de l’équipe avec l’estimation de la complexité et de la valeur métier a été difficile. Tout le monde posait des questions au PO qui ne savait plus à qui répondre. Stressant !

Les sujets ont été planifiés en 3 Sprints mais sans calculer le ROI. Seule la valeur métier a été utilisée : c’est dommage, l’équipe aurait peut-être pu livrer un peu de valeur au premier Sprint avec l’abri de bus par exemple (très simple à réaliser pour une valeur métier moyenne).

Les informations données par le Product Owner ne sont pas partagées avec le reste des équipes (ex : malgré le refus des maquettes proposées, elles ont été utilisé comme modèle pour le premier Sprint.)

Les équipes ont bien géré leur temps : un chrono a été lancé pour surveiller le temps de production. A la deuxième itération, tout le monde s’est occupé d’organiser la ville sur le terrain avant la fin du temps imparti.

Le jeu a été stressant, comme prévu, pour les joueurs mais aussi pour l’animateur qui devait endosser les rôles distincts d’Animateur, Product Owner et parfois « Super » Scrum Master.


C’était prévu, mais le timing était assez serré. L’organisation des équipes nécessite plus de temps que celui accordé.

Le débriefing final a été un peu écourté également.


Atelier Prune the Product Tree


Prune the Product Tree est un des nombreux "Innovation Game" créé par Luke Hohman.



Sur la base d'un arbre dessiné sur une grande feuille de papier kraft, l'équipe a disposé des post-its sur des branches.

Les branches représentent des regroupement de fonctionnalités et les post-its les fonctionnalités.
Selon la position de la feuille dans l'arbre, on voit les fonctionnalités existantes et les celles qui devront être planifiées dans les versions suivantes. Les couleurs indiquent la technologie utilisée, si elle est obsolète ou cible.

Cet atelier se joue normalement avec des utilisateurs afin qu'ils puissent donner un feedback sur la vision qu'ils ont de votre produit.
Nous avons détourné ce jeu pour représenter quelques fonctionnalités de l'espace Internet du client. Ce travail a été réalisé à partir d'un travail réalisé en atelier pour présenter le plan stratégique annuel.

Ce jeu laisse une grande part de créativité aux participants qui peuvent placer des coeurs, des oiseaux, des fruits plus ou moins mûrs, des fruits pourris.

Il est possible de tailler des branches existantes pour supprimer les fonctionnalités qui ne rencontrent pas leurs utilisateurs etc...