Retour de l’Agile Tour Rennes 2011

Voici le compte-rendu de ma participation à l’Agile Tour Rennes 2011. Je vous avais annoncé mon programme probable dans un précédent billet et, chose assez nouvelle pour moi, je m’y suis tenu alors que j’avais précédemment plutôt tendance à finir mes journées de conférence par vagabonder d’une session à l’autre en cherchant mon graal de la connaissance. Le fait est que je n’ai pas senti le besoin de remettre en question mon agenda en cours de route car tous mes choix se sont révélés payants. Je tiens à féliciter les orateurs des sessions auxquelles j’ai assistées pour la qualité de leur contenu. Mon ROTI de la conférence est un 5 sans hésiter (et ça aussi c’est plutôt rare). 

J’ai commencé la journée par la session Obeya Kanban de Laurent Morisseau. L’obeya c’est le lieu de travail d’une équipe dans le jargon Lean, et donc c’est un terme japonais. Si vous vous intéressez un peu au sujet vous savez qu’on aime bien parler japonnais dans le Lean, non pas parce que ça fait plus intelligent mais parce que ça vient de Toyota (cela dit ça fait aussi plus intelligent lors de vos dîners en société).

Laurent nous présente dans sa session le contenu et la disposition des informations visuelles autour d’une équipe qui fonctionne en Kanban. Laurent nous détaille progressivement les différents éléments de ces supports visuels et, ce faisant, revient sur certains points de l’approche Kanban pour les expliquer. On s’aperçoit au final que toute l’approche se matérialise d’une manière ou d’une autre sur les murs de son Obeya, dans l’une des zones suivantes: la cible, le planning, la tendance, le planning micro, les indicateurs de performances, le suivi des problèmes. Laurent ne se restreint pas qu’à Kanban puisqu’il nous donne également des parallèles avec SCRUM et ce que pourraient être ces différents éléments visuels: la cible est la vision, la tendance est le suivi de la vélocité, le planning est le burndown produit, le micro planning est le tableau d’itération, etc. Au final, derrière le simple titre, la présentation était riche d’informations et couvrait un spectre beaucoup plus large. La partie sur la gestion de la performance était notamment assez musclée. Elle me parle dans la mesure où j’ai un bagage d’ingénieur qualité, mais je suis plus sceptique quant à la généralisation d’une approche de la performance aussi systématique. Malgré ce bémol, la présentation était pleine de conseils utiles. Je retiens particulièrement la conclusion suivante: le management visuel doit être simple et créer un flux d’apprentissage pour l’équipe. Laurent nous indique deux critères de validation d’un bon management visuel: tout peut être dessiné à main levé et les problèmes doivent être visibles.

Sur le deuxième créneau j’animais ma session désormais bien rodée sur le ROI de l’automatisation des tests. J’ai profité de l’occasion pour en faire un remaniement cosmétique important et la rendre plus visuelle.  Je remercie au passage la personne qui m’a prêté son PC car j’ai rencontré des soucis de compatibilité entre mon Mac et le projecteur de l’amphithéâtre.

Pour la dernière présentation de la matinée j’ai choisi la session de Fabrice Aimetti sur la gestion de portefeuille agile. Là-aussi, derrière ce titre assez court se cachait une avalanche d’information et de références. Outre la gestion de portefeuille, Fabrice a parlé de formalisation des user stories, de présence du Product Owner, de planification agile, d’atelier d’innovation, de story map. Ce que j’aime c’est que Fabrice prend un soin tout particulier à citer et afficher ostensiblement ses références. On y trouve d’ailleurs la présence de notre collègue Hollandais Serge Beaumont pour sa définition d’une user story « prête ». J’ai surtout retenu de la présentation de Fabrice une succession de petites expressions croustillantes picorées ça et là ou de sa propre création:

• une vision sans action est une utopie, une action sans vision est un cauchemar
• le cahier des charges est surtout un cahier décharge
• un manager est quelqu’un qui utilise les hommes pour accomplir un travail, un leader est quelqu’un qui utilise le travail pour accomplir les hommes
• Faites développer à des équipes agiles des produits qui méritent de l’être
• Un atelier est une réunion dans laquelle le livrable est fait en séance

J’ai commencé l’après-midi avec l’atelier Problem Solving de Regis Medina. Le principe était de travailler sur la bonne définition d’un problème et pas tellement de chercher à le résoudre en séance. Régis nous a distillé une démarche pour aboutir à un plan d’action. Nous avons appliqué cette démarche par groupe de 3 sur nos propres situations, chacun proposant un problème aux autres pour collaborer sur sa définition. Regis nous a fait successivement travailler sur:

• l’identification du problème
• la formalisation de ses impacts
• la recherche de la situation standard qui n’a pas été suivi
• et les actions à prendre pour observer concrètement les causes du problème.

Il est intéressant de constater que l’on part souvent sur de faux problèmes ou des problèmes mal formulés car découlant de notre interprétation personnelle d’une situation. La formalisation d’un problème est objective et doit se traduire en un écart chiffré entre une situation donnée et le point de vue d’un client. Cet écart est l’expression même du problème. Je retiens aussi la mise en application très concrète de la technique des 5 pourquoi: on va voir 5 fois ce qui se passe (on utilise ses pieds), ce n’est pas un questionnement rhétorique!

Dernière présentation de la journée avec la roue de Demming des projets agiles vue par Thierry Montulé. Et là attention, il fallait attacher sa ceinture, remonter sa tablette, éteindre son téléphone, et surtout brancher son cerveau.

La présentation est partie dans les strates atmosphériques des principes agiles. Lorsque Thierry vous lache sur le ton de la discussion des phrases comme « le respect est une posture d’humilité assertive », vous avez intérêt à ne pas prendre de notes ou twitter ces morceaux choisis au risque de se laisser décrocher rapidement. Au détours de cette présentation à la fois dense et simplement structurée, Thierry présente les valeurs du pragmatisme avec la métaphore d’une voiture: la communication est le volant, le respect est l’embrayage, le feedback est le tableau de bord, la cooperation est l’accélérateur. Il transforme ensuite le triangle de fer des projets classiques en une pyramide mettant en perspective la méthode, les hommes, la structure, et le client. Thierry termine enfin avec sa roue de Demming qui superpose les valeurs du pragmatisme avec celles des processus empiriques, le système PDCA et ses axes d’amélioration. Simple et pourtant inexplicable sans la présentation qui va avec.

Pour laisser mon cerveau se remettre, j’ai terminé ma journée avec des ateliers ludiques organisés par l’équipe d’Agile Nantes. J’ai notamment aimé l’utilisation des origamis pour comparer différentes méthodes des collaboration. Ce qui est intéressant c’est que ce support est déclinable en grand nombre et qu’on peut recommencer le même exercice avec différents pliages pour éviter l’effet d’apprentissage et se concentrer sur les techniques de collaboration. Je pense que cela conviendrait tout à fait pour servir de support à un coach retreat.

Une riche journée donc, et toujours le plaisir d’échanger avec des meneurs du mouvement agile: salutations à Oana, Fabrice, et Laurent. Le plaisir également de croiser Eric un ancien collègue d’une précédente vie professionelle où l’on essayait d’inventer l’offshore à la française. Eric, rejoins le mouvement agile ;)