Agile Grenoble 2024

Il y a 2 semaines, je suis allée à Agile Grenoble, la conférence à laquelle je vais tous les ans car c’est pas loin, c’est pas cher, et surtout j’y trouve de l’inspiration pour mettre en œuvre de nouvelles pratiques.

Cette année, je n’ai pu y aller que le jeudi, petite rétrospective de cette journée.

KEYNOTE – Le futur de l’IA : La machine qui aide l’homme ou l’homme qui aide la machine ? par Ari Kouts

Levée aux aurores pour être à Grenoble à 8h30 et assister à la keynote. C’est un domaine que je connais assez peu, et sur lequel j’étais curieuse d’en savoir plus. Intéressant de découvrir quelques IA en lien avec nos métiers, en particulier deux IA qui sont capables de générer du code. L’une des 2 le faisait à partir d’une maquette annotée (Make Real, repo github ici), et l’autre à partir d’un prompt (Chatdev). Les démos étaient très simplistes, et ne m’ont pas convaincue que ces outils pouvaient remplacer un travail de prototypage sur Figma par exemple, mais à voir, à tester. Côté code lui même, je me demande si la qualité est au rendez-vous.

Ce qui m’a marqué le plus, et c’est très auto-centré je vous préviens, c’est que l’IA qui générait du code à partir d’un prompt à généré plusieurs agents pour simuler une équipe de dev. Il y avait un CEO, un CTO, un PO et un dev si ma mémoire est bonne, peut-être un QA, j’ai un doute. Ce qui est certain c’est qu’il n’y avait ni UX, ni UI, et guess what, le résultat était moche et inutilisable. C’était un jeu de Tétris, et celui-ci démarrait directement dès qu’on lançait le programme (pas le temps de se préparer), avec des pièces qui tombaient tellement vite qu’il était impossible de les “ranger”, pas de bouton pour redémarrer, et pas de possibilité de modifier la vitesse. Bref, un NVP : un Non Valuable Product (je viens de l’inventer, mais le concept a peut-être déjà été théorisé ^^).

Qu’est ce qu’on peut en conclure ?

• Que l’UX est indispensable, bien sûr, ahah.
• Qu’avec une IA qui génère un soft en 11 minutes, on peut se permettre de construire une première version sans UX, et d’itérer après avoir testé le résultat ?
• Que le monde de l’agilité n’inclut toujours pas l’UX comme un rôle nécessaire à avoir dans une équipe de développement ? À voir, c’est un peu le sentiment que j’ai eu, mais la journée ne faisait que commencer !

Découper ses user stories, par Gladys Niarfeix

J’estime que je découpe plutôt bien les user stories, mais de manière assez “intuitive” en essayant de faire des US réalisables en moins d’un sprint et qui apportent de la valeur aux utilisateurices. J’étais curieuse d’en savoir plus, et cette conf m’a permis de découvrir des modèles théoriques dont j’avais seulement entendu les noms jusque -là :

• le modèle des 3C qui décrit l’aspect social des US : une US doit tenir sur une Carte (un post-it), elle doit découler de Conversations (au sein de l’équipe, avec des utilisateurices, avec les stakeholders) et elle est la Confirmation physique d’une demande / d’un objectif à atteindre.
• le modèle INVEST : les US doivent être Indépendantes les unes des autres, Négociables et négociées entre les parties prenantes, Valuable (elles doivent apporter de la valeur intrinsèquement), Estimables par les devs, Small de manière à être développées intégralement dans un sprint et suffisamment claires pour être Testable.

La conférencière a également reposé les bases de l’expression d’une User Story : En tant que [rôle] je veux [besoin] afin de [objectif], en insistant sur le fait que c’est le besoin et pas la solution qui doit apparaitre afin de ne pas se priver de la créativité de l’équipe pour trouver la meilleure solution.

Côté découpage, Gladys Niarfeix nous a présenté un jeu de cartes, le Split Poker, qui propose 12 critères pour découper des US. Je ne vais pas vous le détailler ici, autant consulter directement l’article de Neosoft qui a créé le jeu ici. Je trouve cette approche intéressante, mais j’y vois des limites, voire des risques, concernant certaines propositions de découpage.

Par exemple, le critère Happy/Unhappy propose de gérer dans une US le scénario où tout se passe bien, et de créer d’autres US pour gérer les cas d’erreur. C’est quelque chose que j’ai moi-même fait récemment, sur un gros projet avec beaucoup d’erreurs à prévenir, certaines ayant de fortes chances de se produire et d’autres potentiellement moins courantes (donc moins prioritaires). Le risque que je vois d’utiliser ce critère pour découper les US est d’oublier de faire le minimum vital en cas d’erreur dans la 1ère US, et de se retrouver avec des usager·es bloqués dans leur parcours utilisateur. Donc décliner la prévention des erreurs dans les US distinctes, ok, mais la gestion des erreurs lorsque celle-ci a lieu (un message clair, décrivant ce qui s’est produit et comment le corriger) doit selon moi être intégrée systématiquement dans la feature dès son développement initial.

Un autre critère qui m’a fait un peu tiquer, évidemment, est celui concernant la variation d’interface :

Parfois, on se lance corps et âme dans la réalisation d’une interface ultra design avec des UX designers débordant de créativité, sans avoir validé l’intérêt de la soi-disant killer feature avec un prototypage simple. Le risque que la fonctionnalité ne soit finalement pas retenue est réel, aussi pour démontrer au plus tôt la valeur apportée, il peut être intéressant de découper la User Story au niveau de l’interface : avant de montrer ce superbe nouveau widget de calendrier dernier cri, un simple champ texte peut suffire à démontrer la feature se cachant derrière.

Évidemment, je comprends l’idée et ce qui se cache derrière, mais :

• le besoin réel pour les utilisateurs est sensée être validé en amont, c’est tout l’objectif que de la phase d’UX Research ;
• l’expérience me fait dire que si la feature a été développée avec une UX simpliste, il sera très difficile de prioriser l’amélioration de cette UX à moins que l’usage soit vraiment ultra lourd. En gros, si c’est passable, ça restera en l’état pour très longtemps, car il y aura toujours d’autres features plus prioritaires que l’amélioration de celle-ci. Et ça peut être une stratégie acceptable, selon les circonstances, mais dans ce cas, attendez-vous à une grosse frustration des UX designer de votre équipe qui auront bossé “dans le vent” sur une expérience utilisateur vraiment agréable et fluide qui ne sera jamais développée.

Ma reco serait plutôt de privilégier les échanges entre UX et devs de manière à co-concevoir le bon compromis entre une expérience utilisateur agréable et un coût de développement acceptable.

En fin de conférence, quelques questions ont été posées, notamment autour du rôle d’UX justement. J’ai demandé comment concilier le fait de ne pas détailler la solution dans l’US, mais d’avoir un·e UX designer créant des maquettes de celle-ci. La réponse m’a surprise : selon elle l’UX propose une solution mais ce n’est pas forcément cette solution qu’il faut développer à court terme, c’est plus une source d’inspiration. Ce n’est pas comme ça que je vois le rôle de l’UX designer dans une organisation, et ça m’a fait réaliser pour la 2è fois de la journée l’écart entre ma pratique et ce qui est connu/pratiqué dans les milieux agiles.

La fresque de l’agilité, par Claude Aubry, Claude Andrieux, Jean-Pascal Boignard & Anthony Cassaigne

Sur le 3è créneau, j’ai fait le choix de participer à la fresque de l’agilité, un atelier en groupe dans l’esprit de la fresque du climat et autres fresques de ce genre.

Un groupe de 8 personnes environ, 4 animateurs, des cartes et un plateau, et des échanges autour de 4 axes liés à l’entreprise :

• l’organisation des personnes
• l’organisation du temps
• le sens du travail
• le résultat du travail

J’ai trouvé l’approche intéressante pour stimuler les échanges et cadrer un moment autour de l’amélioration continue. Comme une rétro d’entreprise, cadrée sur des axes pré-établis, pour faire une sorte d’auto-diagnostic et creuser des problèmes et des pistes d’amélioration. Plus de détails sur le site internet dédié.

Nous n’estimons plus, et tout va bien ! par Antoine Comble

Croire aux estimations est pire que croire aux licornes, car au moins les licornes sont inoffensives et amusantes. Les estimations peuvent détruire votre entreprise et elles sont sacrément ennuyeuses à créer.

Vasco Duarte

Une conférence intéressante mettant en avant des bonnes pratiques, outils et métriques à exploiter pour travailler sans estimation. L’idée est de s’appuyer sur les principes du No estimate en comptant les tâches plutôt que les points et en les découpant rigoureusement (mais il peut y en avoir des plus petites et des plus grosses, ce sera lissé au global), de l’empirisme (ça implique de se laisser un peu de temps en début de projet) et des mesures autour de la gestion du flux.

Les métriques à regarder sont les suivantes :

• Work in progress : le nombre d’élément en cours de travail.
• Cycle time : le nombre de jours moyen entre l’entrée et la sortie (par exemple le début du dev et la livraison en prod : l’essentiel n’est pas d’avoir la bonne définition de ce que c’est qu’un cycle mais d’en choisir une et de s’y tenir).
• A partir de ces 2 indicateurs, on peut calculer le débit : c’est le WIP divisé par le Cycle time.

Ces métriques permettent de tracer plusieurs graphs intéressants, notamment :

• le Cumulative Flow Diagram qui permet de visualiser la réalisation des tâches au fil des semaines, avec le nombre de tâches en ordonnées et le temps en abscisses, et 3 courbes cumulées pour les tâches Done, En cours et To do. Si tout va bien, le Done augmente, le Todo diminue (sauf si on rajoute sans arrêt des tâches dans le backlog bien sûr), et le WIP est assez constant (sauf si la taille de l’équipe augmente) ;
• l’Aging Work In Progress permet de mettre en évidence les tâches qui restent dans la même étape du flux de travail trop longtemps en traçant un nuage de points (un ticket = un point) avec en abscisses les étapes du flux de travail et en ordonnées le nombre de jours depuis l’arrivée du ticket dans cette étape ;
• le Cycle Time Scatter Plot permet de voir la durée médiane pour développer une tâche et l’évolution de celle-ci au cours du temps, en traçant à nouveau un nuage de points du temps de cycle de chaque tâche au cours du temps ;
• la simulation de Monte Carlo permet d’estimer une date de release à partir de ces indicateurs et d’une probabilité choisie, par ex “Les fonctionnalités x, y et z ont plus de 50% de chance d’être livrées au 1er février, et plus de 80% de chance d’être livrées au 1er mars”, ou un nombre de tickets terminés à une date choisie.

Outils :

• Wiveez
• ActinableAgile
• PaceMkr
• Formule de calcul pour la simulation de Monte Carlo

Consulter les slides ici

L’art de conclure, par Antoine Douchet

Cette conférence était celle que j’attendais le plus car la thématique rejoint celle de mon podcast sur les ingrédients d’une expérience utilisateur mémorable : exploiter la conclusion d’une expérience comme levier d’action pour favoriser un souvenir agréable de cette expérience. Après une présentation étayée du postulat de départ (la qualité de la fin d’une l’expérience est corrélée au souvenir à long terme de cette expérience), la conf présentait 3 axes d’exploitation de cette observation scientifique :

• Soigner l’off bording d’un·e collaborateurice, pour augmenter la probabilité que la personne parle en bien de son ancienne entreprise autour d’elle : dans un contexte de turn-over important c’est dommage de terminer sur un process très froid (rend-ton-badge-et-ton-PC-merci-au-revoir). Le conférencier propose 4 leviers que sont le fait de montrer de la reconnaissance en valorisant la progression de la personne, lui faire du feedback positif sur ce qu’on a apprécié et comment s’améliorer encore, passer un moment convivial (pot de départ financé par l’entreprise) et garder contact ;
• Soigner la fin de l’expérience utilisateur sur un produit ou service pour favoriser l’envie de revenir et d’en parler autour de soi, en utilisant notamment la méthode de l’experience map pour identifier les émotions générées par chaque étape et trouver des pistes pour soigner la fin de l’expérience d’utilisation. Par exemple, Ikea propose des hot dog pas cher après le moment peu fun du passage dans l’entrepôt et du paiement, malin !
• Soigner la fin des réunions pour faciliter l’assimilation, apprécier le moment et/ou reprendre de l’énergie. Voir ce document pour plus de détail sur le sujet et plein d’idées de formats de conclusion.

La conf a été filmée, je ne peux que recommander son visionnage complet pour aller plus loin (en ligne sur youtube d’ici quelques semaines je pense), c’était drôle, sourcé, plein d’exemples parlant, tout ce que j’aime !

Et aussi :

• Je suis juste humain, par Benjamin Cabanne : Une keynote introspective touchante sur l’agilité, l’envie de bien faire, parfaitement, tout en restant juste humain
• Au-delà des heures : La semaine de 4 jours comme levier d’égalité, par Albane Veyron : une ode à la semaine de 4 jours que je ne peux que partager
• Des retrouvailles avec d’anciens clients, c’est toujours un plaisir de se revoir !
• des nouveaux contacts, notamment via l’écriture de cet article en échangeant avec certains conférenciers.
• Un bon déjeuner végé en compagnie de mes collègues de choc Anaïs et Romain.
• Quelques sketchnotes : ça faisait très longtemps que je n’avais pas fait cet exercice, j’ai eu un peu de mal à gérer l’espace…
• L’émergence de l’idée d’organiser un forum ouvert avec le CARA dans mon entreprise : hâte de mettre ça en place !
• Merci à toute la team d’Agile Grenoble pour cette belle journée !