Agile France est le seul événement Agile en journée organisé en ce premier semestre 2016. L’année dernière était pléthorique avec en plus le Scrum day et le Kanban day. Mais cette année ces événements n’ont pas été reconduits. Un vrai trou d’air s’est créé et Agile France a rapidement été un événement complet, limité à 250 personnes.

Une des présentations que j’ai proposé a été retenue lors de la première sélection. J’en parle là. Mais le reste du temps, j’ai été spectateur comme les autres et j’ai assisté aux conférences qui ont été proposées. Cet article est un compte-rendu de mes deux jours de spectateur actif.

9h40 Scaling Agile – Le Release Planning Day en pratique chez Meetic

Par Alban Dalle (coach Agile chez Octo) et Nicolas Malmanovitz (responsable de la transformation Agile de Meetic)

La journée commence bien. Alban et Nicolas nous font un retour d’expérience de leur mise en place de l’agilité à l’échelle chez Meetic. J’en avais déjà entendu parler avant cette journée. J’étais impatient d’avoir la bande son. Je l’ai eue et je n’ai pas été déçu. Beau boulot !

En gros, ils se sont inspirés du framework Safe, dont je suis certifié, pour organiser un Release Planning Day chaque trimestre. Cette journée, qui a eu, au départ, du mal à trouver ses adeptes, est maintenant bien rôdée. La cinquième édition vient d’avoir lieu avec plus de 100 personnes pour une entreprise qui compte 350 employés. L’effet inverse se produit maintenant. Ceux qui n’en font pas partie veulent en être. C’est l’endroit où il faut être.

Toutefois, cette simplicité d’apparence est en réalité d’une complexité titanesque. Une telle journée doit être préparée, notamment pour identifier les projets prioritaires. En amont, un backlog de projets est ouvert à tous. Son nom : Company Kanban. Tout le monde peut y proposer un projet à condition qu’il en soit porteur tout au long de sa vie. Si le porteur de projet ne le vend pas bien, celui-ci est purement et simplement abandonné. A partir de ce Kanban, un Top 50 est réalisé. Seuls les projets qui font partie de ce Top 50 sont des candidats potentiels à cette journée de planification.

Ce Release Planning Day a drainé le changement de la culture de l’entreprise. Cette journée démontre la qualité de la collaboration au sein de l’entreprise. Cette collaboration est devenue la norme au détriment d’Excel, de Jira et du mail. Maintenant qu’il y a plus de 100 personnes, il est plus facile de convertir les autres en douceur. Mais au départ, ce n’était pas la même histoire. La résistance au changement était forte, comme dans toute entreprise qui démarre sa transformation. La stratégie qui a été mise en place a été de faire travailler ensemble les PMO qui sont le mieux placé pour avoir une vision globale et un coach Agile. Il a été préféré d’utiliser des réunions existantes en modifiant légèrement leur objet plutôt que d’en créer de toutes nouvelles. Le temps a ensuite fait son travail.

En aparté, Nicolas m’a confié que bien que cela fonctionne bien et qu’ils ont suffisamment d’expérience avec 5 Releases, il n’y a rien de gagné. Au-delà de 100 personnes, une telle journée devient difficile à organiser. Il reste deux tiers de l’effectif à intégrer à ce rituel. Plutôt compliqué !

Un bien beau retour d’expérience et de beaux challenges à venir. Agile France commence bien pour moi.

11h Les sessions de 2 heures

Mais cet excellent démarrage va très vite être contrasté par ce créneau de sessions de deux heures. D’autant plus qu’il commence mal. J’avais en effet choisir de suivre Eric Sieber qui proposait « Libérez vos talents ! ». Mais voilà que son Mac en a décidé autrement et refuse de démarrer. Eric n’avait pas de backup de ses supports, donc impossible d’utiliser un autre ordinateur et il ne semblait pas être disposé à se lancer à l’improviste. Après lui avoir proposé d’animer un ice breaker improvisé pour qu’il puisse se ressaisir, proposition qu’il a refusée, j’ai quitté la salle pour essayer une autre session. Il devait être 11h20-11h25.

Mais s’incruster à des ateliers qui étaient déjà commencés depuis presque 30 minutes, c’est vraiment compliqué. Je me suis dit, pourquoi ne pas « redécouvrir le manifeste Agile avec des Legos », une session proposée par Romain Couturier. Celle-ci affichait complet. J’ai fait une visite rapide des autres sessions, mais voyant tout le monde à l’oeuvre, je me sentais largué. Je me suis rabattu sur « La foire aux micro-services », animé par Yannick François et Emmanuel Gaillot. Mais je n’étais visiblement pas la bonne cible, cette session était bien trop Geek pour moi. Il fallait coder en groupe et en Java.

A court d’idées, je suis revenu voir Eric et ses déboires. Il a finalement commencé sa session sans support. Mais l’énergie n’était plus là. Dommage. Pour la petite histoire, j’ai reparlé à Eric dans l’après-midi et son Mac avait finalement démarré.

Je n’ai donc rien retenu de ces deux heures.

11h Agilifier le haut de la pyramide

Par Luc Taesch

Je n’ai pas participé à cette session et pour cause. J’avais assisté au Dry Run quelques jours plus tôt. Le groupe avait identifié quelques faiblesses qui ont très probablement été corrigées. Deux de mes collègues coachs ont participé à cette session et sont ressortis enthousiastes.

Dans cette session, Luc essaye de démontrer qu’il est impossible d’Agilifier une entreprise avec la manière d’opérer actuelle qui commence généralement par un simple coaching d’équipe qu’on essaye ensuite d’élargir à un périmètre plus large. Pour étayer cette démonstration, il compare la pyramide hiérarchique et la pyramide de Dills et met en évidence qu’à chaque niveau de hiérarchie est associé un domaine de responsabilités distinct mis en avant par la pyramide de Dills. Quand un coach Agile essaye d’élargir son coaching, il va forcément adresser tous les niveaux de la pyramide et se retrouver confronté à des résistances à chaque niveau dans un contexte de lutte de pouvoirs et de protection de son territoire. A cela s’ajoute un fait aggravant. L’un des niveaux de la pyramide de Dills n’est couvert par personne dans la hiérarchie. Personne n’est en charge du changement de culture au sein de l’entreprise. Et pourtant, une transformation Agile, c’est avant tout un changement de culture. Comment adresser ce niveau si personne n’en est responsable dans l’entreprise ? Actionner un tel levier devient alors très compliqué.

Au-delà des problèmes que Luc met en avant, c’est surtout un ensemble de points d’attention qu’il faut surveiller quand un coach est en charge d’une transformation. Et s’il n’y fait pas attention, il risque d’être viré de sa prestation. Une solution de facilité quand un coach pointe du doigt de vrais difficultés. Les coachs ne sont que des intervenants extérieurs. Ils peuvent servir plus facilement de fusible. Cela règle tous les problèmes au même titre qu’il est préférable de jeter à la poubelle un thermomètre lorsqu’il indique 39° après avoir pris la mesure de son enfant plutôt que de se poser la question de l’origine de cette hausse.

14h30 Le forum ouvert

Après un bon déjeuner, il est temps d’oublier cette mauvaise séance de fin de matinée et de démarrer un forum ouvert. L’animateur l’introduit avec une phrase qui fait mouche : « Vous êtes responsable de votre non action ». En d’autres termes, si je trouve ce forum ouvert mauvais, c’est de ma faute. Je décide donc de m’impliquer, à la fois en proposant une session et en allant contribuer à d’autres.

Le programme est très vaste et chargé. Impossible encore une fois d’assister à tous les sujets qui m’intéressent. Il va falloir sélectionner. Même si certaines sessions ont été retirées après le démarrage, il y avait largement de quoi échanger.

Voici un petit plaisir que je me suis offert. L’un des participants était démotivé au début de ce forum ouvert. Je lui ai redonné de l’énergie en le questionnant sur un sujet qu’il serait susceptible de proposer et de conclure avec lui : « Pourquoi ne le proposes-tu pas ? ». Il n’osait pas parce qu’il le trouvait complexe. Et alors ? C’est un bon candidat pour un forum ouvert ! Quelques minutes plus tard, il s’est jeté à l’eau et l’a proposé. Le résultat a été au-delà de ses espérances et il m’a remercié de l’avoir incité à le faire. Des petits plaisirs qu’on aurait tort de se refuser ! Merci pour le retour.

Voici le programme :

Mon sujet : Synchronisez tout ! Les clés pour devenir une entreprise Agile ?

Commençons par le sujet que j’ai proposé. Bien qu’il n’y ait pas eu beaucoup de participants, le constat est convergent. Tous les frameworks autour de l’Agile consistent principalement à organiser des réunions de synchronisation. En fonction de la réunion, l’ampleur de la synchronisation varie, du daily meeting qui est quotidien au Program Increment meeting qui est trimestriel, mais l’objet reste le même : synchroniser ses activités pour plus de performance globale.  Au final, ces synchronisations facilitent le changement de culture dans l’entreprise.

Voilà les feuilles que nous avons remplies durant cette session :

Les autres forums ouverts

Au-delà de la session que j’ai animé, je suis allé parler « Feuilles de temps« . Bien qu’il y ait un point commun dans toutes les entreprises, à savoir que ça emmerde tout le monde de les remplir, les raisons et les enjeux sont bien différents d’une entreprise à l’autre. Ma proposition de simplification n’a pas forcément remporté tous les suffrages. Mon idée était de dire qu’un membre d’équipe fait partie à 100% d’une équipe et qu’il impute donc à 100% son activité dans cette équipe, ce qui facilite grandement la saisie même s’il ne faut pas oublier de soustraire toutes les activités qu’il fait hors de l’équipe (congés, participation à un autre projet, formation, etc.). Ensuite, au sein de cette équipe, plusieurs stories sont réalisées à chaque sprint, chacune avec des points de complexité. Il est facile de tracer la provenance de ces demandes. Ainsi, si les demandeurs sont multiples, il est plus facile de répartir le temps passé dans l’équipe durant un sprint au prorata temporis des points de complexité de chaque story plutôt que de comptabiliser le temps réellement passé sur chacune d’entre elles.

Ensuite, j’ai essayé de répondre à la question « Comment faire disparaître mon coach Agile vite et bien ?« . Question qu’il est à priori facile de répondre puisque la finalité de coach Agile, c’est de partir dès que possible. Encore fallait-il définir ce que veut dire « vite » et « bien ». Nous avons mis en avant que pour que le terme « bien » soit validé, il fallait que l’équipe ait acquis une autonomie suffisante pour fonctionner indifféremment avec ou sans le coach. Rien ne devrait changer suite à son départ ! Quant au vite, plusieurs réponses ont été apportées entre trois et six mois, l’une d’entre elle était même supérieure à l’année. La bonne réponse est donc : « Ça dépend ! ». Autre sujet que l’on a abordé pour valider le terme « bien », c’était de savoir si le coach avait des critères personnels de notation, comme par exemple la présence d’une pratique ou d’une manière de faire dans l’équipe. Là encore, beaucoup de réponses variées.

J’aurais bien parlé de « Valeur métier », un autre de mes chevaux de bataille, mais on ne peut être partout. Tant pis.

La fresque de la première journée

La première journée se termine et il est temps d’aller voir Jean-Pierre Bonnafous qui, depuis le matin, récupère les feedbacks de chaque participant pour les mettre en image dans une gigantesque fresque que voici :

Seconde journée

La seconde journée n’a pas de forum ouvert. Elle a donc naturellement plus de sessions et donc plus de sujets affichés à traiter. C’est aussi la journée où je présente ma session. C’est parti !

9h30 Comment j’ai recruté mon pair ?

Par Houssam Fakih (référent Java Arolla) et Jonathan Salmona (référent .Net Arolla)

Pourquoi ai-je choisi cette session alors que ce n’est pas mon cœur de métier ? Je me suis dit qu’il serait intéressant de regarder de l’autre côté du miroir les problèmes de recrutement vus par les recruteurs. En écoutant le discours, je ne peux m’empêcher de penser à la blague de commit strip : « On va s’arrêter là« . C’est justement ce que Houssam et Jonathan ont eu envie d’éviter. Leur problème ? Recruter la mauvaise personne et passer à côté d’une perle. Dans une entreprise qui recrute de manière importante, les personnes qui mènent les entretiens sont plusieurs. Chacun évalue à sa manière et peut passer à coté de quelque chose. Le besoin de normaliser les recrutements devient une nécessité comme cela se passe avec les corrections des copies du bac qu’on ajuste après coup en commission de normalisation. Pour y arriver, il faut des critères, notamment un qui est important : tester le candidat. C’est ainsi que le recrutement se transforme rapidement en une séance de pair programming, ce qui peut être déroutant pour le candidat et lui faire perdre tous ses moyens. Il faut donc le rassurer et le mettre en confiance. Cette technique, associée à plusieurs autres, permettent de mettre les candidats à pied d’égalité quelque soit le recruteur qui se trouve en face. Et cela porte ses fruits. La quasi totalité des recrutements effectués ont été des bons choix. Pour terminer, un dernier conseil : s’il y a le moindre doute sur le candidat, il ne faut pas le prendre !

10h30 Pour en finir avec le marathon du planning de sprint

Par Xavier Galleri.

Un peu d’air frais avec Xavier qui veut remettre en cause l’une des pratiques phares de Scrum : le planning de sprint. Une session de 25 minutes, plaisante et qui se résume facilement. Les chiffrages et les discussions à ne pas en finir pour savoir si tout sera fini à la fin du sprint peuvent parfois être contre productifs. Plutôt que se battre sur ces sujets, autant démarrer les développements immédiatement et voir où cela nous mène. Le planning de sprint se transforme donc en une présélection des histoires les plus prioritaires. L’équipe les réalise dans l’ordre en respectant une limite de travail en cours afin d’être contraint de finir une histoire avant de pouvoir en démarrer une autre. Faire un flux quoi ! Au final, ce que propose Xavier, c’est faire ce que Kanban propose.

Mon avis : il a tout à fait raison, mais attention, le Kanban pratiqué dans un tel contexte ne peut fonctionner qu’avec des équipes matures qui doivent au préalable être passés par la case Scrum pour bien intégrer les notions d’engagement, de prêt et de terminé.

11h30 Le contrat Agile ce n’est pas si simple que ça

Par Franck Beulé.

Je ne pouvais naturellement pas participer à une autre session de ce créneau puisque j’étais animateur de celle-ci. Bien entendu, je dirais que la présentation était très bien, mais je ne suis pas objectif ;-). 25 personnes étaient présentes dont quelques unes avec des problématiques très concrètes pour lesquelles elles cherchaient des réponses. Plutôt que de rentrer dans une description détaillée de cette session, je vous propose d’aller directement lire l’article qui lui est consacrée. Vous y découvrirez les supports, la vidéo enregistrée en séance et un retour d’un participant qui m’a beaucoup fait plaisir.

14h Les sessions de 2 heures

Petit appréhension vu ce qui s’est passé la veille et… rebelote. Décidément, le format 2 heures n’est vraiment pas adapté. Entre la session dans la plus grande salle qui s’est terminée au bout d’une heure car l’orateur avait tout dit et la session, semble t’il passionnante, qui a affiché complet alors que des wagons entiers de participants frappaient à la porte, ce format est vraiment à revoir pour l’année prochaine !

Je n’allais pas visiter la session de Legos proposée par Nathaniel Richand et Yannick Ameur car je l’avais déjà faite auparavant. Je n’allais pas non plus creuser l’holacratie proposée par Pablo Pernot, Géraldine Legris et Dragos Deptate, non pas parce que les présentateurs ne me plaisaient pas, au contraire, ils se sont mis en quatre et se son même déguisés pour l’occasion. Je n’allais pas non plus voir Dov Tsal car j’avais assisté à sa session au Dry Run. J’avais envie d’aller voir « Improving Agile Teams, Interactions et changement » de Vincent Daviet. Mais j’ai croisé quelques dizaines de personnes déçues car sur la porte, il y avait écrit « Complet ». Vraiment quelques dizaines de personnes ! Un vrai train de déception !

Il ne me restait plus qu’à participer au Kata Elm de Laurent Bossavit. Découvrir un nouveau langage, Elm, en 2 heures, et comprendre ce qu’est un langage fonctionnel, c’était une belle occasion. Mais 30 minutes plus tard, j’ai jeté l’éponge. Je n’aime vraiment pas ce langage ! Je n’aime pas les langages qui ne te facilitent pas la vie. Et ce langage en fait partie.

J’ai fini par errer dans les couloirs en attendant la fin de ces deux heures maudites.

16h15 Le burnup incertain

Par Xavier Galleri.

C’est l’heure de la dernière session. Je suis frustré. Je n’ai pas envie de finir déçu. Xavier a bien vendu sa session lors de sa première présentation. Je préfère jouer une valeur sure et revenir le voir. Une fois encore, il est dans son mode : ce n’est pas la peine de se prendre la tête pour avoir des chiffres, il faut laisser le temps au temps pour qu’ils émergent tout seuls. Une première estimation de ton backlog ressort un résultat entre 370 et 550 points ? C’est suffisant, même si c’est presque du simple au double. Tu penses avoir une vélocité entre 60 et 90 points ? Très bien ! Ton projet terminera donc au mieux en 4 sprints et au pire en 9 sprints, là encore une estimation qui va du simple au double. Maintenant, travaillons et les chiffres s’affineront tout seuls. Le résultat final est entre les deux.

Le discours de Xavier est très déroutant car il relativise complètement un sujet qui est pourtant au cœur de la majorité des querelles. Pas sûr qu’il passe auprès de tout le monde, moi le premier. Pour autant, c’est un discours à ne pas mettre de côté car il recentre vers l’essentiel. Et l’essentiel, c’est de livrer le bon produit au client, le plus vite possible.

Les fresques colorées des deux jours

La seconde journée se termine et Jean-Pierre Bonnafous a une nouvelle fois fait des prouesses. Voici la deuxième fresque :

Et oh surprise, la première, réalisée la veille, a gagné en couleurs :

Ce bilan graphique fait plaisir aux yeux et rappelle aussi qu’on a vu certaines sessions et qu’on en a ratées d’autres. C’est le jeu !

17h15 Clôture des deux journées

Comme chaque année, la clôture des deux journées est en mode décalé. Cette fois-ci, il nous a été demandé d’écrire sur le dos vierge de nos badges nos souffrances pour mettre en oeuvre dans notre contexte ce qu’on a appris pendant ces deux journées. Puis, nous nous sommes mis en file indienne et avons incanté les esprits afin que ces souffrances disparaissent. En vidéo, cela donne ça :

 Mes regrets

Le principe de ces journées intense, c’est d’avoir plusieurs sessions en même temps. L’intérêt, c’est que statistiquement, il y en a forcément une qui nous intéresse à chaque moment de la journée. L’inconvénient, c’est que forcément, il arrive que plusieurs sessions nous intéressent sur le même créneau ce qui nous oblige de faire des choix, subjectifs. Cela nous amène à regretter celles qu’on a ratées, sans savoir si elles étaient bien ou pas.

Voici donc ma liste des regrets :

• Dashing deux en un, pour un dashboard étincelant ! par Nathaniel Richand. La découverte d’un nouvel outil qui pourrait être bien, c’est forcément intéressant.
• Réaliser une bonne recette au concombre par Shoun Ichida. Je promeus l’outil Cucumber dans mes coachings, l’un des projets que je coach l’a même adopté, et pourtant je n’ai jamais assisté à une présentation générale de l’outil.
• Utilisateur, fais moi mal : la dictature du test par Emilie-Anne Guerch et Nicolas Moreau. L’Agile nous dit d’impliquer les utilisateurs le plus en amont possible du processus. Plus facile à dire qu’à faire.
• A la (re)découverte du Manifeste Agile par Romain Couturier. Forcément, voir un nouvel atelier qui utilise des Legos, ça m’intéresse. Et s’il existait un jeu efficace pour découvrir le manifeste Agile avec des Legos ?
• DDD : et si on reprenait l’histoire par le bon bout ? Tout simplement par Thomas Pierrain et Jérémie Grodziski. Difficile de savoir si cette présentation avait un vrai plus. Sujet marronnier. Si c’était juste pour expliquer ce qu’est le DDD, je n’ai rien raté. Si c’était pour aller au-delà, j’ai des regrets.
• Scaling Culture : Agilité à l’échelle et entreprise libérée par Nicolas Lochet. Mélanger deux sujets différents dans une même présentation, sacré challenge ! Soit on obtient une bouillie indigeste, soit on obtient des faisceaux convergents. Bien entendu, j’aurais espéré la seconde option.
• Unscaling Agile : Beyond budget & process par Samuel Retière. L’utilisation d’anti-patterns, ce n’est pas nouveau. Le résultat est casse gueule mais peut aussi être très intéressant.
• Comment obtenir des standup qui marchent par Florence Chabanois. Au même moment, il y avait une conférence similaire sur le sprint planning. Difficile de faire le choix entre le standup et le sprint planning. Les deux sont importants et sont mal vécus par certaines équipes.
• Mettez en pratique le Design sprint par Paul Depre. Le quoi ? Un truc nouveau, peut-être intéressant, mais j’étais orateur à ce moment là.
• Interviewer les experts métiers, cela s’apprend par Cyrille Martraire, intéressant, mais en même temps que ma conf.
• De l’état gazeux à l’État plateforme : l’agile est un long fleuve tranquille par Cyrille Deruel et Eric Heijligers. Il est toujours intéressant d’écouter Cyrille. Ça ne sera pas pour cette année, encore une fois pour la même raison.
• Le test n’est pas (qu’)une histoire de testeur ! par Clément Rochas. Décidément, ce créneau était bien riche.
• Le Kanban expliqué par Bison Futé par Cyrille Deruel. Petit dernier, encore un rendez-vous manqué avec Cyrille.

C’est ainsi que se termine mon compte rendu des deux jours à Agile France 2016.

Franck Beulé
Coach Agile, expert des technologies de l’Internet et en ergonomie du Web