Agile France 2010 – Jour #1
| Florence Chabanois et moi même Claude Falguière étions à Agile France 2010 au début du mois. Avec pas mal de retard un retour à quatre mains sur Agile France 2010 et les sessions qui nous ont intéressées. |
Agile France 2010 “conférence agile sur les méthodes agiles” se déroulait cette année au Chalet de la Port Jaune, un très beau site près du château de Vincennes. Plus de 300 personnes se sont déplacées, un record pour cette conférence.
Suite au changement de nom de XPDays à Agile France l’audience a un peu changé et mêle les XP guys de longue date et des curieux venus découvrir le monde Agile et SCRUM. Cela explique probablement aussi la présence de bien plus de filles que l’année dernière.
L’ambiance était décontractée, les échanges nombreux favorisés par le buffet présent en permanence, la qualité des repas, les pauses suffisamment longues pour aller faire un tour au buffet, et des activités d’animation pendant ces pauses.
Beaucoup de contenu car les sessions se sont déroulées sur 6 salles (voir 7 par moment). De nombreux sujets sur Scrum, TDD, la gestion de configuration logicielle et toutes les techniques de l’agilité. Quelques sujets un peu plus techniques et pas mal de présentations sur la communication pour s’ouvrir l’esprit. A commencer les deux keynotes.
Si vous voulez voir le programme vous le lirez mieux là.
La coder Academy
Agile France 2010 a introduit une compétition en 3 manches entre développeurs lors de pauses déjeuner et avant le diner : la Coder Academy.
Le but était principalement de montrer des applications réelles de TDD sous la forme de Coder Dojo. Si le terme Coder Dojo ne vous dis rien vous pouvez vous référer à la présentation d’Emmanuel Gaillot qui était là aussi en tant que membre du jury.
Les sujets donnés au hasard étaient des Kata en 7mn soit TDD à partir de rien, soit Refactoring en TDD d’un code de son choix.
A l’exception de Christophe Thibaut et Jonathan Perret qui ont présenté un kata en Haskell, tout le monde a fait du Java, avec des variantes comme Play! ou Groovy.
La finale s’est déroulée en figure imposée : implémenter la liste des n premiers nombres premiers en TDD à partir de rien en Ruby en randori (chaque équipe passe à tour de rôle pour 5mn sur le même code).
Le véritable enjeu était le temps. 7mn c’est très, très court quand on est de l’autre côté du clavier, et probablement très, très long pour les gens qui nous voient peiner 
. Mais certains kata on été très réussis.
Si après ça vous êtes tentés vous pouvez rejoindre plusieurs des participants de cette Coder Academy au coding dojo qui est organisé tous les lundi soir à Paris. Il y en a aussi deux autres, mais on verra ça une autre fois.
Les photos de la Coder Academy illustrent ce post en fil rouge.
La keynote de Bruno Sbille
Claude Falguière et Florence Chabanois
La keynote de Bruno Sbille “PNL et Agile: les yeux, les oreilles et les sensations” nous a présenté rapidement comment utiliser les méthodes de la PNL pour améliorer notre communication dans un projet Agile.
La PNL ou Programmation Neuro Linguistique est un ensemble de méthodes déduites de l’observation de gens efficaces.
Le premier point traité par Bruno Sbille est qu’il faut savoir interagir avec les auditifs, les visuels et les tactiles/kinesthésiques sur des canaux différents sinon ils ne comprennent tout simplement pas.
Comment les reconnaître ? Les types de verbes utilisés sont un critère. Les auditifs utiliseront plutôt des descriptions verbales assez longues, les visuels des dessins, les kinesthésiques des interactions physiques et des ambiances. Les différents systèmes de représentation sont traités dans la PNL sous le terme VAKOG si vous voulez aller plus loin.
La seconde partie de la keynote de Bruno Sbille a commencé par des scénettes de la vie quotidienne (qui n’a pas oublié de reboucher le dentifrice un jour). Dès qu’il y a plusieurs personnes dans une équipe elles peuvent créer un triangle dramatique et se livrer à des jeux psychologiques plus ou moins conscients. Le triangle comporte 3 rôles : le persécuteur, la victime, le sauveur, et le jeu peut commencer à 2 joueurs en configuration victime/persécuteur ou victime/sauveur.
Chaque type de rôle trouve un intérêt à le jouer, y compris la victime, qui peut d’ailleurs être la source du triangle en attirant aussi bien les persécuteurs en puissance que les sauveurs.
Ces jeux sont nuisibles pour l’humeur de l’équipe, car ils créent des conflits ou des dépendances excessives. Paradoxalement, le sauveur aussi est problématique car il peut en arriver à prendre en charge le travail de tout le monde.
Vu qu’il y a probablement quelques sauveurs par ici, je vous délivre le message : Quand sauver ?
- est ce qu’on me le demande ?
- est ce que j’ai le temps ?
- est ce que j’en ai les compétences ?
- est qu’il y aura un échange ?
et si jamais le sauveur prend la décision de sauver il faut rendre la “victime” active en lui demandant de prendre en charge 50% du travail.
Keynote intéressante mêlant habillement le visuel, l’auditif et le kinesthésique et beaucoup de matière à réflexion sur nos agissements.
Au delà de l’équipe, l’entreprise agile, par François Bachmann
Florence Chabanois
Les points importants : auto-organisation, auto-organisation, auto-organisation et pour que ce soit possible, il faut fournir un conteneur (C), un cadre dans lequel l’équipe puisse s’exprimer. Une équipe à qui on dicte la conduite en disant “va à droite, à gauche, tout droit” fonctionnera forcément moins bien qu’une autonome. La dissonnance (D) et les erreurs doit également être acceptée pour que la créativité soit possible. Les échanges (E) doivent abonder : plus de communication et moins de docs. C’est le CDE.
François Bachmann aborde également le problème de la gestion des ressources humaines : comment “récompenser” l’agilité, et sur quels critères? Par analogie, comment évaluer les performances d’un footballeur ? Si l’on mesure les mètres parcourus, d’une part le but final de gagner des matchs n’est pas forcément atteint, d’autre pas le footballeur risque de ne faire que cela, sans s’intéresser au reste. J’ai aussi envie de dire que le système de récompense peut être pervers dans le sens s’il faut systématiquement “payer” les pots cassés quand l’on se trompe. On risque de se renvoyer la patate chaude pendant que personne ne prend de responsabilités.
La résistance à l’agilité peut avoir plusieurs causes :
- la perte de contrôle liée à la promotion de l’auto-organisation, même si le contrôle n’était qu’une illusion
- l’équipe se considère déjà agile et il n’y a pas de problèmes, tout va bien. En fait les problèmes sont dissimulés au lieu d’être montrés au grand jour.
- certaines personnes aiment suivre des règles
- la motivation baisse
- “c’était mieux avant” (pour l’équipe, pas pour le client…)
- l’expert ne trouve plus sa place
Quelles directions à suivre :
A faire
- Former les équipiers, sur de la technique mais pas seulement. Promouvoir des façons de pensées et des approches différentes.
- Avoir un véritable projet pilole qui apporte de la valeur pour le client
A éviter
- Changer les noms et garder les mêmes rôles. Le “chef de projet” est maintenant un “scrum master” et il fait exactement la même chose qu’auparavant…
- Conduire un changement “big bang” : “A partir d’aujourd’hui, tout le monde ici est agile !”. L’adaptation doit se faire graduellement.
Et pour finir, cela sent mauvais si :
- La décision de passer à l’agilité est un ordre du management
- On veut des résultats immédiats. Il faut le temps qu’il faut, comme pour apprendre le vélo.
- Il y a un acharnement sur les termes agiles : “backlog”, “scrum”.. ces mots font peur ! Il vaut mieux se concentrer sur les idées plutôt que les étiquettes.
- Scrum est vu comme une solution magique. Scrum donne des pistes, un cadre mais il faudra forcément plus pour guérir.
- Les bonnes pratiques sont aveuglément suivies. Il faut aussi comprendre le pourquoi, voir si elles s’intègrent dans notre organisation et les faire évoluer après. François évoque à ce sujet un livre sur les 40 entreprises qui marchent, dont la plupart avaient coulés dix années après. Chaque organisation est unique et il n’y a pas de solution universelle.
Le Lean Office : améliorer la performance administrative, par Michel Baldellon
Florence Chabanois
Michel Baldellon montre par les chiffres qu’un “petit” problème peut, à force d’être répété, devenir insidieusement le coeur du travail d’une entreprise. L’exemple ressemblait à cela : considérant qu’il faut une unité de temps pour faire un rapport, et que l’imprimante en abime 1 sur 10 (on se dit que c’est tolérable).
- 10 rapports faux => 10 unités passés à les faire
- 90 rapports bons => 90 unités passés à les faire
Pour détecter que le rapport est en erreur et le corriger, il faut 10 fois plus de temps.
Sur les 100 initiaux, voici les couts :
- 10 rapports faux : 110 (10 + 100)
- 90 rapports bons : 90
On passe au final plus de temps sur la partie boguée qui semblait minime que sur le coeur du métier.
Trois points sont soulignés !
- Management visuel. Utiliser des couleurs pour donner du sens. L’exemple cité est celui d’un bureau désordonné comparé à une étagere avec classeurs post-ités
- Identification du gaspillage. L’exemple évoqué est celui du bac rouge dans une usine, qui recueille les produits défectueux. La ligne de production est continue (“flow continu”), simplement les problèmes sont mis en valeurs et isolés pour pouvoir être traités plus tard.
- Méthode de résolution de problème. Une fois qu’une cause est identifiée, elle est affichée. A chaque fois qu’on la rencontre, on trace un trait. On voit ainsi facilement que la cause 1 est survenue 30 fois alors que la cause 2 est apparue une seule fois. On peut ainsi objectivement traiter la plus importante. Il rappelle aussi que traiter un problème tout de suite permet de ne pas avoir de documentation à écrire et à maintenir et nous épargne de la resynchronisation.
Voici d’autres points soulevés, en vrac :
- quand on veut obtenir quelque chose, plutot que simplement le demander, montrer en quoi il y gagne (ex : on ne peut pas vous payer car il manque le numéro de facture).
- certains services aiment le gaspillage, cela rend la “vie moins monotone”, cela rassure car on sait le traiter. La cause profonde d’un problème n’est pas intéressant, on connait le contournement. La démarche “Qualité totale” n’est pas universelle, et dans certains services moins que d’autres.
- notion de file unique. Avoir des files spécialisées favorise les situations où certaines sont pleines et d’autres vides. Plutôt qu’avoir des personnes dédiées, il vaut mieux des gens polyvalents. La présence de guichets simples permet aussi d’accéler le flux (exemple des caisses pour panier de moins de 10 articles dans les supermarchés).
Un article sur le Lean Office est en ligne sur le site de Michel Baldellon.
Benoit Gantaume : Introduction au processus de pensée visuelle / Sortez vos crayons
Claude Falguière
Cette série de sessions s’appuie sur la méthode Visual Thinking que Dan Roam a exposé dans son livre Back of the Napkin (site web très dynamique et la présentation des principes de la méthode dans le livre blanc est très percutante)
La présentation a duré 4h (1h le matin et 3h l’après midi). D’abord quelques explications des concepts puis un atelier pour expérimenter ces concepts.
Le visual thinking est une technique d’utilisation du dessin pour résoudre des problèmes et exposer une idée.
L’idée a germé quand Dan Roam a gribouillé un dessin sur le dos d’un nappe pour expliquer une idée. Puis il a complété ses recherches avec des éléments provenant d’études sur le fonctionnement du cerveau.
Le but n’est pas de faire des jolis dessins mais des dessins qui donnent du sens et avec des moyens très simple de type papier/crayon.
La technique exposée permet d’organiser la démarche qui permet de collecter les informations, les organiser, compléter ces informations en imaginant les éléments qui manquent puis présenter le résultat obtenu.
Elle est guidée par deux axes :
- le type de questions que l’on peut poser : qui/quoi, quand, où, combien, comment, pourquoi ou les 6W (toutes ces question comportent un W en anglais)
- la façon d’aborder ces questions résumé par SQV1D qui force notre imagination a entrer en jeu pour examiner le problème sous plusieurs angles avec des oppositions.
L’auteur propose en ensuite des modes de représentation adaptés à chaque type de question selon l’angle sous lequel on veut les traiter.
Le speaker Benoît Gantaume a présenté la méthode et des exemples d’utilisation. Il a animé plusieurs ateliers portant sur les différentes techniques. Le plus long en fin d’après midi sur SCRUM en images a donné quelques jolies oeuvres qui ont été mises en ligne là par Benoît Gantaume.
Je reproduit le dernier qui vient de mon équipe car il a mené à un délire collectif sur le client envoyant ses specs par dessus les creneaux de la tour qui restera un souvenir mémorable de cette session d’Agile France.
Une présentation très intéressante mais qui aurait gagné a être un peu plus rapide.
Fin de la première journée
Journée bien remplie. Pour celles et ceux qui sont restés au repas c’est l’heure d’aller diner et d’avoir des discussions passionnantes avec les autres participants et les speakers.
Les textes sont de Florence Chabanois et Claude Falguière. Les photos sont d’Eric Lefèvre et Claude Falguière.