Mission de coaching

Depuis début Mai j'ai commencé une mission de coaching agile chez un nouveau client.

A fin juin, après une formation à Scrum, et plusieurs journées de collaboration nous avons mis en place l'organisation du projet sur des voies agiles. Tout n'est pas parfait, mais nous progressons.

Un wiki projet pour travailler et valider les travaux suivants

• définition des exigences avec le métier
• maquettes d'écran conçues par un ergonome
• scénarios de navigation
• afficher la roadmap et le release plan
• centraliser les documents projet

Une Backlog Produit a été commencée bien avant mon arrivée pour travailler avec le métier. Elle est déjà trop détaillée mais nous ferons avec.

Un tableau Kanban pour

• suivre l'avancement de l'expression des exigences 
• suivre les travaux et de recette
• mesurer les temps de passage des fonctionnalités dans le wokflow
• fluidifier les travaux du Product Owner, de la MOA et des utilisateurs
• s'assurer que l'équipe de développement ait assez de User Stories prêtes à chaque Sprint

Une liste des problèmes et des urgences

• pour connaitre les problèmes
• suivre leur résolution

Tableau de suivi Kanban et de suivi des erreurs (initialisé)

Graphique de suivi du tableau Kanban (projection)

BurnUp de Produit et vélocité de l'équipe Scrum (projection)

Le Sprint 0 est prévu pour le mois d’août,

En septembre, après les vacances (si tout va bien ...) nous commencerons les premiers Sprints

Scrum Café #7

Session intéressante qui s'est déroulée le 10 Mai 2012.

J'ai commencé par une présentation sur les Personnas et la vision Box (cf posts précédents)

Nous avions ensuite trois ateliers en parallèle :

•   présentation de Scrum en 5 minutes (20 en vrai) que j'ai animé
•   atelier du groupe MOA
•   atelier du groupe Test

Ci dessous l'évolution des indices de satisfaction de la première à la dernière session :

En progrès

Pour la session 8, j'organiserai un "Penny Game" :
Philippe Launay nous l'a présenté au dernier Scrum Wine Bordelais, un excellent jeux de simulation...

Son succès dépendra donc de l'animateur....

les Personas du Scrum Café

Ils sont tout frais, et la peinture n'est pas sèche. Nos Personas sont en cours de réalisation....


Il s'agit donc du public intéressé par nos Scrum Café. Nous devons veiller à ce qu'ils obtiennent ce qu'ils attendent, sinon ils ne viendront plus. 


Même si nous connaissons personnellement chacun des membres du Scrum Café, la démarche "Persona" + "Vision Box" révèle des aspects intéressants sur nos clients.


Ci-dessous, le travail réalisé :

Vision Box pour les Scrum Café

Une vision Box pour les Scrum Cafés organisés chez nos clients

La boite est réutilisable à chaque session, il suffit de changer un post-it!

En la réalisant conjointement avec des Personas, je me suis posé de nouvelles questions. L'exercice est très intéressant et les membres de l'équipe ont fait part de leur remarques de suite.

Cette technique issue de l'Agile-UX (Agile User Experience) tend à capitaliser les expériences utilisateurs. A vrai dire, je voulais commencer par les Personas, mais je me suis rendu compte qu'il serait plus profitable de les réaliser en même temps.

Une fois la box et un premier Persona terminée et c'est comme un déclic : on comprend mieux les spécificités du produit, et c'est tellement facile d'en parler, l'utilisateur est comme présent pour jouer son rôle...

Les Personas donnent vie aux utilisateurs et sont un puissant outil de communication dans l'entreprise. De même pour la "Vision Box" vous incite à mettre en valeur ce qui va attirer vos utilisateurs, ce qui va leur donner confiance dans le produit et qui fera la différence par rapport aux autres.

Je vous recommande la lecture des blogs de Jean-Claude Grosjean :

• http://www.agile-ux.com/ 
• http://www.qualitystreet.fr 

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.

Modéle A3 Toyota

Lors du 6éme Scrum Café organisé chez notre client, j'ai présenté 4 types de modèle A3 Toyota à utiliser dans le cadre de projets informatiques :

• La charte de projet / fiche de vision
• Le A3 de résolution de problème
• Le rapport d'avancement
• L'affiche informative

 Vous trouverez également ci-dessous une traduction du modèle A3 résolution de problèmes par Tom Poppendieck et Henrik Kniberg.

Modele a3 toyota v2.0.s37s10

View more PowerPoint from Olivier Patou

Télécharger la traduction (doc)

Télécharger la traduction (pdf)

 Vous trouverez l'original sur le site anglophone Crisp.se (lean)

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