Rétrospective Annuelle et Innovation Games : plans d'actions

Une fois la rétrospective animée, et les résultats collectés, que faire de cette matière brute et comment l'utiliser?

Notre démarche fut la suivante : 
1 - réaliser une synthèse de chaque atelier et des retours du mur de feedback
2 - regrouper les problèmes identifiés par thème et en établir une liste 
3 - attribuer une valeur à chaque problème
4 - attribuer une complexité de résolution à chaque problème
5 - calculer le ROI (valeur/complexité) à chaque problème pour les prioriser
6 - dresser un plan d'action pour les 3 problèmes les plus importants
7 - identifier pour chaque plan d'actions la liste des problèmes adressés

Ce matin, j'ai donc présenté à l'équipe l'ensemble du travail de consolidation, la démarche et les plans d'actions. 

L'équipe a retrouvé dans notre synthèse les éléments qu'ils avaient remonté. Du coup, nous avons eu une bonne adhésion de l'ensemble des acteurs sur les plans d'actions à mettre en oeuvre.

Le plus gros est donc à faire!

Management visuel et amélioration continue

L'organisation des POs

En début d'année je vous publiais un post sur notre mise en oeuvre de Kanban au sein de notre équipe de "PO". Notre objectif était de mieux suivre notre flux de production des US afin d'être en mesure d'alimenter convenablement nos équipes Scrum, de visualiser les goulets d'étranglement et d'améliorer la communication au sein de l'équipe.

Aux mêlées des POs participent : 

• Les POs - 8 personnes,
• Les Chefs de Projet - 5 personnes : exerçant parfois le rôle de PO,
• Les Coordinateurs Fonctionnel - 2 personnes : identifient les impacts entre projet et coordonnent les évolutions fonctionnelles par version (vision macro),
• Les experts métier/testeurs - 2 personnes : aident les POs à la conception fonctionnelle et renforcent leur capacité de test de fin de Sprint. Leur feedback sur la logique métier et le fonctionnel est très précieux,
• Un représentant de l'équipe de graphistes / intégrateurs Web,
• Deux architectes techniques

Lors de nos mêlées, nous tenons le 1/4 d'heure sans dépassement, il arrive même qu'elle soit finie avant la fin du temps. Personnellement, je trouve que nous sommes trop nombreux et que l'on n'optimise pas la communication, mais en même temps cela fonctionne et globalement nous en tirons tous des éléments importants. En attendant que nous trouvions un meilleur mode de fonctionnement, nous continuerons donc nos mêlées quotidiennes à 20 personnes... 


Après 6 mois d'utilisation, nous avons abandonné notre tableau de suivi de la production des US : le suivi au niveau des US trop fin entre la livraison de la dernière version et le lancement des devs de la nouvelle version,

•  les équipes surchargées n'ont plus pris le temps de mettre à jour le tableau trop d'info tue l'info : le tableau devenais illisible tellement il comprenait d'US (nb US >100)
• pour chaque équipe Lors d'une rétrospective nous avons donc décidé d'abandonner ce format pour un autre, mieux centré sur nos problématiques. 

Nous avons mis en oeuvre un tableau affichant la roadmap des projets permettant visualiser les dépendances qui peuvent exister entre projet. 

L'objectif est donc de pouvoir augmenter notre réactivité lors des changements de planification et ainsi de mieux maîtriser notre gestion du périmètre. La roadmap est enrichie de différentes affiches sur sa gauche : Fiche de vision A3 Toyota du projet, tableau de présence/absence....

Pour l'instant tout le monde a mis en oeuvre ces changements sur son projet et nous allons suivre cette amélioration de près afin d'en mesurer les gains et les difficultés rencontrées. 

Reste à faire en sorte que nos mêlées se focalisent aussi sur ces points.

Une mise en oeuvre de Kanban pour l'IT - itération 2

La première version de notre tableau est terminée. Depuis deux semaines, nous avons commencé la mise en oeuvre :

• Initialisation de la backlog des Features
• Harmonisation des backlogs produit 
• Mêlées quotidiennes façon "Scrum"
• Refactoring du tableau Kanban des activités
• Tableau des problèmes et actions pour le facilitateur
• Initialisation des burnups d'activités par projet, et consolidation des résultats

Ce que nous ne faisons pas encore :

• Tracer les dates d'entrée / sortie dans notre système
• Suivre les indicateurs induits par les mesures de temps de passage
• Limiter le WIP (travail en cours par activité)

Voici nos tableaux :

Tableau des problèmes / actions du facilitateur

Tableau des Features pour l'établissement de la Roadmap produit

tableaux de suivi de la production des US

BurnUp d'activité des tableaux Kanban et BurnUp de produit des équipes Scrum 

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.

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.

Scrum Cafe #6 - Le jeu des Post-its

Scrum Café #6

Lors du 6éme Scrum Café, nous avons organisé un atelier pour établir la Backlog d'un groupe de travail sur les Tests.
L'atelier a été très intéressant et on aurait tous aimé avoir plus de temps pour travailler les User Stories, mais nous n'avons qu'une heure à accorder à l'exercice.
Ce jeu permet d'établir les User Stories et de leur attribuer une valeur métier.

Voici les règles :



Le résultat obtenu n'est pas esthétique, mais de vrais sujets ont émergé et c'était le but!

Les observateurs ont remarqué que :

• La rédaction des Users Stoies : Le groupe était silencieux, et le travail studieux
• Le travail en binôme : beaucoup de discussion sur la compréhension des user stories. Les post-its n'étaient pas forcément bien rédigés et le "Afin de" était plutôt flou. Est-ce une User Story ou pas?
• Lorsque le débrief est arrivé, les user stories déja discutées on été rediscutées, et expliquées par celui qui les avait écrites. Il y avait une différence forte entre ce qui était compris et ce qui était souhaité
• Tout le monde à bien joué le jeu

Une fois les post-its regroupés on additionne les points des histoires  identiques. Ce sont généralement 

• les mieux exprimées,
• les utiles au projet
• car elles sont vite comprises et leur intérêt ne fait pas de doute

Si ce n'est pas le cas, la négociation est longue, l'histoire est peu partagée, et n'aura probablement pas les meilleures notes.

Cet exercice est utile lorsque

• l'on veut initialiser ou améliorer une Backlog Produit
• Définir une valeur métier pour des fonctionnalités
• Afin de palier à un rôle Product Owner qui serait partagé au sein d'un groupe utilisateur ou MOA.

Ce jeu peut-être réalisé avec quelques personnes de l'équipe technique afin de bénéficier également de leur créativité, et afin de leur faire partager la vision du produit.