L’escouade agile d’Eleven Labs s’est déplacée le 2 décembre jusqu’à Porte de Charenton pour assister aux différents talks et workshops de l’Agile Tour 2019.
Vous retrouverez donc ci-dessous les différentes chroniques de l’équipe, composées d’une présentation et d’un avis personnel sur les ateliers qui nous ont le plus marqués au cours de la journée !
Guillaume Maron, Co-founder et CTO de chez Dashlane a ouvert la journée avec ce premier talk sur l’investissement technique dans l’agilité et les différentes organisations adoptées par leurs équipes en interne au fur et à mesure du temps et des effectifs.
La société voit le jour en 2009, et c’est en 2014 que les équipes adoptent l’agilité “by the book”. En 2016 sont mis en place des OKR afin de se fixer des objectifs business d’entreprise.
En 2017, les “Feature teams” voient le jour. Mais très vite, les objectifs étant trop flous et éloignés des équipes de développement vis-à-vis de leur vision produit, en 2018 l’organisation passe en “Mission teams”. Ce qui permet à chacun de se projeter plus facilement.
Enfin, en 2019, en complément de ces “Mission teams” est ajoutée une organisation en “Dual Track”, suite au constat de la dette technique qui ne fait qu’augmenter. Il n’est donc plus question de passer 2 jours par-ci par-là pour se pencher sur la question, mais clairement de dédier une “Platform team” de 25% des effectifs dev à cette dette technique. Une rotation a été instaurée pour que ces effectifs changent régulièrement et une “Technical Roadmap” sur 3 mois leur permet de ne pas tomber dans les travers des tâches qui ne finissent jamais.
Globalement, l’objectif donné n’est pas de la faire baisser, ni de l’augmenter, mais de la rendre “neutre”.
Mais pour que tout cela puisse fonctionner il faut avant tout que l’entreprise, dans sa manière de fonctionner et de penser, s’agilise à tous les niveaux :
L'avis de Maeva : Sujet très intéressant que ceui de la dette technique, bien souvent mis à la trappe par les directions métiers ou les CTO non avertis. Et qui fait pâtir aussi bien le produit que les équipes quand on la laisse faire sa vie. Bien plus compliquée à mettre en place dans des petites équipes, et probablement imparfaite, la dynamique adoptée pour trouver une organisation pouvant répondre le mieux possible à la dette technique - fléau commun à tout produit logiciel - a le mérite de se pencher sur la question.
On connait plutôt bien la Customer Journey Map qui consiste à cartographier l’ensemble des actions et interactions qu’un client va avoir avec une entreprise durant le processus d’achat d’un produit ou d’un service. Mais la Value Stream Map, on est moins familiers et ça nous intéresse !
Guillaume Morin - CEO de Monsieur Guiz - et son associé nous ont présenté ce concept issu du Lean Management, au travers d’un cas concret : un de leur client dans l’hôtellerie a souhaité retirer les comptoirs dans son hôtel pour créer un accueil plus chaleureux.
Le constat après un POC : allongement du temps d’attente, double saisie sur l’application mobile mise à disposition du réceptionniste, difficulté à gérer des demandes particulières pour le réceptionniste… Un accueil pas beaucoup plus chaleureux, donc.
Étape 1 : Définition de la valeur client et alignement
L’équipe de Monsieur Guiz s’est attaqué aux problèmex d’alignement des objectifs en allant interroger les Product Owners et les différentes parties prenantes avec des questions simples :
Un objectif clair est ressorti : Faciliter la vie du réceptionniste et réduire le temps d’attente du client
Étape 2 : Définir une boussole chiffrée
Par exemple, le temps de récupération des clefs par le client
Étape 3 : Créer la value Stream Map Produit
Ils ont réuni les différentes parties prenantes pour les faire travailler de concert sur leur Value Stream Map. La VSM est une technique de design et d’analyse du flow d’informations et des différents process qui permettent de délivrer un produit au client.
Ils ont donc fait mapper aux équipes (à l’aide de post-its) toutes les étapes nécessaires pour arriver à la création d’un produit ou la livraison d’une feature. Concrètement : qui passe la balle à qui ?
L’objectif : commencer à faire échanger les parties prenantes, cartographier toutes les étapes pour produire une feature/un produit, faire connaître les processus par tous, identifier les étapes qui ralentissent le process et faire s’aligner les équipes pour réussir !
Étape 4 - Les tops problèmes à régler et les tâches associées
Ils ont procédé de la même manière pour cartographier les problèmes identifiés tout au long du parcours client et les tâches associées qui apportent le maximum de valeur au client. Ils ont ensuite redispatché les problèmes et tâches aux différentes étapes identifiées dans la Value Stream map.
Le résultat : une Value Stream Map Produit et Value Stream Map Client alignées !
L'avis de Marion : Une méthode très intéressante quand un besoin de rapprocher le développement des objectifs business se fait sentir. Il semble en effet permettre d’aligner toutes les parties prenantes vers un objectif commun et être un bon point de départ pour faire ouvrir les yeux sur la nécessité de revoir les process et l’implication des différentes parties prenantes aux différentes étapes de développement d’un produit qui a de la valeur pour le client !
Sweta Mistry (Agile coach CSM, CSP et CSPO), venue tout droit de New York pour nous former, nous a embarqués dans une session ultra interactive avec pour but d’étoffer notre boîte à outils Scrum.
On a commencé en pratique avec des techniques pour engager l’audience :
Bien échauffés, on enchaîne sur les Liberating Structures. Des micro-structures qui permettent de faciliter les meetings et les conversations. Il en existe 33 qui sont détaillées dans l’ouvrage que Sweta nous recommande : The Surprising Power of Liberating Structures: Simple Rules to Unleash A Culture of Innovation d’Henri Lipmanowicz.
On découvre notamment l’”Impromptu Networking”, qui nous permet de créer des liens avec les participants du meetup, et les règles qui s’appliquent à toutes les liberating structures, à savoir :
Sweta nous conseille d’approfondir sans plus attendre les Liberating Structures et le concept de Training from the back of the room de Sharon Bowman's qui consiste en tant que formateur ou animateur à donner les instructions pertinentes aux participants puis à se mettre en retrait pour les laisser apprendre en faisant.
On continue à remplir notre boîte à outils avec les 6 TRUMPS :
On parlera enfin d’intelligence émotionnelle qu’Howard Gardner décrit ainsi “Your EQ is the level of your ability to understand other people, what motivates them and how to work cooperatively with them” et contrairement au quotient intellectuel, eh bien l’intelligence émotionnelle ça se travaille nous dit Sweta ! On apprend donc qu’on pourra améliorer notre Self-awareness, notre Self-regulation, notre Motivation, notre empathie et nos Social skills.
L'avis de Marion On repart en effet avec beaucoup de pratiques très concrètes dans notre petit baluchon, que l’on aura pu tester en live ! Pas sûr qu’on puisse toutes les mettre en pratique dans nos rétros, démos etc... mais ca nous donne beaucoup d’idées pour engager, faire participer, mieux communiquer, mieux réagir... On est resté un peu sur notre faim car on aurait aimé en savoir plus sur le mind maps, le story mapping, l’impact mapping… Et finalement, ce n’est pas qu’un Toolkit de Scrum Master mais des pratiques qui peuvent aider tous ceux qui animent des événements, des meetups ou une équipe !
La journée a commencé par une première présentation de Philippe Pushmann de la société Avanade, un conférencier habitué de l'Agile Tour puisque j'avais déjà eu l'occasion de l'écouter en 2017.
Pour cette session 2019, le sujet était : les liberating structures.
Afin d'animer de manière innovante et stimulante vos réunions, vos process, les liberating structures vous permettent d'optimiser la communication avec vos équipes.
En effet, par l'intermédiaire de petits exercices, vous allez permettre à vos collègues de se sentir investis et, par voie de conséquence, d'améliorer l'efficacité collective.
Théoriquement, le Scrum, c'est génial. On est, pour la plupart, d'accord. Dans la pratique aussi, vous me direz, mais très souvent nous pouvons nous retrouver dans une certaine routine face aux différents meetings qui rend les participants moins alertes et, de fait, moins efficaces.
Afin de casser cette routine, il ne faut pas hésiter à agrémenter vos réunions de ces liberating structures.
Je vais vous vous parler de celle qui m'a paru la plus simple et applicable, selon moi.
Il s'agit du Triz, que l'on pourrait, par exemple, mettre en place lors d'une rétrospesctive de sprint.
Demandez à vos interlocuteurs ce qui pourrait engendrer le pire résultat vis-à-vis de vos objectifs.
Dans un deuxième temps, faites les réfléchir sur les choses que vous faites actuellement qui pourraient engendrer certains résultats décrits dans la première étape.
Et, enfin, dernière étape, déterminez des actions qui vous permettraient de stopper ces effets néfastes.
Il y a en tout 35 petits ateliers très intéressants que je ne vais pas détailler parce que le but n'est pas de refaire toute la présentation mais vous pouvez les retrouver facilement sur le site liberatingstructures.fr.
L’avis de Renaud : J'ai vraiment beaucoup aimé cette présentation. Dans mon quotidien de Product owner, je me suis souvent demandé comment sortir de cette routine qui s'était installée et dont je voyais l'impact sur l'efficacité déclinante de nos échanges. J'ai enfin trouvé des réponses à ce problème et je vais m'empresser d'expérimenter tout ça !
Jean Sébastien Sladecek, Directeur Services-Conseils chez CGI est venu à l’Agile Tour nous parler d’une manière plus réaliste et surtout plus humaine d’évaluer les performances d’une équipe produit.
Dans les organisations d’aujourd’hui, on pense performance avant de penser humain - un facteur bien en amont de la livraison.
Pourquoi de ce fait ne pas être à l’écoute du réel besoin des équipes pour améliorer la performance ? Et surtout, pourquoi ne pas penser les KPIs (acronyme pour Key Performance Indicators) au service de l’équipe et non pas au service du manager ?
La première chose importante est de vous poser cette question avant de mettre en place ce type de métriques : que voulez-vous réellement savoir à travers les KPIs ?
Est-ce que vous faites est pertinent ? est-ce quec’est collaboratif ? Fluide ? À quel moment êtes-vous complètement bloqué ?
Car avant de penser performance, livraison dans les temps, et payer le moins cher possible, il est important de partir d’un constat simple mais vrai : est-ce que chaque membre de l’équipe doit avoir la même performance ?
Dans une équipe de football, par exemple, est-ce qu’on pourrait attendre que tous les joueurs d’une équipe soient évalués selon leur même performance ?
La réponse est non, évidemment. Pour certains ce seront les buts, pour d’autres les passes décisives, ou encore la défense de son propre but. Mais avant même tout cela, il ne faut pas oublier la collaboration entre chaque joueur, la discipline liée au sport en lui-même, et la compréhension et maîtrise des règles qui a permis à chacun d’être dans l’équipe.
Qu’est-ce que la performance, donc ? Notre intervenant nous l’a traduite de la manière suivante : la performance est une situation optimale afin que les individus qui composent l’équipe puissent s’exprimer à 100% de leur capacité (sénior, comme junior).
Et cette performance est affectée par plusieurs facteurs communs à toutes les équipes, comme par exemple : la maturité de l’équipe, le niveau d’expérience propre des joueurs, la situation mentale personnelle à l'instant T, le désir de dépassement de chacun, l’engagement de l’équipe dans le projet.
Quel comportement attendre de l’équipe qui pourrait donc faire l’objet de nos désormais KBIs (acronyme pour Key Business Indicators) : la motivation, l’engagement, la responsabilité, la confiance entre eux et dans l’équipe, l’amélioration continue, le partage de connaissance, l’écoute et l’empathie, le nombre de rires, etc..
Pour en savoir plus sur le sujet, une vidéo résume très bien l’ensemble : “Performance VS Trust”.
*L'avis de Maeva : Le sujet n’est pas nouveau dans l’agilité : se tromper pour s’améliorer, éviter de passer plus de temps à estimer qu’à réaliser ou encore faire comprendre à son client / sa direction qu’il ne sert à rien de courir après les points d’effort. Cela reste cependant très intéressant de pouvoir mettre des indicateurs de performance plus réalistes, plus humains et non plus liés juste à de la production. Et surtout, de pouvoir engager d’une manière plus saine l’équipe dans la volonté d’atteindre des objectifs sans risquer de les démotiver avec des demandes parfois lunaires. *
Younes Jaaidi est venu nous présenter les avantages de l’Extreme Programming, dont les principes ont été re-façonnés par Kent Beck. Technique qu’il a lui-même mise en place dans sa société Marmicode.fr.
Il a en effet rapidement fait face au constat que ses développeurs (lui y compris) codaient chacun dans leur coin sur leur propre branche, et perdaient du temps à faire des reviews de code entre eux beaucoup trop longues. Et au moment de merger une semaine de travail, se retrouvaient avec bien trop de conflits à gérer.
Ils se sont donc lancés dans l’Extreme Programming : tout le monde sur la même branche et parfois même sur le développement des mêmes features. La volonté étant de favoriser le pair programming, le pair testing & le collective ownership. En soit, l’implication et l’appartenance commune de tous les développeurs dans le même code.
Mais comment réussir à travailler avec une seule branche commune ?
En faisant de l’intégration continue, nous a-t-il répondu, qui permet notamment de :
Résoudre le problème de symétrie du code
Eviter le Git Spaghetti
Mettre en place un collective ownership plus important
Réduire le work in progress d’une feature (car tout le monde est dessus en même temps)
Ce qui pour autant ne permet tout de même pas d’éviter tous les conflits, notamment en faisant des push sur la même branche et en écrasant le travail de l’autre !
Younes Jaaidi nous a donc présenté le shared programming à travers le principe du Limbo : quel est le plus petit commit qu'il soit possible de faire, au même titre que, jusqu’où est-il possible de se baisser au Limbo ?
Dans sa vision du développement, un commit ne doit pas être une feature, mais doit contribuer à une feature. Et l’avantage de ce système est d’embarquer les développeurs dans une communication constante entre eux tout au long de la journée, permettant d’éviter autant les doublons que parfois les erreurs.
En poussant encore plus loin, ils se sont d’ailleurs essayés au “Timeboxed TDD”. Chaque commit est timeboxé, et si pour le développer cela vous prend plus de 30 mins : c’est que c’était probablement une mauvaise idée. HOP, c’est revert.
L'avis de Maeva : Technique un peu drastique qui doit peut-être bien fonctionner dans des petites équipes de développeurs qui se connaissent déjà. Mais je vois d’ores et déjà plusieurs barrières. La première est l’effort constant et au quotidien de communication imposé entre individus. Nous sommes tous humain, il arrivera donc forcément un moment où ce ne sera pas le bon jour et où potentiellement la productivité chutera. Je pense également que cela implique parfois de passer plus de temps à échanger machinalement et moins de temps à produire réellement, pPour plus d’efficience par la suite, peut-être, et c’est intéressant dans le cas d’un produit qui se cherche. Mais probablement beaucoup moins dans des équipes où la direction du produit est déjà bien travaillée en amont.
Nicolas Delahaye, coach professionnel, nous fait débuter notre voyage agile au travers d’une session de talk et d’échanges centrée sur nos mécanismes de perception et comment ils peuvent influencer notre état d’esprit agile.
Il démarre son propos sur l’Allégorie de la caverne de Platon, vous savez cette “demeure” souterraine où des hommes sont enchaînés ! Allez, on revient un peu sur le concept : “ces hommes n'ont jamais vu directement la source de la lumière du jour. Des choses et d'eux-mêmes, ils ne connaissent que les ombres projetées sur les murs de leur caverne.”
Imaginez maintenant que l'un d'entre eux soit libéré de ses chaînes et accompagné de force vers la sortie, il sera d'abord cruellement ébloui et souffrira de tous les changements. S'il persiste, il s'accoutumera et pourra voir “le monde supérieur”, ce que Platon désigne comme “les merveilles du monde intelligible”. S’il retourne dans la caverne, on peut imaginer que les autres hommes seront incapables de comprendre ce qui lui est arrivé et refuseront de le croire : “Ne le tueront-ils pas ?”.
Un petit retour en cours de philo pour nous rappeler que notre cerveau est un modeleur de la réalité, que nous avons tous une perception différente du monde et que “la carte n’est pas le territoire”. C'est un des présupposés de la PNL (on parle bien ici de Programmation neuro-linguistique), c'est aussi une phrase empruntée à Alfred Korzybski.
Oui mais comment tout ceci s’applique-t-il à l’état d’esprit Agile ?
Pour faire le lien, Nicolas Delahaye nous présente le Fixed Mindset et le Growth Mindset de Carol S. Dweck. Une personne ayant un Fixed Mindset aura tendance à éviter les challenges, à abandonner plus rapidement face aux obstacles, à considérer les efforts comme vains, à ignorer les critiques, à se sentir menacée par le succès des autres etc... Une personne ayant un Growth Mindset est plus dans une configuration apprenante qui lui apportera résilience, capacité d’adaptation, volonté d’embrasser les challenges et d’apprendre de ses erreurs...
Dans un contexte Scrum, un Fixed Mindset pourra avoir des biais qui inciteront par exemple à vouloir planifier un backlog sur 10 sprints, à faire un refinement qui serve uniquement au Product Owner pour insister sur un chiffrage, à supprimer les rétros considérées comme “inutiles”, à pointer du doigt les erreurs, ou à considérer que les erreurs viennent de l’extérieur (d’autres parties prenantes) etc…
Vous l’aurez compris, l’Aile a donc besoin de talents avec un Growth Mindset pour lui permettre de faire face au Monde empirique et complexe dans lequel Scrum a été créé !
L'avis de Marion : Une prise de hauteur intéressante sur l’état d’esprit appliqué à l’agile qui nous amène à questionner notre interprétation et la manière dont nous sommes amenés à résoudre nos problématiques. S’il semble évident que des Scrum Masters, Product Managers ou Product Owners doivent acquérir le Growth Mindset, comment procéder ? Pour aller plus loin que la théorie, quelques pistes : -Developing a Growth Mindset with Carol Dweck -25 Simple Ways To Develop A Growth Mindset
La Communication Non Violente (CNV) : voilà un concept qui valait bien un atelier lors de cet Agile Tour 2019 animé de mains de maître par Laetitia Thernier et Geoffrey Groff.
L'exercice se déroule en six phases, pourquoi six ? Vous allez très vite le savoir.
Première étape : en binôme, commencer par faire connaissance avec votre partenaire du jour. C'est toujours utile de savoir à qui l'on s'adresse ! Deuxième étape : partons sur une situation qui nous crée de l'inconfort. Troisième étape : la phase d'observation. À tour de rôle, on expose notre situation pendant que notre binôme prend note de ce qui se révèle être des faits, des sentiments et des jugements. Quatrième étape : les sentiments. Quels sont ceux ressentis lors de cette situation ? Cinquième étape : quel est mon besoin non satisfait ? Sixième étape : quelle demande aimeriez-vous faire afin de régler ce problème ?
Réfléchissez à comment réagir face à un refus de l'interlocuteur, pensez à remercier, et voilà ! Maintenant, vous savez comment aborder une situation compliquée ! Un problème inconfortable au travail, une situation conflictuelle personnelle...
L'avis de Renaud : Cette méthode s'applique à tous les contextes. Selon nos conférenciers et moi-même au sortir de cet atelier, nous avons à faire à un vrai art de vivre !
C’est sur ces ateliers qui nous ont le plus marqués que se terminent nos chroniques de l’Agile Tour 2019 ! Un sentiment partagé d’un événement moins orienté Product Ownership que l’année précédente, mais de plus en plus Agile à tous les niveaux - et particulièrement vers le Scrum Mastering. Ce qui n’en fait pas moins un événement intéressant, et qui peut-être intéressera au fil du temps des profils plus techniques sur l’agilité !
Auteur(s)
Vous souhaitez en savoir plus sur le sujet ?
Organisons un échange !
Notre équipe d'experts répond à toutes vos questions.
Nous contacterDécouvrez nos autres contenus dans le même thème
Aujourd’hui on parle de product management pour qualifier tout et n’importe quoi, ce qui entraîne la mise en place d’organisations produits sur des bases bancales. Quelles sont les principales erreurs commises ? Comment les éviter ? La liste n’est pas exhaustive mais vous permettra assurément de mieux appréhender votre méthodologie produit.
Cet article présente mes méthodes préférées pour bien appréhender un nouvel environnement de travail, incluant des outils pratiques comme le rapport d'étonnement, le Value Stream Mapping, le mandat de mission, la matrice des attendus et les Moving Motivators, afin de faciliter l'intégration, améliorer les processus et renforcer la collaboration au sein de l'équipe
Trois astronautes reviennent sur la Flowcon, la conférence sur le développement de logiciel en flux, qui a eu lieu les 6 et 7 Mars 2024