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.

La suite de Fibonacci dans l'estimation des Story

Ken Schwaber (co-fondateur de la méthode Scrum) nous préconise d'utiliser le poker planning basé sur la vraie suite de Fibonacci (http://kenschwaber.wordpress.com/2011/03/11/planning-poker). En lisant cet article publié sur son blog, vous verrez comment la communauté scientifique, en la personne du Dr Stephen Hawking l'a interpellé au sujet de l'anormale simplification qui a été opérée sur les cartes dédiées à l'exercice...

 

Je vous propose ci-dessous la traduction de l'article :

J'ai utilisé la technique d'estimation du Planning Poker de l'extreme Programming depuis que James Grenning me l'a montré en 2003. Beaucoup a été écrit à ce sujet, comment l'utiliser, et comment il conduit rapidement à des estimations d'aussi bonne qualité que toute autre technique plus détaillée et plus longue. J'aime bien quand quelque chose que j'utilise marche. Je l'aime encore plus quand je peux pointer dans la nature ou dans la science les principes fondamentaux sous-jacents expliquant leur fonctionnement. La séquence de chiffres sur lesquel le poker planning est basé provient de l'ensemble de Fibonacci: «Par définition, les deux premiers nombres de Fibonacci sont 0 et 1, et chaque numéro ultérieur est la somme des deux précédents. Certaines sources suppriment le 0 initial, au lieu de commencer la séquence avec deux 1s. En termes mathématiques, la séquence des nombres de Fibonacci Fn est définie par la relation de récurrence Fn = Fn-1 + Fn-2 avec des valeurs semences F0 et F1 = 0 = 1 Wikipedia : Cela nous ramène à des lois naturelles, tels que la taille relative entre les verticilles dans une coquille de nautile, et le nombre d'or provenant de la sommation de l'inverse de l'ensemble: {This ties back to nature, such as the relative size between the whorls in a nautilus shell, and the golden ratio derived from the summation of the inverse of the set:} où {where } Source: http://en.wikipedia.org/wiki/Fibonacci_number Alors, fidèle à la nature, je me sers de ponts entre le poker planning et les numéros 1, 2, 3, 5, 8, 13, 21, 34, 55 ..., en fonction de la taille du backlog de produit. Imaginez ma surprise quand j'ai été appelé en grande détresse par le Dr Stephen Hawking, le physicien théorique. Il était curieux de savoir qui «fricotait » avec la séquence de Fibonacci. Lui et ses compagnons avaient remarqué une recrudescence de phénomènes affligeant ces derniers temps, tels que:    1. La vitesse de la lumière commence à varier de manière imprévisible.    2. La chute d'objets à partir d'arbres à différents vitesses qui étaient indépendants de tous attributs connus.    3. Les Coquilles de Nautilus éclataient spontanément.    4. D'autres perturbations inquiétantes de l'ordre naturel. Ils avaient étudié le problème, et suivis depuis ses origines jusqu'à ce jour, la communauté des développeurs de logiciels agiles. Ils ont constaté que plusieurs d'entre nous avaient perverti la suite de Fibonacci. Ils ont trouvé un certain nombre de jeux de cartes et des affiches qui montrent la séquence suivante: Dr Hawking indiqué un haut degré de probabilité qu'il y ait une corrélation entre la variation anormale de phénomènes naturels et cette perversion de la séquence de Fibonacci. Dr Hawking plaide, et je soutiens, que nous cessions et que nous abstenions de notre utilisation abusive de la séquence de Fibonacci, et que nous revenions à la séquence réelle. Ce sera réaffirmera notre relation avec la nature et notre monde. Best, Ken Schwaber

Estimation en points VS heures/jours, vélocité de l'équipe

La vélocité en Scrum : 

La vélocité représente la capacité d'une équipe Scrum à terminer des Stories (histoires). Cette capacité est estimé en points et non en heures ou jours.


Estimer en points VS heures / jours :

Lorsque l'on estime une fonctionnalité en jours on se retrouve forcément face à un dilemene. Il nous faut prendre en compte qui réalisera la tâche, car dans une équipe on peut avoir des experts qui réaliseront les tâches rapidement, alors qu'un débutant ou un nouveau dans l'équipe mettra plus de temps.

De la même manière, une même histoire simple (ex. :un écran de synthèse) sera plus longue à réaliser en début de projet qu'à la fin. Pour autant sa complexité (l'effrot nécessaire) sera la même. 

Retour d'expérience :

Ce n'est sans doute qu'un sentiment personnel, mais il m'est beaucoup plus naturel et simple d'estimer en points de complexité que d'estimer en jours comme j'ai eu à le faire dans les projets précédents. Cela est d'autant plus facile que cette estimation est collégiale, et qu'elle se fait à partir d'une suite (type Fibonacci).