Estimations agile - Square Game

Contexte de formation/sensibilisation agile

Expliquer les estimations agile à une équipe, un groupe lors d'une formation ou d'un coaching est toujours long et fastidieux.
La réticence à supprimer les estimations en jours/hommes est très forte surtout lorsque nous avons des Managers dans l'assemblée.
Les arguments que nous avançons en tant que formateur/coach sont entendus, mais il faut encre prouver que ça marche vraiment, et la plupart des simulations sont taxées d'être trop simplistes. Après les explications, les exemples et les retours d'expérience les échanges s'éternisent.
Qui n'a jamais vécu ça? En générale, on fini par cloturer le point et passer à un autre thème mais sans avoir convaincu tout le monde.

Le square Game comme solution?

Avec mes collègues Olivier Picaud (@opicaud1 ‏) et Thierry Delestre (@ThierryDelestre), nous utilisons depuis quelques années le jeu des trois carrés (ou avec surfaces patatoïdes) dont il faut estimer la surface en centimètres carrés, puis de refaire cet exercice avec une estimation relative de leur taille, en prenant le premier et le plus petit pour étalon.
Ce jeu fonctionne très bien, mais il est difficile de compiler les résultats en direct et de fournir une analyse chiffrée des résultats en direct surtout lorsque l'auditoire est élargi à une quarantaine de participants 

Facilitez vous la démonstration et essayer le Square Game en ligne, c'est super efficace!

Sans limite de participants, l'animateur peut projeter son écran et lancer une session qu'il doit nommer (ci-dessus "201707"). 

Session en cours lors d'une formation

Une fois la session lancée, les participants peuvent rejoindre la session à l'aide de leur smartphone (ou de leur tablette/PC):

participer à une session avec son smatphone

• Ils se connectent à la session et renseignent un login (au choix)
• Ils doivent estimer la surface des trois carrés A, B et C en cm²
• Puis estimer à nouveau les carrés A, B et C, mais en relatif en utilisant le carré A (qui fait 1 unité au carré - 1u²) comme référence.

Etape 2 : estimations absolues (cm²)

L'animateur voit en temps réel le nombre de personnes qui se connecte, qui répondent aux estimations en absolu (cm²) et ceux qui ont terminé les estimations en relatif.
Il est alors facile d’enchaîner sur le débriefe! On gagne du temps là encore.

L'animateur n'a plus qu'à mesurer à l'écran la taille réelle du carré A, B et C et de renseigner leur surface afin de clôturer la session.

Une fois terminé, l'application s'occupe de tout et vous propose quelques statistiques sur les résultats. Il ne reste plus qu'à s'appuyer sur ceux-ci pour assoir l'argumentaire :

Synthèse de la session

Il est alors facile de parcourir la liste de résultats pour montrer que personne n'a donné toutes les bonnes réponses. Heureusement que certains ont donné des chiffres aberrants car grâce à eux la moyenne des résultats se rapproche de la valeur exacte : Sagesse des foules!

Le calcul des écarts types (à la mesure/à la moyenne) permettent de lancer la discussion suivante :

• Comment peut-on se mettre d'accord sur un nombre de jours quand notre perception est si différente? 
• On sera jamais d'accord sur le temps! On passera donc beaucoup de temps à discuter du nombre d'heure ou de jours plutôt que de discuter du sujet de fond : 
• Quel est le besoin de l'utilisateur? 
• Mais qu'est qu'il y a dans cette User Story? 
• Quelles sont les règles de gestion qui la composent?
• Doit-on mettre en place un nouveau service, impacter un service existant?
• Quels sont les risques auxquels on s'expose et qui nous conduiraient à ne pas la terminer?
• Que peut-on faire pour la terminer efficacement?
• Doit-on expérimenter de nouvelles choses techniques ou fonctionnelles avant de la commencer?
• Peut-elle être prise dans le prochain sprint/le sprint que l'on commence?

 Pour faciliter le discours et la compréhension des principes de base je complète le jeu avec des slides sur l'estimation, ou des posters (je préfère) que j'ai réalisé pour illustrer le propos :

Poster sur les estimations relatives et les indicateurs d'avancement

N'hésitez pas à l'utiliser et à laisser un commentaire sur ce blog. Je suis certain que vos feedbacks permettrons d'améliorer cette première version!

Dans le backlog j'ai déjà noté les améliorations suivantes :

• Prendre en compte les saisies avec virgule (on peut actuellement les saisir, mais seules les parties entières sont comptabilisées). Même si cela ne change rien, cela évite des frustrations, incompréhensions, ou questions inutiles ==> enlever le bruit
• Lors de la clôture de la session, ne demander que la mesure du premier carré A en cm². Les carrés B et C seront calculés automatiquement
• Gestion d'erreurs avancée : aujourd'hui j'affiche trop facilement les traces dans la page
• Clôturer vraiment la session (actuellement si on lance une session avec le nom d'une session existante, on peut la continuer)
• Pouvoir reprendre une session commencée
• Une version en Anglais

Rétrospective Annuelle et Innovation Games

Animer une rétrospective avec des Innovation Games

En cette fin d'année j'ai été missionné pour animer la rétrospective annuelle de notre support technique.
Habituellement cette réunion est unidirectionnelle : le manager présente un PPT à son équipe et relate les événements marquants de l'année.

Cette forme a vécu et l'équipe a proposé une nouvelle version plus interactive, plus vivante et plus constructive.

Reposons le décor 

Il s'agit d'une équipe constituée d'experts techniques - DBA, développeurs ... Le gros de l'équipe se trouve localisée en région Bordelaise - même bureau- mais quelques membres sont répartis sur d'autres sites - Aix-en-Provence, Nantes ... . 
Le client principal est le pôle Internet, mais il y a aussi un département GED et un département Intranet. Quelques membres de l'équipe sont de nouveaux arrivants, d'autres sont arrivés en cours d'année et certains sont présents depuis la création du service il y a 3 ou 4 ans.
L'équipe était initialement positionnée sur la résolution des problèmes de production, puis a essayer de se recentrer sur des activités plus en amont afin d'anticiper les problèmes et de ne plus subir les choix réalisés par d'autres tout en ayant une augmentation conséquente de ses effectifs et de son périmètre.

Faire un bilan est devenue plus qu'une nécessité, un élément vital!

C'est là que les Innovations Games nous ont apporté une solution.

Au programme

Une présentation des faits marquants de l'année sur le thème de la voile illustrée par un tour du monde en équipage. Un parallèle est fait entre les valeurs de l'équipe et les valeurs véhiculées par le sport - rugby et voile- .

• Un mur de feedback placé prés de la porte de sortie de la salle pour collecter les retours après chaque atelier.
• Un atelier Vision Box afin que chacun contribue à la constitution de la vision idéale de ce qu'est cette équipe : son rôle, ses forces, son périmètre - 4 équipes
• Un repas convivial tous ensemble,
• Un atelier Remeber The Future pour se projeter dans trois scénarios idéaux à l'horizon 2018 - pour laisser un peu de place à l'imaginaire et au progrès que pourrait faire l'équipe et l'entreprise - 3 équipes
• Un atelier Speed Boat pour identifier dans le contexte actuel les forces et les freins de l'équipe en vue d'un objectif idéal à court terme - tous ensemble
• Débriefe du mur de feedback pour chaque atelier puis débriefe des retours plus globaux (la journée, l'équipe... complètement ouvert en fait!)
• Un ROTI de la journée pour finir ( des 4 et des 5 : ça fait plaisir!)

Durant cette journée, j'ai pris quelques 222 photos - très utiles pour se remémorer l'ambiance et les attitudes - et des vidéos lors de la présentation des travaux des différentes équipes constituées pour les jeux  - très riches d'enseignement également car le discours est également riche en enseignement.
Pour chaque équipe de travail et chaque atelier il y avait un observateur/facilitateur, également membre de l'équipe. Mon rôle était celui de facilitateur, animateur des jeux, et time-keeper.

Bilan en images

Bon assez de Bla Bla, voici quelques unes des photos réalisées, c'est parlant:

Rétrospective : introduction

Les valeurs du sport comme métaphore

Atelier Product Box

Product Box : L'organisation des thèmes

En pleine création

Des échanges animés

La "vente" de la "Box"

Les quatre box produites

Le mur de feedback s'alimente par atelier

Un repas tous ensemble c'est ^lus convivial

Remember the future : la timeline en cours de construction 1

Remember the future : la timeline en cours de construction 2

Remember the future : la timeline expliquée au reste de l'équipe

Le Speed Boat : tous ensemble

Le mur de feedback se rempli

La mascotte échouée prés du bâteau de l'équipe

Speed Boad : Le débriefe des ancres et des vents

En conclusion : 

Une journée ou tous les participants 

• ont été très actifs, 
• ont passé une journée agréable, 
• ont eu le sentiment d'être une seule et même équipe
• ont partagé leurs réussites et leurs problèmes

Beaucoup de matière a été récoltée et en plus d'un compte rendu des ateliers, nous avons synthétisé une vingtaine de problèmes. Ces problèmes ont été ordonnés par importance et valeur - merci Fibonacci - ce qui nous a permis de définir les 3 problèmes les plus importants et pas trop complexes à traiter en priorité.

Parmi ces problèmes, le premier est le manque de vision commune et partagé des missions de l'équipe et de son périmètre. 
Une fois réglé il est fort possible que d'autres problèmes disparaissent d'eux-même.

Revue de Backlog : technique d'estimation

Magic Estimation :
(le 29/04/2012 : j'ajoute à ce billet le nom de la technique d'estimation décrite)

Traditionnellement, lors de nos revues de Backlog nous réalisions nos estimations en équipe, en appliquant la technique du Planning Poker.

Récemment, Michel Goldenberg a donné des formations spécifiques certifiantes de Product Owner et de Scrum Master chez notre client. Son public était essentiellement composé de personnes a qui j'avais moi-même dispensé une formation "généraliste" sur Scrum.

J'ai donc profité de sa présence dans les locaux pour me glisser à la fin de la session et échanger avec lui sur les pratiques et techniques qu'il préconisait.

Volontiers provocateur, Michel Goldenberg me fit remarquer que le Poker Planning n'était pas une bonne pratique! Enfin, qu'il en existait de meilleures...

En trois minutes il nous a tous convaincus, et ce matin nous avons mis en place sa préconisation :

•    le Scrum Master  écrit la suite de Fibonacci au tableau : un nombre de la suite par ligne
•    le Scrum Master  place aléatoirement les post-it des Stories sur le tableau
•    l'équipe estime la position relative des User Stories en déplaçant les post-its
•    les détails des histoires sont discutés en séance avec le Product Owner

Le premier gros avantage pour l'estimation est le coté visuel :

•    chaque Story prend place à coté d'une autre de même taille
•    et tant que tout le monde n'est pas d'accord sur l'estimation, on creuse les détails

Cela a plusieurs avantages : On ne se focalise pas sur le nombre de points que vaut la Story, mais plus sur le poids relatif des unes par rapport aux autres. Si la Story de base (template) est représentative et que les Stories sont correctement décrites, le travail d'estimation  en relatif est alors très rapide et efficace :
 "C'est plus grand que" ou "plus petit que" se résout facilement en équipe et favorise les échanges entre équipiers.

Autre conseil de Michel Goldenberg, pour la revue de Release Backlog :  demander à chaque membre de l'équipe de prendre des notes personnelles sur les détails des Stories. Ainsi lorsque au 5éme ou 6ème Sprint, lorsque l'on rediscutera de la Story pour une Revue de Backlog du Sprint, chacun à l'aide de ses notes pourra se remémorer les détails discutés. La pluralité des notes permettant de conserver trace des différents aspects de la Story et favorisant la résurgence des souvenirs (en 3D).

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).