Le 9 octobre, j’étais à Agile Tour Rennes où j’ai eu l’occasion de présenter "Le Manifeste Agile e(s)t l’opium du peuple" avec Aurélien Morvant (@AurelienMorvant). Un bon moment et j’en profite pour remercier encore l’audience pour l’accueil qu’elle nous a fait. Pour ceux qui seraient intéressés, les slides de la conférence sont sur slideshare: http://fr.slideshare.net/XebiaFrance/le-manifeste-agile-est-lopium-du-peuple-40063827 et pour un éclairage complémentaire vous avez toujours l’article que j’avais écrit il y a quelques mois ici: http://blog.xebia.fr/2014/03/28/le-manifeste-agile-est-lopium-du-peuple/
Bien sûr, je n’y suis pas allé que pour cela. Comme toujours c’est l’occasion d’assister à des présentations, prendre de nouvelles sources d’inspiration et c’est un vrai plaisir. Comme le partage ne devrait pas s’arrêter à ces moments là, j’en profite donc pour vous livrer mon retour sur les quelques conférences ou ateliers auxquels j’ai pu assister !
20 fois sur le métier…
Christophe Thibaut – @ToF_
La keynote d’ouverture de l’Agile Tour Rennes était donnée par Christophe Thibaut sur des thématiques chères au mouvement du Software Craftsmanship. Les concepts présentés étaient familiers à tous ceux qui ont un peu étudié (et pratiqué !) XP. Pair programming, revues de code, tests unitaires, beaucoup d’éléments qu’il faut apprendre au travail et mettre en oeuvre sous peine de voir la non-qualité s’accumuler rapidement. Détail amusant, alors que Christophe parle de la valeur du test, son Evernote plante et fait quitter le mode présentation ! Belle illustration, et preuve s’il en est de l’importance du test. On aurait voulu le faire exprès, on n’aurait pas fait mieux !
Non content de nous faire partager les bonnes pratiques d’ingénierie, Christophe les illustre aussi de son expérience, en explique les raisons (et les conséquences de l’absence de leur mise en oeuvre). Il insistera surtout sur la nécessité de prendre le temps d’apprendre, de refaire, de partager, même si cela peut sembler contre-productif dans des entreprises qui recherchent l’industrialisation. Certes, quelqu’un qui baigne dans l’agilité tous les jours n’en ressortira peut-être pas avec beaucoup de nouvelles idées. Pourtant je pense qu’il s’agissait d’une très bonne keynote d’ouverture. Elle permettait d’ouvrir la journée en rendant des concepts importants accessibles à tous. La découverte de l’agilité se fait souvent à travers des frameworks (comme Scrum), et oublie parfois les bonnes pratiques logicielles. C’est important de ne pas oublier que sans elles nous n’obtiendrions pas grand chose.
Invitez-vous au mariage du (21ème) siècle
Laurent Sarrazin – @bangalaurent
En début d’après-midi, Laurent Sarrazin nous a fait le plaisir d’animer la Keynote. Laurent nous a livré une vision de l’agilité, que j’ai beaucoup appréciée car elle repose sur des valeurs que je partage.
J’ai particulièrement aimé les références à la complexité et notamment le Darkness Principle, que je ne connaissais pas. Réaliser que face à la complexité le tout ne peut plus résider dans un seul cerveau, c’est un bel argument en faveur de l’auto-organisation ! Laurent nous a présenté l’agilité comme un moyen libérateur qui permet aux individus d’agir. Son histoire sur le sous-marin du commandant Marquet et à travers celle-ci sur les risques d’un management dirigiste en était une belle illustration (cf. le livre "Turn the ship around ! A true story of building leaders by breaking the rules").
Après nous avoir montré la nécessité d’évoluer et de rendre du pouvoir aux équipes, Laurent nous a aussi exposé comment le faire dans une véritable démarche de coaching (apprendre à pécher et ne pas donner un poisson… sauf quand c’est réellement nécessaire pour progresser. Une démarche qui cherche à donner du sens. La référence à Simon Sinek et son "Start with why" (http://www.ted.com/talks/simon_sinek_how_great_leaders_inspire_action) est d’ailleurs encore une idée à laquelle j’adhère sans réserve.
Laurent n’a pas hésité non plus à nous partager sa démarche de transformation Agile. Comment passer d’un état stable à un autre, comment embarquer les gens à l’aide d’innovations games, safaris, foires agiles, katas… Comme il le dit "on pirate une maternelle pour bosser !" Bravo aussi pour l’utilisation du perfection game au sein de réponses à appels d’offres. Impliquer le client pour lui faire exprimer ce qu’il apprécie de notre proposition et ce qui lui manque pour un 10/10, c’est brillant !
Laurent a l’art de se nourrir dans un pool de connaissances très hétéroclites et hétérogènes, et il faut s’accrocher pour le suivre. Je dois dire que Romain Couturier qui assurait le scribing de la keynote de Laurent a eu fort à faire ! Pour que ce soit parfait, il aurait peut-être fallu un peu plus de clarté dans les slides. Sans doute fallait-il aussi faire des choix dans les thématiques abordées, ce qui aurait permis un débit du discours plus posé. Je n’aurais pas été contre avoir un peu plus de temps pour assimiler une idée avant de me retrouver propulsé vers une nouvelle !
Toutefois, au vu des applaudissements de la salle à la fin, on peut dire que le pari était réussi. Il faudra y revenir pour tout ce qui nous a échappé la première fois !
Atelier DEVOPS Mindstorms
Aurélien Morvant – @AurelienMorvant
Nicolas Ledez – @nledez
Sylvain – Revereault – @srevereault
L’atelier DEVOPS Mindstorms fût l’occasion de jouer avec des Lego dans une approche plus technique que celles vécues habituellement. Une expérience intéressante car elle permet de mener une idée à exécution avec l’ensemble de ces composantes : expression du besoin, modélisation du besoin, réalisation à travers un matériel fonctionnel.
Les équipes étaient réparties en deux groupes : l’un en charge de la réalisation d’un robot (à l’aide d’un manuel de construction Lego), l’autre en charge de l’écriture du logiciel de programmation du robot (à l’aide d’un système visuel de programmation par assemblage de briques fonctionnelles unitaires).
Evidemment l’atelier permet de bien voir des difficultés classiques que l’on rencontre sur les projets :
- Imperfection de l’expression du besoin
- Mauvaises traduction du besoin en logiciel (DEV)
- Déficiences techniques de la réalisation au regard du besoin (OPS)
Plus particulièrement l’accent était mis sur les deux dernières problématiques et la mauvaise adéquation du DEV avec les OPS.
Les robots devaient passer à travers un labyrinthe simplifié. A la fin de la première itération, certains robots ne bougeaient pas du tout quand d’autres avançaient en arrière…
Les problématiques étaient exacerbées par la division entre DEV et OPS. Division d’autant plus forte que les deux équipes ne pouvaient pas échanger ou tester le design et le logiciel du robot avant sa "pleine" réalisation. Si ces barrières au bon fonctionnement d’une équipe ne se limitent pas au cas des DEV et des OPS, l’exercice est suffisamment technique et complet pour susciter l’intérêt vers une approche qui permette le déploiement continu. Tous les DEV auraient aimé pouvoir tester au fur et à mesure et les OPS auraient certainement pu simplifier leur design s’ils avaient pu échanger avec les DEV. In fine nous aurions tous pu répondre plus rapidement et plus efficacement au besoin en travaillant ensemble.
Au delà de cette session, je pense qu’il aurait été intéressant de laisser plus libre cours aux OPS dans la création de leur robot (à l’aide d’un cahier des charges et non d’un manuel Lego qui guide assez efficacement la réalisation). Nous aurions ainsi pu montrer des différences de design sur la même expression de besoin. En introduisant un aspect compétitif entre les équipes dans le jeu, la pression supplémentaire aurait encore pu susciter de situations amusantes (et riches d’enseignements).
Par ailleurs le labyrinthe était relativement connu dès le départ ce qui suscitait des stratégies en réponse directe à sa structure. Une expression de besoin plus floue, voire un labyrinthe changé en cours de route auraient là aussi pu créer des prises de conscience positives. En travaillant différemment avec deux équipes, l’une à qui l’on fait expérimenter une approche bullet-proof et l’autre une approche YAGNI (http://fr.wikipedia.org/wiki/YAGNI) et KISS (http://fr.wikipedia.org/wiki/Principe_KISS) on aurait aussi sans doute pu montrer l’intérêt de ne pas sur-spécifier pour répondre plus rapidement au besoin (et mieux jauger ce qui est réellement utile ou non).
Cela dit, dans le cadre relativement court de l’atelier, il était difficilement envisageable de mettre en place ces éléments. L’expérience a été une réussite pour beaucoup et j’ai pu entendre certains dire : c’est dommage que les Mindstorms soient si chers…
Jeu : le Village Gaulois
Sacha Lopez – @Sacha2point0
David Lemesle – @dlemesle
Oui encore un jeu avec des Lego, que voulez-vous je suis partial avec ces petites briques et je suis toujours intéressé par de nouvelles approches. C’est encore, à mon sens, un des moyens les plus efficaces que l’on ait trouvé pour susciter la créativité en entreprise, jouer le rôle d’ice-breaker et expérimenter rapidement diverses situations que l’on rencontre au sein des projets.
Cet atelier était là-aussi assez intéressant et nous amenait à réfléchir sur les enjeux du travail en équipes, de l’expression de besoin et de la collaboration. Les régles étaient relativement simples et laissaient une large place à l’improvisation (où à l’auto-organisation).
Nous étions 3 équipes en charge de la réalisation de constructions Lego dont le design était transmis par 3 architectes (un par équipe). Quand les architectes voyaient le design, ils ne pouvaient pas en voir la réalisation (et vice-versa). Les architectes disposaient de plusieurs design à transmettre aux équipes exclusivement par oral. Chaque design avait une valeur différente (connue à l’avance par l’architecte) et à la fin du jeu les points remportés par une équipe étaient comptabilisés.
Au delà de cet aspect communication (et de nos mémoires mises à rude épreuve), le jeu était aussi intéressant par les dynamiques inter-équipes. En effet chaque équipe disposait d’un lot de pièces de couleurs différentes et évidemment certains designs demandaient des pièces dont ne disposait pas notre équipe. Il fallait alors aller voir les autres équipes pour négocier l’échange de pièces.
Notre groupe a su adopter une approche relativement collaborative sur cet enjeu mais apparemment dans certains groupes c’est la guerre !
Bien entendu pour rajouter au piquant les instructions des architectes ont évolué en cours de jeu, mais alors que nous pensions avoir bien maitrisé le sujet nous sommes passés à côté d’un élément de coopération inter-équipes important. En effet les structures qui rapportaient le plus de points, rapidement mises de côté par les architectes car trop compliquées à décrire, n’étaient en fait que l’assemblage des structures basiques de chaque équipe !
Et oui, sous pression du temps, avec un enjeu de compétition affiché et des animateurs qui nous laissent volontairement dans le flou, on a les bons ingrédients pour bien apprendre !
Contractualisation Agile, replacer la valeur au centre du contrat
Eléonore Varet
Sébastien Delayre @sebdlbc
C’est pour moi, le rendez-vous raté de cet Agile Tour Rennes. Le sujet était intéressant et c’est vrai que nous avons régulièrement des questions sur la contractualisation de projets Agiles. Plusieurs aspects expliquent ma déception sur ce sujet.
Nous nous sommes tout d’abord un peu perdus dans des explications sur ce qu’est l’agilité. Cela manquait de clarté mais surtout n’était peut-être pas entièrement pertinent dans le contexte d’une discussion autour d’un contrat Agile. On peut en effet supposer que l’audience qui se pose la question de la contractualisation de l’Agilité (au point d’en voir les enjeux et de vouloir en savoir plus) a déjà une bonne connaissance des bases. Cette première partie a eu un impact certain sur la conférence et à mi-chemin, nous nous demandions encore ce qui pouvait nous être proposé pour aider à mieux contractualiser les projets Agiles. Malheureusement cela a aussi eu pour effet de compliquer la tenue du timing et nous avons largement débordé du cadre imparti, sans grand sentiment de révélation.
Sur le contenu, il s’agissait essentiellement de proposer un mode de contractualisation qui s’appuie sur la valeur acquise.
J’ai trouvé cela dangereux. La valeur acquise est en effet une logique de pilotage financier du projet. Pour plus de détails, le plus simple est encore de se référer à wikipédia qui explique assez bien le concept : http://fr.wikipedia.org/wiki/Gestion_de_la_valeur_acquise
Par ailleurs, la présentation proposait aussi d’assigner une valeur financière au Story Point qui permette de définir une base de rémunération indépendante du contenu. Si l’idée de récompenser le travail à sa valeur est séduisante, c’est oublier deux choses :
- Indexer un élément de récompense sur des Story Points c’est prendre le risque d’une inflation des estimations (qui donne l’illusion d’une augmentation de la productivité)
- Un Story Point représente la difficulté relative d’une User Story, pas sa valeur business. Il peut y avoir conflit entre les deux parties, l’une cherchant à délivrer ce qui représente le plus de difficulté, l’autre ayant intérêt à obtenir ce qui a le plus de valeur utilisateur.
Bref, si j’ai aimé voir un tel sujet proposé en conférence, je reste encore sur ma faim. Pour autant, je suis curieux d’une nouvelle version de la présentation sur ce sujet, pour une question qui reste encore souvent trop compliquée.
Pour conclure, on peut dire que l’Agile Tour Rennes 2014 était un bon cru. Pour la troisième année consécutive, il a d’ailleurs fait carton plein et les organisateurs se demandent déjà comment ils pourraient accueillir plus de monde l’an prochain. L’organisation justement était extrêmement investie. Pour avoir vu une partie des coulisses, je peux vous dire qu’ils se sont démenés jusqu’au dernier moment pour nous offrir une belle expérience. Mention spéciale aux goodies orateurs, les Lego Serious Play. Quand on est fan comme moi, c’est une superbe idée. Bonne idée aussi les sous-rires, cette monnaie sous forme de smileys que nous pouvions nous échanger à chaque fois que nous passions un bon moment. A l’arrivée, le tableau de feedback était d’un joli vert et c’était mérité !
On reviendra !
