Agile Tour Marseille 2011 (retour)

Le 13 octobre dernier, j'ai assisté et participé à l'Agile Tour Marseille 2011, en voici un petit retour, selon quelques prises de notes que j'ai pu faire.

Un document agile se promène un fil - Jean-François Jagodzinski

J'ai choisi cette session pour avoir l'approche de JF sur la documentation en contexte agile.

JF commence par dresser l'approche "classique" où la documentation est au centre du système, entre "Information", "Process" et "Travail". Intéressant de noter qu'il peut se passer des mois de "travail", permettant de produire de la documentation mais ... aucun produit : bonjour le ROI !

J'ai bien aimé la vision en cascade du cycle de vie d'une documentation de type spécification : collecte du besoin, analyse, conception, puis réalisation. JF plaque sur ce schéma le fait que, dans la réalité, les individus vont osciller entre ces différents états. Par exemple, dans la phase de collecte ou d'analyse, il est fréquent de faire un aller-retour vers l'état plus technique (réalisation par exemple) pour vérifier la faisabilité. De même, dans les phases de conception ou réalisation, il n'est pas rare de revenir vers l'état de collecte pour approfondir le besoin. Ajoutons à cela que chacun oscille différemment, et c'est l'anarchie, l'incompréhension, le déphasage, .... l'échec.

D'où l'idée en agilité de favoriser les échanges entre individus pour exploiter positivement ces oscillations ...

J'ai noté en vrac :

• Le travail peut être du plaisir (j'aime !)
• Il faut éviter le filtrage de l'information, d'où l'idée en contexte agile que l'équipe soit en contact direct avec la source pour faire son propre tri de l'information utile
• La documentation doit avoir de la valeur métier, doit prendre moins de temps et moins d'espace
• Favoriser l'accès et l'utilisabilité de la documentation, ainsi qu'une saisie rapide et facile, et une gestion minimum (exemple : Wiki bien sûr !)

JF est ensuite passé à une représentation intéressante de la documentation en contexte agile, avec tous les éléments la constituant : la vision, le product backlog, les conditions de satisfaction, les contenus d'itération, les spécifications exécutables, les tickets, etc ... L'idée suivante m'a beaucoup plu : il est possible à partir de ces éléments de reconstituer intégralement une documentation "classique" (planning, specs, PAQ, etc ...). Et oui, on a tout mais sous une forme différente !

Un membre de l'auditoire a posé des questions sur le planning, en expliquant qu'en méthode classique, grâce à son planning, il sait qu'il aura telle fonctionnalité au mois de mars. Pour moi, c'est un leur, tout comme un contrat au forfait en mode classique : un leur je vous dis ! Mais j'y reviendrai dans un prochain article ... Mais pour moi, un planning est prévisionnel mais jamais prédictif ....

Session intéressante, une approche différente et transversale de tous les éléments de l'agilité et de Scrum, au travers de la documentation.

"Marshmallow challenge" - Pablo Pernot

L'intitulé de la session de Pablo ne laissait pas entrevoir ce jeu, je ne sais pas pourquoi : "Planification et itération : itérations, redéfinition, équipe hétérogène". Mais bon, peu avant les sessions, j'ai su qu'il s'agissait d'un "Marshmallow challenge". J'ai donc choisi cette session car je n'ai jamais assisté à des jeux à objectifs pédagogiques pour l'agilité (à part le "Scrum Tower Game" que j'ai mis au point pour ma journée d'introduction "Agilité et Scrum").

Je n'ai pas été déçu. Pablo a la pêche ! Et c'est tant mieux, ça se prête bien au contexte.

Je ne reviens pas sur le jeu pour lequel on peut trouver plein d'informations sur le site http://marshmallowchallenge.com/. Ce qui est intéressant c'est qu'il a été joué par des milliers de personnes, et donc qu'il existe des statistiques très intéressantes dont Pablo nous a donné un aperçu : les enfants réussissent mieux que la moyenne, les équipes hétérogènes en profils réussissent également mieux, etc ...

Tout comme pour ma session (voir ci-dessous), je pense que l'intérêt dans une telle conférence mais pas tant l'intérêt pédagogique du jeu, mais plus sa découverte pour le mettre en pratique. Pablo m'a semblé surpris, voir déçu peut-être, des conclusions qui pouvaient être tirées de cette session. Mais pour moi, le contexte n'est pas comparable à celui d'une entreprise où un coach intervient, le public présent est très différent avec des attentes tout autres.

J'ai donné un ROTI de 5 à Pablo car je n'ai vraiment pas perdu mon temps, j'ai pu voir une façon de mettre en place et animer cet atelier, ça m'a donné envie de creuser ce jeu pour peut-être l'utiliser dans mes propres interventions.

Coding-dojo ou l'apprentissage du TDD - Xavier Nopre

Franchement, je ne me sentais pas les épaules pour être "orateur" dans une conférence. Mais finalement, grâce à la convergence de différents éléments, je me suis lancé, j'ai proposé une session "Coding-dojo et TDD" qui a été retenue.

C'est une animation que j'ai fait plusieurs fois en entreprise, mais là, le contexte était différent : les gens ne se connaissent pas, ils ne sont pas censés tous participer, ils ont probablement des niveaux très différents (plus qu'au sein d'une même entreprise).

Ce qui me faisait donc presque le plus soucis était la façon de faire passer les personnes au clavier. En entreprise, je mets tous les noms sur des papiers dans un chapeau et on tire au sort. Là, j'ai laissé faire, et ça a bien fonctionné, il ne m'a manqué personne durant la session.

Public varié ? Oh que oui ! Entre ceux qui ne connaissent pas le TDD et celui qui ne fait que ça depuis 7 ans ! Mais également sur les capacités de développement, d'improvisation, de frappe, d'expression, etc ... Sans compter qu'en passant devant les autres, on perd pas mal de ses moyens. Mais tout cela était très riche.

Il y avait également la question du choix des sujets. Le sujet doit être simple et très abordable pour les participants pour garder le focus sur l'objectif pédagogique (par exemple, le TDD) et éviter de perdre du temps dans des recherches algorithmiques ou autres. J'avais pensé que le public serait hétérogène mais d'un niveau minimum, surtout s'il venait à cette session, et ça a été le cas, apparemment, les sujets n'ont pas posé de problèmes, nous avons pu mettre l'accent sur le TDD.

Un autre point que j'ai pu vérifier (après l'avoir vérifié la veille en entreprise) : le coding-dojo est accessible à tous, quelque que soit le langage, quelque soit le profil. Pour le langage, certains sont passés au clavier en ne connaissant que le C et ils ont codé en Java sans problèmes apparemment, avec l'aide de l'assistance, nous sommes bien dans un travail collectif. Mais ceci s'est également vérifié pour les profils, certains n'étaient visiblement pas ou plus trop "technique" (comme par exemple un chargé de recrutement), et eux aussi ont pu s'essayer sans problème à prendre leur tour de rôle au clavier.

Au final, les retours sont très positifs, ça fait plaisir. Surtout que c'était réciproque, j'ai moi aussi eu grand plaisir à expliquer et montrer ce qu'est un coding-dojo, et en guise d'exemple, le TDD et la vision que j'en ai. Donc, un grand merci à Karine pour sa stimulation et ses bons conseils, aux participants à ma session qui ont bien joué le jeu, à toute l'équipe d'organisation pour ce bon moment, ainsi que le repas entre orateurs. Bravo !