La conférence Agile France 2013 est la huitième édition organisée par Agile France. Pendant deux jours, des conférences, retours d’expériences, live coding, ateliers et jeux agiles se sont enchainés simultanément dans six salles. Cet événement a eu lieu les 23 et 24 mai 2013. Le principe et l’organisation sont similaires au Scrum day qui a eu lieu un mois plus tôt mais qui était concentré sur une seule journée. Vous pouvez lire mon compte-rendu du Scrum day ou visiter le site de la conférence Agile.

Voici mon retour d’expérience sur ces deux journées où il a fallu que je choisisse certaines conférences au détriment d’autres qui avaient lieu au même moment. Quelques regrets donc, mais globalement deux journées très enrichissantes. En fin d’article, vous trouverez la liste, je l’espère exhaustive, de tous les comptes rendus et slides publiés sur la toile. Compte-rendu.

Le cadre

Cet événement était organisé à La Porte Jaune, au beau milieu du bois de Vincennes. Un lieu très bucolique au bord d’un lac au beau milieu d’une colonie d’oies, que nous aurions certainement plus apprécié si nous n’avions pas eu deux jours de pluie et de grêle. Heureusement, les conférences avaient lieu au sec ! Qui dit milieu des bois dit un réseau téléphonique cellulaire et 3G qui ne fonctionnait quasiment pas. Et, du fait que c’était excentré, un accès difficile par les transports en commun. C’est peut-être l’une des raisons qui a fait que la conférence n’affichait pas complet.

Le fil rouge

Peut-être est-ce dû au choix des conférences ou était-ce une vraie tendance, mais beaucoup de conférenciers ont abordé le sujet du coaching des managers. Organiser des équipes en Agile est semble-t-il quelque chose de maitrisé. L’étape suivante est de faire accepter ces modes de travail aux managers. Il y a dans ce domaine encore beaucoup de marge de progression. La recette proposée pour résoudre ce problème est toujours la même : extraire les managers de leur tour d’ivoire et les emmener sur le terrain pendant quelques heures, une à deux fois par mois. Il n’y a qu’en s’impliquant sur le terrain qu’on peut identifier les vrais problèmes des équipes et donc proposer des plans d’action adaptés. Être déconnecté de l’opérationnel est le vilain péché des managers, surtout en France où il y a une forte culture de la hiérarchie.

Et maintenant, les conférences…

From Value to Values – Why Management has to change and how IT is inspiring the solution

Jeudi 9h. Après que les organisateurs nous ont accueillis par une petite présentation d’une dizaine de minutes, la première conférence de la journée est présentée par Peter Stevens. Pas de concurrence pour lui, il n’y avait pas d’autres conférences au même moment. Il est le seul à avoir eu cette chance. Dommage pour les non-anglophones, car cette première présentation était tout en anglais.

Cette première conférence a abordé la thématique du management et mis en évidence à quel point le management d’hier, très hiérarchique, ne peut plus fonctionner aujourd’hui, et comment les méthodes agiles permettent un management plus souple et plus adapté. L’orateur a insisté sur le réseau Stoos dans lequel il est impliqué et qui a pour but de faciliter ce nouveau management.

Comment diffuser massivement une approche Kanban

Jeudi 9h30. Samuel Retiere prend le relai et présente une organisation Kanban qui s’est étendue à plus d’une centaine de personnes. Selon lui, Kanban est plus adapté que Scrum à partir du moment où le nombre de personnes impliquées devient important. Lorsqu’on est confronté à un groupe aussi important, tout le monde n’intervient pas lors du daily meeting. Seuls ceux qui ont des tâches qui bougent prennent la parole. La durée du daily meeting est toujours limitée à quinze minutes.

Le Respect en Action

Jeudi 10h. Un grand coup de cœur pour cette présentation de Cyrille Deruel et Jonathan Scher sur la thématique du respect. C’est l’un des deux grands thèmes mis en avant par le Lean, mais en pratique, cet aspect est très rarement développé. Et pourtant, le respect est essentiel, car c’est en respectant ses collaborateurs que l’on peut tirer le meilleur d’eux.

Afin d’illustrer ses propos, la présentation commence par une scène jouée de daily meeting, suivie d’une démo animée par un chef de projet tyran, le genre de personne avec qui l’on n’a pas envie de travailler. Pendant cinq minutes, il pourrit l’ambiance et surtout son équipe. Tout le monde est démotivé. Plus personne ne veut faire d’effort. C’est la genèse de l’échec. Une caricature certes, mais criante de vérité. Tout le monde a été confronté à au moins l’une des situations présentées.

Le reste de la présentation consistait à reprendre point à point les manques de respect successifs qui ont été mis en avant et montrer à quel point cela peut démotiver les équipes. Et, bien entendu, d’expliquer comment appliquer ce respect qui rendra ses équipes performantes.

Voici quelques exemples de manque de respect flagrants :

• Nommer publiquement une personne pour dire qu’elle n’a pas bien fait son travail,
• Estimer que son équipe n’est pas capable d’animer une réunion ou une démo,
• Faire l’amalgame des problèmes de deux collaborateurs et proposer aux deux une solution unique et non adaptée,
• Maquiller les indicateurs pour faire plaisir au client,
• Se désolidariser de son équipe,
• Donner toujours au même collaborateur les tâches ingrates jusqu’à ce qu’il s’en plaigne.

En sortant de cette présentation, la seule question que l’on se pose est : pourquoi cette thématique n’est-elle pas plus largement développée ? J’ai échangé sur ce sujet avec d’autres conférenciers et j’ai bien ressenti à quel point ils ne considéraient pas cette thématique comme primordiale. Et pourtant, elle l’est ! C’est la base d’une collaboration riche et efficace.

Real Options: quand et comment (ne pas) prendre des décisions

Jeudi 11h30. Pascal Van Cauwenberghe nous apporte sa bonne humeur et son humour belge en nous racontant trois contes de fées. Derrière ces contes, la mise en avant de techniques simples pour retarder au plus tard la prise de décisions. En effet, il n’est pas rare d’avoir une pression phénoménale pour prendre une décision urgente au motif qu’il y va de la vie du projet. Cette décision ayant été prise à la hâte sera remise en cause en milieu de projet entraînant une désorganisation complète de celui-ci. En réalité, en utilisant des patterns comme MVC et de nombreux autres, il est souvent possible de retarder la plupart des décisions en se concentrant en premier lieu à la réalisation des sujets obligatoires.

Pour les sujets soumis à décision, il est nécessaire d’évaluer le temps de leur réalisation en partant du principe que l’obligatoire est déjà réalisé. En soustrayant de la date de livraison souhaitée ce temps de réalisation, on obtient la date de décision au plus tard. Cette date est généralement plus tardive que la date initiale à laquelle on aurait imaginé nécessaire cette décision.

Si toutefois cette date ne convient pas, il est possible de se lancer dans le développement des deux solutions en parallèle. C’est certes plus long, mais cela permet de repousser la date de décision encore plus tard. Une fois la décision prise, une partie du travail devient certes obsolète, mais l’autre est bien avancée. En réalité, la vie des projets étant ainsi faite, la solution implémentée et devenue obsolète peut très vite redevenir d’actualité. Ainsi, il sera plus rapide d’aboutir à la solution finale, puisqu’on pourra repartir d’un travail réalisé partiellement.

Une décision urgente, si elle est prise au moment adéquat, devient tout de suite moins urgente et surtout, plus elle est prise tard, plus elle est le sera en connaissance de cause. Les équipes travaillent donc plus sereinement et limitent leur risque de devoir tout recommencer.

Agilité : do the wrong thing faster ?

Jeudi 12h30. Pour nous mettre en appétit, l’heure du déjeuner approchant à grands pas, Pierre Pezziardi constate que la plupart des projets, bien qu’ayant un but louable, sont des échecs cuisants. Même si votre projet a été livré en temps et en heure et est conforme au besoin, finalement, apporte-t-il réellement de la valeur, ou au contraire en retire-t-il ? Quelle application de risque bancaire a anticipé la crise financière ? Quel système de surveillance censé assurer le bien-être des collaborateurs aboutit au contraire à l’augmentation du taux de suicide de ces mêmes collaborateurs ? Quelle nouvelle version d’un logiciel divise la productivité par trois car la nouvelle interface, censée être plus ergonomique est au contraire un frein ?

Le projet sur lequel vous travaillez, pensez-vous qu’il va finalement apporter de la valeur ou en retirer ? Est-il réellement au service de l’utilisateur final ? Sera-t-il réellement utilisé et apprécié ? Beaucoup de questions qui permettent de prendre un peu de recul sur ce que l’on fait et se poser les bonnes questions. Juste avant l’heure du déjeuner…

Jeudi 14h30. Heure de la sieste oblige, je suis incapable de me souvenir de la conférence à laquelle j’ai assisté. Pour vous dire à quel point elle m’a marqué. J’en suis désolé, car il y avait pourtant plusieurs sessions qui m’intéressaient à cette heure.

Coacher des managers

Jeudi 16h. Antoine Contal est un coach au look improbable : costume cravate style premier de la classe. On comprend mieux son look quand on découvre le métier qu’il fait : il coache les managers, ceux qui sont haut placés dans la hiérarchie et qui sont bien souvent déconnectés de la réalité. Alors forcément, il a le look correspondant. CQFD.

Antoine nous a fait un retour d’expérience sur quatorze managers qu’il a coaché, certaines fois brillamment, d’autres fois avec des résultats moins probants. Mais c’est de ses échecs que l’on apprend le plus… De profils différents, leurs approches ont été très différentes, les résultats aussi. Son rôle était de les intégrer dans un processus pour que l’entreprise dans son ensemble soit agile. Et pour y arriver, la meilleure des solutions, c’est le rapprochement des managers et de leurs équipes. Pour ce faire, il organise régulièrement des sessions d’une demi-journée avec le manager qui l’accompagne. La première heure, il le prépare à la rencontre d’une équipe sur le terrain. Puis, pendant deux heures, il l’accompagne sur le terrain, à la rencontre de ces équipes. Mais plus qu’une simple visite de courtoisie, c’est plutôt une visite de terrain, pour voir ce qu’il s’y passe vraiment et découvrir les problèmes que rencontre l’équipe. Pendant cette période d’immersion, Antoine reste silencieux. Tout au plus se permet-il une unique intervention pour essayer de pointer du doigt un point particulier. Cette période d’immersion terminée, une réunion de débriefing à deux a lieu. C’est là qu’Antoine fait ressortir tous les points qu’il a observés, certains que son manager a vu, d’autres pas. Grâce à cet enrichissement, le manager sait plus facilement où il doit agir et ce qu’il doit faire.

3 semaines pour une Product Map

Jeudi 17h. Cette première journée se termine par une présentation de Bertrand Dour, coach agile mais surtout un collègue d’une précédente mission. Bertrand aime la musique et depuis le Scrum day, il essaie de faire revivre le groupe Pink Floyd. Notre mission : produire leur nouvel album. Petit problème : l’album précédent ne s’est pas bien vendu. À l’aide d’outils et de jeux agiles, speed boat, buy a feature puis product map, nous allons définir les priorités qui vont régir la production de ce nouvel album. Et l’enchainement de ces jeux est implacable : cela fonctionne !

Bertrand a essayé en entreprise cette technique. Un grand nombre d’intervenants, de nombreux métiers et parties prenantes, des objectifs et priorités divergents… il n’y avait guère d’issue pour définir une roadmap de projet cohérente. Plutôt que d’étaler des centaines d’interviews sur plusieurs mois pour tenter d’extraire une tendance, il a mis en place des ateliers d’une demi-journée, deux fois par semaine pendant trois semaines. Au bout de ces trois semaines, la roadmap était établie. Les priorités étaient établies. Et surtout, il y avait consensus !

C’est sur cette touche de bonne humeur que nous pouvons attaquer l’apéritif et clore cette première journée.

Communautés de pratique en pratique

Vendredi 9h30. Quoi ? Encore lui ? J’avais déjà participé à une présentation de Cyrille Deruel la veille. Comme quoi, nos centres d’intérêts convergent. J’ai en effet déjà travaillé dans le domaine des communautés de pratiques, et j’étais curieux d’avoir un retour d’expérience sur une mise en pratique différente de la mienne.

Une communauté de pratique, c’est un groupement d’au minimum trois personnes qui se réunit régulièrement pour aborder une thématique particulière afin de s’améliorer dans ce domaine par échange de retours d’expérience. On peut par exemple monter des communautés de pratiques de développeurs sur un langage particulier, une communauté de testeurs ou d’agilistes.

Pour que cela fonctionne, il suffit d’un noyau d’au minimum trois personnes pour l’animer et des réunions régulières, de préférence physiques, d’une durée d’une heure. Le mieux est de réserver un créneau, même heure, même salle, toutes les deux semaines. La communauté gère un backlog de sujets à traiter qui sont priorisés. Une fois le sujet le plus important choisi, le collaborateur désigné prépare une présentation de trente minutes sur le sujet en question qu’il présentera lors de la prochaine session. S’ensuivra un échange sur ce qui a été dit lors de la présentation pendant l’autre demi-heure. En fin de session, le sujet pour la prochaine réunion est choisi. La session se clôture par la rédaction d’un compte rendu dans un Wiki afin de capitaliser sur les sujets et surtout ne plus avoir à revenir dessus.

Ce mode de fonctionnement est optimal avec des communautés de dix à quinze personnes. Si la communauté devient trop importante, la partie d’échange libre doit être cadrée pour éviter la cohue. Pour maximiser la qualité des échanges, la réunion doit avoir lieu physiquement. Dans le cas où les intervenants sont disséminés sur plusieurs sites, c’est beaucoup plus dur à mettre en place. Mais si sur chaque site il y a une communauté suffisante, rien n’empêche d’organiser des communautés indépendantes sur chaque site et de mettre en place ce qui est nécessaire pour que les autres sites bénéficient des conclusions des échanges.

Encore plus d’agilité avec le lean : trois pratiques pour commencer

Vendredi 10h. Regis Medina nous plonge dans les arcanes du Lean et nous le présente sous un angle si simple à comprendre que cela paraît naturel : définition d’un premier lot indispensable, rythme de production, respect de la qualité, amélioration continue… toutes les recettes de base pour aboutir au succès. En fait, Lean, c’est simple, mais sa simplicité fait toute la différence !

Storytelling Battle – pour enclencher le changement, créer son histoire

Vendredi 11h30. Je ne pouvais pas manquer la présentation d’Oana Juncu, accompagnée de Pablo Pernot, dans un exercice qui paraît simple mais qui en fait ne l’est pas. Partant du principe que si l’on n’est pas capable d’expliquer un problème à un enfant, c’est qu’on ne l’a pas compris soi-même et que 70 % de ce que nous apprenons vient des histoires qu’on nous raconte, pourquoi ne pas traiter ses problèmes en racontant des histoires simples à comprendre ?

En partant d’un sujet bateau, en l’occurrence pour notre équipe l’explication des rôles dans Scrum, comment exposer simplement ce sujet, ses tenants et ses aboutissants ? L’exercice paraît simple mais nous étions en équipe et en temps limité. En plus de créer une histoire qui tient la route, nous devons établir un consensus d’équipe. Ce n’est pas une mince affaire. Nous sommes partis sur une métaphore que tout le monde ne comprenait pas. Pris par le temps, nous n’avons pas pu revenir en arrière. Nous avons donc raconté notre histoire en utilisant cette métaphore. Ce qui en est ressorti, c’est que personne ne savait où l’on voulait en venir.

Deuxième itération, nous repartons sur de nouvelles bases. Exit la métaphore, hormis dans la phrase de conclusion pour rappeler notre première intervention. Nous nous sommes appuyés sur le concret et le factuel. Résultat de la deuxième présentation, ce que nous expliquions a été compris, mais nous n’avons pas attiré l’attention. En étant trop factuel, nous avons créé de l’ennui. Choisir le juste milieu entre l’histoire, la métaphore et le concret, c’est un métier à part entière. Mais lorsqu’on en a la maitrise, la communication de ses problématiques devient tout de suite plus facile.

Petite pause déjeuner pour reprendre des forces et attaquer la dernière demi-journée. Déjà ? Finalement, le temps passe vite…

Elastifiez votre application : du SQL au NoSQL en moins d’une heure

Vendredi 14h30. Bien que l’on sorte un peu du périmètre de l’agilité, cette présentation est mon deuxième gros coup de cœur. David Pilato et Tugdual Grall, travaillant respectivement pour Elastic search et Couchbase, vont nous montrer en une heure, code à l’appui, le passage d’une application à base de Sql en NoSql avec tous les avantages que cela comporte. Afin de gagner du temps, les différentes étapes de la migration ont déjà été implémentées et sont disponibles sur Github. La session se limite donc à l’explication du pourquoi et du comment.

La première étape consiste à passer en services REST/JSON les requêtes métier d’accès aux données puis de mettre le résultat de ces requêtes en cache avec Memcache. Migrer ces données vers Couchbase qui est une base de données NoSql orientée document et qui a la particularité de ne gérer aucune table. Pour coder la clé, il faut donc utiliser une convention d’écriture, par exemple « table:id ». La valeur correspond à un document au format Json. Un connecteur entre Couchbase et Elasticsearch est mis en place afin que chaque modification de la base Couchbase soit notifiée à Elasticsearch. Ce dernier est un index puissant qui permet de retrouver une séquence de texte à n’importe quel endroit du bloc Json, ou, si on le souhaite, ne s’intéresser qu’à un seul endroit en spécialisant la requête. Elasticsearch s’appuie sur la technologie Lucène pour fabriquer son index. Pour couronner le tout, saupoudrons nos résultats de requête avec Angular.js, un framework Javascript qui permet en deux temps trois mouvements de transformer de simples bases de données en tableau de bord évolué. Ainsi, il est possible de voir en temps réel la répartition géographique des données ou des graphes statistiques en tout genre qui se mettent à jour en temps réel au fur et à mesure que l’on continue à injecter de nouvelles données, le tout sans latence.

En somme, un ensemble d’outils puissants qui permettent de manipuler efficacement ses données avec une rapidité jamais vue dans les bases de données relationnelles.

Cette présentation était bluffante. Elle permet de s’ouvrir l’esprit vers de nouveaux horizons. La disponibilité des sources va permettre de décortiquer les choses. Petite frustration au bout de cette démonstration, elle appelle plein d’autres questions. On ne peut pas leur en vouloir, c’est un sujet si vaste et nous n’avions qu’une heure…

À ce stade, je reste donc avec mes questions mais une envie forte de creuser le sujet. Et je me dis intérieurement que les bases de données relationnelles, c’est peut-être has been. Tiens, c’était justement le but de cette présentation.

Imaginer l’entreprise agile avec le Consensus Workshop, un outil de facilitation pour les agilistes

Vendredi 16h. Un petit dernier pour la route ? Il est difficile de choisir sa dernière session, surtout après être sorti d’une session qui ouvre l’esprit. C’est la dernière, et ce serait bien de partir sur une bonne impression. Lan Levy et Damien Thouvenin (le chef de Lan) ont eu la lourde charge de tenir ce rôle.

À partir de la simple question « qu’est-ce qu’une entreprise Agile ? », essayons de répondre à la question en utilisant la méthode du consensus Workshop. Comment fonctionne ce workshop ?

Première étape, individuellement, chacun répond à la question en donnant sa liste d’arguments.

Seconde étape, les individus forment des groupes de trois personnes et s’échangent leurs arguments. Une liste limitée à sept éléments doit émerger.

Troisième étape, parmi ces sept éléments, les trois premiers de chaque équipe sont présentés à tous. Les éléments communs sont regroupés en respectant le consensus général.

Quatrième étape, les éléments non présentés jusqu’alors et qui correspondent à des idées nouvelles sont présentés à tous puis regroupés.

Cinquième étape, les groupes les plus importants sont transformés en phrases qui synthétisent les notions qui définissent le groupe. Cette étape est la plus compliqué car dans un groupe, il y a en fait plusieurs nuances qu’il est difficile de synthétiser en une seule phrase.

Au bout de cet exercice, il est possible de répondre à la question initiale par une série de phrases synthétiques qui regroupent les notions les plus importantes.

Ce workshop était intéressant car il nous a permis d’expérimenter cet outil de consensus workshop. Mais la fin était un peu laborieuse car il a été difficile de trouver un consensus sur la formulation des phrases de la cinquième étape. Et, petite déception, j’étais venu à cet atelier pour en savoir plus sur ce que serait une entreprise agile. Je n’ai pas vraiment eu la réponse à la question, l’atelier étant plus focalisé sur l’utilisation de l’outil.

C’est ainsi que c’est terminé le dernier atelier.

Bilan de la conférence Agile

Globalement, le bilan de la conférence Agile est forcément positif, car il y avait de très nombreux ateliers qui ont permis de creuser un grand nombre de sujets. Il est très intéressant de se réunir en groupe de personnes partageant les mêmes centres d’intérêts, et d’en débattre. Même défaut que le Scrum day, l’abondance des conférences fait qu’il est impossible de participer à toutes celles que l’on aimerait. Mais d’un autre côté, s’il y en avait moins, le risque de s’ennuyer serait plus grand, tous les sujets n’étant pas forcément intéressant pour soi.

Bien que très bien organisée, cette conférence a eu quelques points négatifs. Il y avait bien moins de monde qu’au Scrum day. Est-ce le prix plus élevé, la localisation excentrée, la popularité moindre de l’événement ? Je ne sais pas. Mais avec moins de monde, l’esprit festif est plus réduit. Avantage quand même : ce n’était pas la cohue pendant les sessions.

Autre point négatif lié à l’organisation : il manquait une keynote de clôture à la fin de la deuxième journée. En sortant du dernier atelier, on ne sait pas où aller. Tout le monde est dispersé. Il n’y a pas de lieu pour dire au revoir aux personnes que l’on a côtoyé pendant deux jours. Cet élément de cohésion manquait cruellement.

Troisième point, très peu de sessions étaient filmées. Il ne restera pas grand-chose pour la postérité et surtout, pas moyen de voir chez soi les sessions que l’on a ratées et que l’on aurait bien aimé voir. Certes, au Scrum day, tout n’était pas filmé non plus. Mais on avait le sentiment que beaucoup plus de sessions l’étaient.

Quatrième point, la météo était pourrie, mais l’organisation ne pouvait pas y faire grand-chose. À cause d’elle, nous n’avons pas pu profiter à sa juste valeur du cadre de verdure qui nous était proposé.

Cinquième et dernier point, promis, je m’arrête là. Je n’ai pas trouvé sur le site comment garder contact avec les participants comme cela se pratique par exemple sur le site Meetup, ni comment publier les retours d’expérience comme celui-ci pour le faire partager au plus grand nombre. Prendre contact avec les intervenants et retrouver leurs slides va être un sacré travail !

Ces quelques points négatifs sont mineurs par rapport à ce qu’on retire de ce genre d’événements, et ce qu’on en retire est très positif !

On en parle ailleurs

Je me lance dans une mission compliquée. Essayer de prendre contact avec chaque intervenant pour récupérer leurs slides et les vidéos si elles existent et vous communiquer toutes celles que j’ai réussi à réunir. Si vous en avez trouvé qui ne sont pas là, n’hésitez pas à me le remonter…

Les comptes rendus :

• Retours sur Agile France 2013, 1ère partie (en images) par Christophe Addinquy
• Retours sur Agile France 2013, 2nd partie (en images) par Christophe Addinquy
• Retours sur Agile France 2013, 3ème partie (en images) par Christophe Addinquy
• Retours sur Agile France 2013, 4ème partie (en images) par Christophe Addinquy
• Retours sur Agile France 2013, dernière partie (en images) par Christophe Addinquy
• Agile France 2013, bonus track par Christophe Addinquy
• Coacher les managers par Olivier Le Lan
• Mener le changement – Découvrez les  étapes de Kotter par Olivier Le Lan
• Travailler ? oui, avec plaisir ! par Vincent Uribe
• Code Legacy, faire évoluer ou réécrire par Vincent Uribe
• L’usage de la CNV en agilité par Vincent Uribe
• Les astuces du coaching et de la gestion du changement par Sébastien Bonvoisin
• Mon premier Agile France, par Olivier Azeau
• Agile France par Alexis Monville
• Agile France, c’était les 23 et 24 Mai par Simon Jallais
• Agile France 2013 : J’étais là ! Par Emilie Esposito
• Agile France 2013, impressions de voyage par Thierry Cros

Les slides :

• Elastify your app par David Pilato et Tugdual Grall ainsi que les sources de l’application démontrée
• From Value to Values: Why Management Has to Change par Peter Stevens
• Domain-Driven Design in legacy application par Cyrille Martraire
• Real Options – Comment et Quand (ne pas) prendre des décisions par Pascal Van Cauwenberghe
• Je vois ! – Ou comment la visualisation non conventionnelle contribue à des projets agiles par Egor Sviridenko
• Coacher des managers avec le Lean par Antoine Contal
• Mais pourquoi y m’écoute pas ? par Florence Chabanois
• Encore plus d’agilité avec le Lean par Régis Medina
• L’agilité en maintenance logicielle par Sébastien Delest
• Communautés de pratiques en pratique par Cyrille Deruel
• Ce que le sport m’a appris d’Agile par Christophe Keromen
• Ce que j’ai appris de l’agilité au théâtre par Christophe Keromen
• Agile values, French values par Peter Stevens
• Les paradoxes du leadership par Thomas Lissajoux
• Scrum Metal Jacket par Jean-Louis Rigau et Nicolas Jozviak
• Building an MVP that works for users par Ariadna Font Llitjos
• Designing an MVP that works for users par Ariadna Font Llitjos
• The hitchhicker’s guide to unit testing par Rémy-Christophe Schermesser

Divers :

• Le jeu Software ball
• Elasticsearch, le moteur de recherche élastique pour tous par David Pilato
• Couchbase Webinars et différentes présentations.

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