Je n’ai pas trouvé de traduction évidente pour le terme “unconference” qui décrit des conférences organisées et menées par les participants eux-mêmes. La première conférence du ALE Network (Agile Lean Europe) ne pouvait pas mieux porter son titre. En effet depuis XP2011 à Madrid (et bon sang, il me faut écrire mon feedback du 12 mai car il en traite beaucoup) et le lancement de la première conférence ALE 2011 à Berlin sous l’impulsion -énorme- de Olaf Lewitz on peut voir littéralement émerger une conférence dont la cible est 200 participants, avec 3 mois de préparation et 40 organisateurs. Un défi. Impensable sur la papier, mais les faits montrent que cela semble marcher. Tout est géré au travers du “cloud” (avec Basecamp, Mindmeister, Google apps & Skype). La débauche d’énergie que l’on constate est ahurissante. On a l’impression qu’il y a des appels skype au travers de toute l’Europe tous les soirs. C’est proprement hallucinant. Je disais à certains que cela me donnait l’impression d’être dans un peloton de cyclistes dans un sérieux col, et soudain d’être complètement décroché par une accélération du groupe (car j’essaye humblement de participer, mais je vous assure que par faute de temps je ne suis pas à la hauteur).

La conférence XP2011 s’est déroulée la semaine dernière à Madrid, j’ai eu le plaisir d’y participer. Cela fera l’objet de plusieurs articles sur ce blog car ces deux jours ont été assez denses et pas mal de choses m’ont paru assez intéressantes pour être évoquées.

Je vais commencer ici par vider mon carnet de notes et vous décrire à peu près mon itinéraire. Voici un état des lieux du premier jour.

Une idée me trotte dans la tête depuis quelques semaines. J’assimile mon rôle de coach agile à celui -en quelque sorte : ne me prenez pas au pied de la lettre ! - d’un psychanalyste… Enfin de loin, disons la silhouette du coach agile ressemble à celle du psychanalyste. Je n’ai jamais été psychanalyste, et je ne le regrette pas du tout (argh une confession), mais j’ai tout de même réalisé des études où la philosophie et la psychologie ont pris une part intéressante. Bref je reviens au fondement de ce petit article : j’opère un rapprochement entre le métier du coach agile et le rôle de psychanalyste. Pourquoi ? Comment ?

Dans quelques dizaines de jours, le 27 mai plus exactement, à Nîmes, j’aurais le plaisir de faire une session autour de l’agilité lors du premier Sudweb, 2011 donc. Il reste 24H chrono pour acheter des places !

Je tiens d’abord à saluer l’effort réalisé par ce groupe d’aventuriers : déclencher ce type d’évènement, avec ce standing (salle, vidéo, traiteur, orateurs étrangers), dans notre région… Bravo, hats off !

Pour ma part je dois représenter le quota gardois. eh eh.

J’ai été initié il y a peu de temps par Pierre au Marshmallow Challenge. Ce challenge très ludique permet de mettre en évidence l’intérêt du travail par itération (et optimisation), l’intérêt des équipes hétérogènes et complémentaires. Je vous recommande de vous plonger dans la documentation et d’essayer au moins une fois, c’est simple et rapide. Joué plus 70 000 fois, le plus grand rassemblement a réuni 800 personnes, ce n’est pas initialement un atelier agile et pourtant il rempli fort bien ce rôle. Le défi est -à partir de 20 spaghetti, d'1 mètre de scotch, d'1 mètre de corde et d’un marshmallow-de monter la tour la plus haute, le marshmallow devant figurer (intègre) à son sommet. Pour cela 18 minutes.

Hello, après avoir rapidement jetez un oeil du côté de la loi de Parkinson, voyons aujourd’hui la notion de dette technique. Pour l’historique de cette notion assez simple mais ô combien efficace : wikipedia.

Grosso modo l’idée est que, à chaque fois que vous réalisez “à la vite” du développement (généralement parce que quelqu’un exige une date de livraison trop difficile à tenir et donc que la qualité disparaît, ou parce que vos pratiques de développement ne sont pas assez pointues -TDD, Unit Test, Pair programming, refactoring, etc-.) ce même code vous demandera de payer des intérêts à terme. A chaque fois que vous reviendrez sur ce code, une somme de travail supplémentaire due à sa mauvais qualité sera -en plus-nécessaire.

La loi de Parkinson…  ou les gaz parfaits… veut que “le travail s’étale de façon à occuper le temps disponible pour son achèvement”. Qui dans un projet classique n’a pas vécu cette expérience étrange ? Donnez 3 jours à un “réalisateur”, il consomme les 3 jours pour réaliser ses tâches, donnez lui 10 jours, c’est 10 jours qu’il utilisera… Oui on évite cela avec Scrum au passage ou plus globalement avec l’agile, mais fallait-il le préciser ?  Je vous laisse déguster l’explication éminement efficace de Uderzo & Goscinny dans Astérix en Corse.