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

mercredi 3 octobre 2012

Un atelier Product Box

Contexte de l'atelier

Dans le cadre de l'animation de l'agilité chez mon client, nous avons créé un groupe de travail "Product Owner" dont l'objectif est de partager des pratiques permettant de mieux travailler avec le métier, à défaut d'avoir des utilisateurs.
Dans ce cadre j'ai proposé de présenter les plus simples/accessibles des Innovation Games de Luke Hohmann : Product Box, Buy a feature, Spider Web, Speed Boat, Prune the Product Tree.
Après la présentation des jeux à l'équipe, un vote a permis de choisir le premier jeu (Product Box) que nous allions jouer afin de dérouler le processus complet de mise en oeuvre d'un Innovation Game.


Objectif 


Créer une boite de produit (Product Box) décrivant l'agilité afin de vendre la démarche au métier.

Etant donné que les participants sont des "Product Owner", nous sommes pas les vrais clients du produit que nous souhaitons vendre. C'est la MOA des projets (basées sur des sites différents).
Au final, ce que les équipes ont fabriqué est donc plus une "Vision Box" qu'une "Product Box".

Préparation de l'atelier

Les participants ont été invités une quinzaine de jours avant le déroulement de l'atelier afin qu'ils puissent réfléchir à l'atelier.
De mon coté j'ai pillé les fournitures chez le client est dans mon agence, je suis allé faire des achats de gomettes colorées, feutres de couleur, tubes de colle, post-its multicolores....
J'ai également préparé des boites blanches pour que chaque participant puisse réaliser sa propre boite de produit et même recommencer si besoin.


L'atelier

Le jour J, tout est prêt, nous avons 1h30 pour préparer les boites et les vendre.
Les participants un peu intimidés par l'exercice ne souhaitent pas faire leur propre boite de produit, mais ils s'organisent en 2 groupes.

Premier temps : organisation des idées
Second temps : travaux pratiques













Après 1h10 d'effort, les deux équipes ont finalisé leur produits :



boite de produit 1

boite de produit 2


Il est temps de vendre son produit aux autre participants:








Après la vente des boites par chacune des deux équipes le groupe a conclu que :

  • L'équipe 1 a bien mieux vendu sa boite de produit (le discours) que l'équipe 2.
  • Les deux Box sont très belles, mais il faudrait les mélanger pour obtenir la boite idéale
  • L'atelier a été apprécié (évaluation ROTI)  :
    • 4 votes à 5
    • 1 vote à 4


Commentaires des participants :

  • 5 ! car cela permet de définir des objectifs communs de façon ludique et c'est applicable en toutes occasions, même en dehors du contexte métier.
  • Bonne : c'est 2 ou 4 ?
  • 5 sans problème.
=> On a tous eu beaucoup de plaisir à jouer ce jeu, et nul doute qu'il nous servira à l'avenir!

La suite ...

Compiler les observations de chacun des participants, et produire les rapports qui nous permettrons de mieux comprendre notre produit, notre manière de l'envisager et de le vendre.

mercredi 26 septembre 2012

Scrum Wine du 25 Septembre 2012

La session a été animée par Fabrice Aimetti et Alexis Monville au Cesi de Blanquefort.

La présentation de Scrum en 5minutes par Alexis était excellente :

  • un flot bien maîtrisé,
  • aller à l'essentiel 
  • laisser le temps pour des questions
J'ai ensuite joué au Légo4Scrum. Nous étions deux équipes de 7 "agilistes" pour réaliser la ville idéale d'Alexis ( maître du jeu et Product Owner).  une très bonne simulation de la mise en oeuvre de Scrum sur un projet qui illustre différentes problématiques : 
  • estimation
  • priorisation
  • compréhension du besoin
  • critères d'acceptation
  • Scrum de Scrum avec deux équipes
  • les itérations (on en a fait 3)
  • la rétrospective

et j'en oublie certainement....

Merci aux organisateurs et au Cesi pour l'accueil.

J'ai pris deux photos postées sur Meetup.

mardi 18 septembre 2012

Les chaises non musicales

Le support d'animation de la session :

Dans la salle, nous avons placé autant de chaises que de participants, plus une. L'objectif pour l'équipe était d'empêcher l'organisateur de prendre place sur la chaise vide.





Voici le tableau des résultats présentant les temps de chaque itération :




Les détails du jeu sont décris dans la présentation.
Le jeu s'est déroulé en plusieurs itérations, et l'équipe disposait de 10 minutes entre chaque itération afin de s'auto-organiser
Afin de capitaliser le déroulement du jeu, nous avions deux observateurs, Cécile et Rémy.
Cécile a pris des notes, des photos et des vidéos. Voici son compte rendu :
  • It 1 : discussion stratégie : max 5 intervenants :
    • les idées fusent mais pas de prises de décision de celles qu’on retient
    • 1 minute restante annoncée : pas de stratégie « validée »
    • => Résultat : 6 s
  • It 2 : quasi les mêmes intervenants :
    • toujours des idées qui fusent dont certaines mêmes pas entendues
    • timing demandé à Olivier
    • départ du jeu avec une nouvelle stratégie «votée » en dead line
    • pas de communication dans le jeu
    • => Résultat : 7.7 s
      vidéo réalisée)
  • It 3 :
    • bonne écoute
    • décision d’un observateur
    • nouvelle stratégie
    • pas de gestion du timing : toujours Olivier qui les informe
    • => Résultat : 1.2 s
  • It 4 :
    • les groupes de discussion se forment => plus du tout d’écoute
    • personne ne pense à l’observateur
    • recherche d‘amélioration de la stratégie : 2 rôles mis en place (cercle intérieur et extérieur)
    • pas de gestion du timing
    • => Résultat : 6 s
  • It 5 :
    • l’observateur est écouté
    • Olivier propose la communication dans le jeu => idée écartée une nouvelle fois
    • recherche d‘amélioration de la stratégie
    • toujours les groupes chacuns dans leurs coins
    • proposition d’un test, mais non réalisé
    • pas de gestion du timing
    • en dead line : on fait quoi ?
    • => Résultat 13.5
  • It 6 :
    • idem précédemment
    • un intervenant (Rodolphe) annonce qu’il y a plusieurs conversations !
    • => 10 s
Rémy a observé les comportements et les a classé en "comportements adaptés (CA)" et "comportements inadaptés (CI)"

Qu'avons nous appris?

  • La simplicité
  • La confiance
  • Le travail d'équipe
  • les itérations
  • L'auto organisation
  • La rétrospective
  • L'esprit d'équipe
  • Le Time Boxing
Evaluation ROTI, 16 votes pour 19 participants

mardi 4 septembre 2012

Mêlée : retour aux fondamentaux

Notre équipe accueil deux nouveaux équipiers, et bientôt nous serons 7.

Lors de la dernière rétrospective de Sprint nous avons choisi comme amélioration de revenir aux fondamentaux de la mêlée : 

  1. qu'ai-je fait hier 
  2. quels problème ai-je rencontré 
  3. que vais-je faire



  • A la question "qu'ai-je fait hier", il convient d'indiquer le reste à faire sur les tâches non terminées.
  • A la question  "quels problème ai-je rencontré" il est important de ne rien dire si il n'y en a pas eu. Si on en a eu, il ne faut pas rentrer dans les détails, il seront discutés hors mêlée. Le but est de trouver le ou les interlocuteurs au sein de l'équipe qui qui nous aiderons à débloquer la situation.
  • A la question "que vais-je faire", simplement prendre et lire à haute voix les post-its qui correspondent aux travaux que vous souhaitez/devez faire aujourd'hui.  


Si on veux garder l'attention de toute l'équipe et encore plus des nouveaux arrivants tout en ne dépassant le 1/4h, il ne faut pas s'étendre sur les sujets. Nous avons la possibilité de détailler au PO ou membres les plus concernés plus tard dans la journée. Cela peut éventuellement donner lieu à la création  d'une tâche non planifiée que l'on ajoute pendant la mêlée. 

Premier bilan à 6 équipiers nous avons traité toutes nos activités en 9 minutes. Si on continue comme ça, tout ira bien.

Notre tableau de suivi après la mêlée de ce matin :

Tableau de suivi des tâches, Sprint 44