Ça se passait les jeudi-vendredi 22 et 23 mai toujours au chalet de la porte jaune. Cette année, la conférence suivait au moins 2 fils. L'un explicite "le fil rouge", activité de médiation graphique omniprésente et l'autre en trame, avec une résonance entre la keynote de Régis Médina sur le produit lean et les sessions qui ont suivi.

L'après-XP pour du développement produit

Avis de non-responsabilité : pratiquant l'XP depuis 7 ans, en partie avec Antoine C, et travaillant avec David B, membre de l'équipe d'organisation les propos suivants sont éventuellement subjectifs ;)

Cette keynote était une bonne introduction, une synthèse construite autour de l'expérience de Régis parti de l'extreme programming pour faire du lean. Ce ne sont plus des pratiques lean (les liens ci-dessous) qui sont expliquées mais l'utilisation de ces pratiques au service d'un nouveau modèle de gestion du système de production logicielle. Le marché a changé, l'open source, les plate-formes de téléchargement (apple store, android store...), les éditeurs, mettent en compétition énormément d'acteurs. Pour sortir du lot, il faut créer un effet "whaoo!!".

Pour cela, il revient sur la métaphore artistique : il faut un réalisateur, comme pour un film. Quelqu'un qui ait

• la vision pour positionner le challenge : trouver le segment d'utilisateur ciblé, les paramètres clés du logiciel (par ex pour google chrome, la vitesse), et les points durs à solutionner. Le gemba ou go and see, est un bon moyen d'identifier ces 3 parties du concept.
• l'encadrement pour cultiver le désaccord : le consensus rapide que promeut l'agilité est également source de re-travail (rework). Pour créer l'alignement, le set based design assure une discussion basée sur des faits. Le management visuel fournit des modèles pour animer la collaboration, propose une vision partagée du produit.
• l'exigence de dénicher les erreurs : des revues de design permettent de créer le challenge nécessaire à l'affinage de la vision. L'ouverture des vannes de retour utilisateur génère une source de résolution de problème par PDCA.

Benoît Charles-Lavauzelle qui nous expliquait ensuite "Comment impliquer vos clients dans leurs projets", était en parfaite continuité avec cette keynote. Il nous relatait sous format PDCA les problèmes, hypothèses, actions et leçons apprises au niveau de la gouvernance de leur société. Au cœur de la démarche était remis en cause le type de contrat au forfait. Mais comment faire accepter des contrats au temps passé à des clients qui choisissent (lorsqu'ils ont le choix) systématiquement le forfait ? Benoît a un déclic lorsque l'un de ses clients qui lui dit "les experts c'est vous". Ils décident alors de vendre le temps passé en invoquant :

• leur vitesse de développement. Le plus grand défenseur du cycle en V sait que la vitesse n'est pas la force de ce type de méthode.
• les dépassements déjà subis par les prospects. Ces derniers conviennent que le risque existe aussi dans ce contrat
• le risque du temps passé est partagé contrairement à l'argument des avocats du forfait : Théodo peut avoir des développeurs en inter-contrat du jour au lendemain si le contrat est dénoncé, et le client récupère le code
• leur grande expertise technique dans un marché de niche (développement web PHP-symfony)

Et ça marche!

Ils mettent en place des questionnaires de satisfaction client à chaque sprint avec un objectif de 8/10. Chaque écart est vu comme un problème qui conduit à un PDCA. Ils font participer le client au planning-poker (avec un vote). Ils envoient un mail quotidien après chaque daily, contenant le burndown et le board virtuel Trello. Ils partagent la vision avec des boards physiques dans les équipes. De cette manière ils proposent à leur client de devenir pilote de la voiture de course qu'est Théodo. Il pilote les choix fonctionnels et budgétaires.

Bien sûr, la session sur la rétrospective continue par Antoine Contal et Régis Médina enfonçait le clou. Ils évoquent les difficultés de l'amélioration continue et introduisent en précisant que la solution n'est pas dans la rétrospective mais à l'extérieur : un nouveau défi. Pour cela ils proposent de créer un environnement propice à l'apprentissage, et décider qui doit apprendre quoi pour que le format ne soit plus un soucis. Comment ?

• En définissant le challenge de façon mesurable en terme de qualité, délais et productivité. En se basant sur l'idée de prospérité mutuelle, le gemba permet d'aller voir sur le terrain le problème que cherche à résoudre le client, comment il se traduit en euros sonnants et trébuchants, en stratégie pour ses équipes. L'écoute des équipes permet de conserver les talents, et on itère sur le gemba
• en rendant ce challenge visuel : montrer à tous la déclinaison du challenge sur les murs. Les tâches quotidiennes doivent participer à l'atteinte du challenge
• en animant les exercices de kaizen (amélioration de chacun). Un problème opérationnel (ex: le temps de résolution des bugs est trop important), est décliné en plusieurs PDCA qui sont pris en charge par des développeurs. Par exemple ce temps de résolution de bug est élevé car les logs applicatives ne sont pas pertinentes. Un développeur devient alors M. Logs en prenant le sujet avec l'aide d'une ou 2 autres personnes. Il devient expert dans le domaine et peut ensuite retransmettre son expertise aux autres personnes de l'équipe.

L'intervention du Thibaud Brière le soir, sur l'intelligence collective, proposait de favoriser la diversité pour pouvoir bénéficier des écarts entre les opinions exprimées, et trouver des nouveaux chemins. Cultivons l'impertinence. La remarque d'un participant sur l'alignement des desseins me fait aussi penser à la congruence de G. Weinberg.

La keynote du vendredi était faite du même bois, Rachel Davies nous explique l'organisation de sa société qui a poussé l'extreme programming bien plus loin que ce que décrit la littérature. Et pour cause, Matt Cooke, le directeur technique est un expert XP depuis plus de 10 ans. Leur challenge c'est créer plus de valeur en rapprochant les opérationnels de l'expression du besoin, du métier, des utilisateurs. Les développeurs sont organisés en petites équipes de 3-4 personnes. Ils écrivent les stories, font du support, ils fonctionnent en flux tiré, font du set based design, chaque story a un leader. Après le déjeuner, c'est "story time" un moment pendant lequel ils explorent le besoin avec les gens du métier. Pour les "impairs" ils ont mis en place un rôle de "lone rangers", ils sont disponibles pour la corrections de défauts, ou répondre aux questions fonctionnelles.

Enfin, Bernard Notoriani nous relate avec Guillaume Nurdin leur expérience de Dojo et Mob programming. Ou comment ils ont relevé le challenge de la refonte d'une application financière avec une équipe répartie entre l'Espagne, La Belgique, l'Italie et la France contenant 4 experts fonctionnels, 5 développeurs et un coach XP.

Ils mettent d'abord en place des Dojo-Développements pour faire monter en compétence les développeurs débutants. 2 fois par semaine, 2h, avec une préparation minutieuse. Après avoir montré un geste (ex un CRUD), ils font répéter le même geste à chacun d'entre eux. Puis vient l'idée du Mobprogramming c'est un poste de développement, une équipe de 4-6 personnes avec un PO, des rotations tous les 1/4h derrière le poste et un rétroprojecteur pour que tout le monde puisse suivre. Leur implémentation est différente pour des raisons logistiques, ils essayent 1/2j par semaine ou 1j par semaine en sous équipe, sur les sujets complexes de l'application sans PO (pas facilement disponibles et éloignés).

Ils déclinent ensuite sous forme de Requirement-Mob pendant lequel ils itèrent sur les spécifications. Après avoir échoué à travailler depuis le format FitNesse, ils utilisent un template word accompagné éventuellement d'une feuille de calcul excel. Ils décrivent les scénarii (Tests d'acceptance) de l'application et incorporent les tests dans leur wiki FitNesse.

Une inconférence dans la conférence

Un grand bol d'air avec un jeudi après midi consacré à une parenthèse d'inconférence. La pluie s'est calmée, et a fait place à de belles éclaircies, permettant des sessions en plein air. Bien sûr il y avait un peu d'égo-trip dans certaines propositions. Mais nous avons pu parler de ce qui fait qu'une équipe est agile, jouer avec l'ableton push de Guillaume Saint Etienne, parler du buzz du moment le TDD (ou plutôt Requirement Driven Developpment) avec Étienne Charignon.

Dans un esprit très Agile Open (en session de la conférence) nous avons pu voir du coding live, grâce à Emmanuel Gaillot, qui nous a montré qu'on pouvait faire du TDD avec... de l'assembleur (i386 je crois). Très agréable de voir la progression méthodique et régulière qui ne laisse personne au bord du chemin sur un sujet aussi difficile qu'inhabituel.

Le format court et rapide des sessions du vendredi après-midi dans la salle plénière était également divertissant, avec notamment la belle présentation de Matti Schneider sur Petit Board Deviendra Grand, ou comment faire de l'amélioration continue par les artefacts, en faisant évoluer son management visuel pour qu'il modélise le système de production. Comme le modèle est moins complexe que le système représenté, il est plus facile de le discuter, le modifier.

Lorsque le modèle résonne avec le système, on atteint le graal : l'hyperproductivité. Rétrospectivement, sur un projet passé dans la téléphonie (dans lequel nous avions parlé de l'importance de la modélisation avec Antoine C), c'est en partie ce qui nous est arrivé. Je ne l'avais jamais vu sous cet angle.

Bref, bonne édition de la conférence, même si on sent bien une adoption de l'agilité par le "mainstream", preuve aussi de son succès, l'organisation a bien su mettre l'emphase sur ceux qui continuent d'avancer. Merci à eux de venir partager leurs trouvailles.