De retour de Mix-IT Lyon

03 May 2012

Jeudi dernier, j’ai eu l’occasion de me rendre à Lyon pour assister à Mix-IT, une conférence dédiées aux techologies liées à Java et au Web, et à l’Agilité. Une conférence pendant laquelle j’allais pouvoir enfin expérimenter certains jeux et surtout retrouver les collègues du dernier Agile Open Sud.

Mon programme était centré sur les jeux, et notamment le Sky Castle Game d’Antoine, Fabrice et Philippe, ou l’expérience des billes de Rouges de Alexis « Deming » Monville. J’avais également proposé un lightning talk intitulé « Le seul échec c’est celui de ne pas apprendre », et l’ai donc soumis au vote du public. L’ayant proposé assez tard je ne pensais pas qu’il serait retenu, puisque seuls les 10 premiers l’étaient. Il finira 6e ! 🙂

Et en préparant ma venue, une fois le calendrier publié, deux surprises :

• La première était que j’allais raté le Sky Castle Game : les lightning talks étaient prévus en même temps !
• La deuxième était que Claire Blondel, dont je parle dans mon lightning talk, était prévue en keynote ! Cela allait me faciliter la tâche pour faire passer mon message !

L’expérience des billes rouges

C’est un atelier auquel je vous conseille de participer. Là nous avions une heure et c’était peut être un peu court. Pour ma part, j’ai joué (très mal) le rôle de chef de la qualité. Je ne vous raconte pas le jeu, mais l’idée est de mettre en avant les 7 maladies d’une organisation et les 14 « points » de Deming. Expérience très intéressante, et donc trop courte. 🙂

Backbone.js

Je ne voulais pas nécessairement suivre des sessions techniques mais finalement j’ai suivi le flot… Tant qu’à faire, autant apprendre quelque chose ! Même plusieurs choses puisque je ne connaissais ni Backbone ni CoffeeScript, langage utilisé lors de la démo.

J’ai d’ailleurs trouvé ce langage très intéressant, et sa syntaxe assez naturelle. Je ne sais pas si j’ai bien compris, mais j’ai l’impression qu’on peut s’abonner à un événement « appel de méthode », du style messages.on(« reset », this.render, this);. Ce qui permet à une vue de réagir au changement du modèle (dans le cas de Backbone) ou de faire de l’AOP. Intéressant… Mais je ne sais toujours pas si cela vien en effet de CoffeeScript, Underscore.js ou Backbone… Une idée ?

Backbone, lui, est un framework assez complet pour faire des applis Web assez facilement sur base de REST, Page-Controller, etc. A suivre donc…

Lightning Talks

La déception de ne pas jouer au Sky Castle Game passée, je me suis rendu aux lightning talks. Et c’est JB Dusseaut d’Arpinum qui a démarré avec « La voie du programmeur », que je vous invite à regarder. C’est cette session qui a eu le plus de voix lors du vote, et c’était à mon sens effectivement la meilleure, mais je vous laisse vous faire votre idée.

J’ai bien aimé aussi le concept de Developer Experience (DX) présenté par Pamela Fox. L’idée est que de la même façon qu’on fait de l’UX pour l’interface, il faut faire du DX lorsqu’on conçoit une API ou un framework. L’idée est de rendre son utilisation la plus naturelle possible.

Puis au bout de quelques unes, c’était à mon tour… quel stress ! J’ai déjà donné des sessions classiques d’une heure. Mais là le format 5 minutes, faut pas se planter sinon c’est mort ! On verra bien au montage le rendu final, mais je n’étais pas totalement satisfait. Soit, ce n’était qu’une expérience de plus dont j’essayerai de tirer les enseignements 🙂 (sujet du discours). Si vous voulez la version développée en attendant la vidéo, suivez ce lien.

Enfin celui d’Alexis Monville m’a bien plus. Plus que le fond, avec lequel je suis totalement en phase, j’aime bien la façon dont Alexis présente les choses, en posant des questions, et en laissant parfois des grands blancs. Le message passe mieux que quelqu’un qui parle en flux continu (comme moi) et où finalement on retient moins de choses.

L’Agile chez Google

Je ne sais pas si je me suis rendu à cette session parce que c’était Google, ou parce que c’était Petra Cross… 🙂 En tout cas, elle sait faire en sorte que son auditoire l’écoute religieusement ! 🙂 Avec JB, on s’est calé dans des transats disposés dans le couloir, vu que la salle était pleine. Il ne manquait qu’un petit pastis 🙂

Pour en revenir au sujet, rien de très extraordinaire chez Google. Google semble être agile. Bonne nouvelle ! Evidemment ils ne font pas de Scrum, mais plutôt du Kanban, même s’ils planifient toutes les semaines. D’ailleurs cela m’a poussé à me poser cette question : peut-on faire autre chose que du Kanban lorsqu’on déploie continuellement, plusieurs fois par jour ? Ils font aussi un peu d’XP, mais pas tout… (RIP Antoine, JB, Thierry, Sylvain, etc. 🙂

Un sujet qui m’a marqué est la volonté de Google de limiter le plus possible le temps de réunion. Cela se traduit par des réunions de planif de 30 minutes max, des rétrospectives hebdomadaires de 15 minutes, assez efficaces, mais aussi par l’abandon des daily standups, considérés uniquement comme un outil pour les managers. Je retiens cette idée de vouloir rendre les réunions plus efficaces. En revanche, la rétro de 15 min me parait trop courte, ou alors avec une sacré expérience. L’abandon des daily standups va trop loin à mon sens. Surtout qu’il est perçu comme un outil pour les managers, or ce n’est pas son rôle. Personnellement, je remets pas mal en cause le fameux format des 3 questions. Non pas les questions elles-mêmes mais le fait qu’elles soient posées individuellement. Elles sont parfois mal comprises, et utilisées pour du reporting. Or ce n’est absolument pas leurs rôles. Dans le même esprit, je commence à chercher une façon d’abandonner les points pour les estimations…

Le DotGame

Je me suis ensuite précipité pour aller jouer au Dot Game d’Oana Juncu. L’idée est de fabriquer des pizzas et mettre en oeuvre les principes du Kanban. La base est très intéressante. On s’est pour le coup bien amusé. Je suis resté toutefois un tout petit peu sur ma faim pour plusieurs raisons :

• Le jeu ne tient pas en pas en 1h ou alors en limitant le nombre d’itérations. Il y a à mon sens un temps minimum de rétrospective entre les itérations qui est nécessaire, sans lequel on peut avoir du mal à apprendre pendant le jeu.
• Une rétrospective finale a aussi manqué, mais par manque de temps là encore.
• En fait, on est dans le vrai Kanban, celui de Toyota. Donc il faut aller au bout. Et son objectif est plus de faire de la qualité totale que d’aller vite. Or là on était purement dans de la précipitation, sans prendre en compte la qualité. Je pense qu’il devrait y avoir des critères plus stricts là dessus. Car soyons clair : ce qui donne le sentiment d’aller plus vite, c’est que la qualité est obtenue du premier coup !

En tout cas, toutes ces raisons me poussent à y rejouer !

Anatomie d’une mission agile

Enfin, je suis allé écouter religieusement et boire les paroles de Pablo lors de cette session que je connaissais déjà, et que je vous invite à voir. L’exercice n’est pas simple car c’est un retour d’expérience d’une mission de coaching par le seul coach (en l’absence du client). Cela peut parfois être interprété comme une volonté de se mettre en avant en faisant la part belle aux réussites.

Mais ce n’est pas le cas de cette session. Elle vise simplement à alerter qu’une transition agile, quelle qu’elle soit, n’est pas simple ni de tout repos, et qu’elle nécessite une prise de recul que seul quelqu’un qui a vécu plusieurs expériences peut amener. Attention, on peut prendre un coach, mais on peut aussi embaucher ! Sur la forme, après avoir vu les prémisses de cette session, le discours de Pablo est aujourd’hui arrivé à maturité, ce qui est finalement on ne peut plus normal après plusieurs expérimentations.

Des rencontres, des retrouvailles

Voilà donc une journée bien remplie, jalonnée de discussions sur des sujets plus ou moins sérieux avec quelques personnes de la communauté. On s’est bien marré, et ça donne forcément envie de se retrouver ! Rendez-vous lors de prochains événements, Agile France fin mai à Paris et, peut-être, Agile Innovation à Lyon au mois de juin !