Retour sur l’Agi’Lille 2023
Sommaire
- Shape Up : allez à l’essentiel pour construire un produit par Julie Demanze & Perrine Maroye
- Et si on arrêtait de produire un software inutile ? Par David Laizé
- Cupcake Story par Camille Marquette & Bernard Klymowicz
- Rendez l’agilité aux Devs par Fanny Klauk
- L’art de conclure par Antoine Douchet
- En conclusion
Au moment des inscriptions à la 14ème édition de l’Agi’Lille, qui s’est déroulée les 29 et 30 juin dernier à l’université Catholique de Lille, nous n’étions pas tous égaux face à l’événement.
Alors qui sommes-nous, et quel regard portons-nous sur cette rencontre ?
- Raphaël : Product Owner depuis 2 ans chez Néosoft Lille. Pour ma première participation à l’Agi’Lille, j’étais heureux de pouvoir échanger entre pairs mais je restais dubitatif sur la possibilité de mettre en place ces nouvelles pratiques sur le terrain.
- Eric : Product Owner depuis 4 ans au sein de Néosoft Lille. C’était ma seconde participation à l’Agi’Lille et j’étais déjà conquis par ce format qui permet d’ouvrir son esprit sur de nouvelles théories et d’écouter des retours d’expérience souvent rassurants !
L’événement a-t-il tenu ses promesses ? Pouvons-nous dès à présent mettre en place des éléments que nous avons découverts pendant l’événement ? Qui est le père d’Eric Cartman, est-ce le chef, l’officier Barbrady ou l’équipe des Broncos de Denver de 1998 ? Hormis cette dernière question, vous saurez tout en lisant cet article.
Shape Up : allez à l’essentiel pour construire un produit par Julie Demanze & Perrine Maroye
Nos 2 speakers du jour nous présentent ici un REX sur la mise en place de la méthode Shape Up.
Un peu d’histoire : Shape Up est issue de la société américaine BASECAMP. N’étant pas convaincus par leur façon de gérer leurs projets en interne, ils ont élaboré cette nouvelle méthode.
Les principes :
- Le Shape Up se décompose en 4 grandes étapes :
- Shapping : phase durant laquelle nous étudions les besoins. Il en résulte des pitchs qui seront présentés en “Betting Table”
- Betting : phase durant laquelle nous sélectionnons les pitchs pour passage en Build
- Building : phase de 6 semaines durant laquelle chaque équipe met tout en œuvre dans un mode interruptible pour répondre au besoin énoncé du pitch
- Cool Down : phase en parallèle du Betting où, durant 2 semaines, les équipes peuvent se relâcher et s’allouer du temps pour la résolution de bugs, la documentation, la dette technique, les formations…
Et ça change quoi par rapport à Scrum ?
- Des cycles de 6 semaines et non des sprints d’une semaine à un mois
- Des pitchs plutôt que des User Stories
- Document facile à lire
- Qui reprend les informations ci-dessous :
- Problème auquel on veut répondre
- Appétit : quel est le temps que l’on souhaite y consacrer ?
- Solution : quels sont les éléments clés ?
- Risques : quels sont les problèmes envisageables et comment les éviter ?
- No Go : ce que l’on ne veut pas faire
- N’est pas une spécification afin de laisser un maximum de liberté aux équipes de Build
- La notion d’appétit et non d’estimation
- La période de Cool Down
- Avoir du temps pour souffler et prendre du recul
- Espace sanctuarisé
- Du temps pour s’occuper de la santé du produit
En conclusion ?
Dans le cadre de ce REX, la mise en place du Shape Up a permis aux équipes d’améliorer leurs livraisons, d’augmenter l’implication des équipes de Build et de traiter la dette technique durant les périodes de Cool Down.
Mais cela a aussi permis de revoir la forme des échanges entre technique et métier et d’améliorer la définition des priorités métier.
Avant l’Agi’Lille, je ne connaissais pas cette méthode du Shape Up. On y trouve des éléments vraiment intéressants !
Eric
Par exemple, la période de Cool Down qui permet de sortir la tête du guidon, aussi bien pour les équipes de Dev que pour le PO, afin de reprendre un peu de hauteur sur le produit. Cette période n’existe pas en Scrum et nous épuisons souvent les équipes de Dev, à embarquer de plus en plus de dette technique ou à négliger la “santé” de son produit.
L’autre point est la façon de pitcher les besoins. En Scrum, nous avons tendance à écrire des User Stories trop détaillées et de ce fait nous enlevons de la “liberté” aux équipes de Dev lors de la conception. Cette façon de pitcher un besoin m’apparaît plus ouverte et favorise l’échange.
La principale difficulté semble être le cycle 0. Il faut réussir la transition “User Story” vers “Pitch”, embarquer l’équipe dans un nouveau mode de fonctionnement où elle doit avoir suffisamment de maturité pour faire des propositions.
Et si on arrêtait de produire un software inutile ? Par David Laizé
Partons d’un exemple de notre conférencier. Je vais vous raconter l’histoire d’un homme, Michel, qui était fier de lui. Après avoir un peu réfléchi sur l’application qu’il a fait développer, il a eu une super idée qu’il voudrait ajouter. Il est allé voir son CODIR, qui lui a donné le feu vert pour partager cette idée à l’équipe technique qu’il sous-traite pour démarrer les développements et procéder à une livraison le plus tôt possible.
Finalement, son évolution a été utilisée deux fois en production, une fois par lui-même et une fois par l’équipe de “test” (toute ressemblance avec des personnes ayant réellement existé ou des faits qui se sont réellement produits est purement fortuite, merci de votre compréhension).
Cette situation nous est arrivée à tous au moins une fois (même si nous n’en avons pas toujours conscience) et c’est un fait : la moitié de notre backlog ne sera jamais utilisée. Pourtant, les tâches techniques seront effectuées, et ce ne sera que de la perte de temps et de moyens. L’enjeu de cette présentation aura été de donner quelques pistes pour répondre à ce problème.
Le fait de rendre plus concret l’affectation d’un rôle à une user story ou à un besoin métier permet de se poser les bonnes questions sur l’utilité d’une tâche. Ainsi, si vous avez des problèmes de features inutilement développées, vous n’utilisez peut-être pas assez vos personas. Il faut garder à l’esprit qu’être utile, c’est créer de l’impact et donc, changer la vie d’un utilisateur. Imaginez-vous cet utilisateur ? Si la réponse est non, vous pouvez essayer de le matérialiser par vos personas.
De la même manière, si vos User Stories sont des équivalents de specs, alors il y a un problème dans votre transformation Agile. Il est, en règle générale, inutile et contre-productif de passer un temps considérable pour rédiger une User Story. Dans le cas où, essayant de penser à tous les exemples et contre-exemples d’un sujet, vous passez quelques jours (voire quelques semaines) à la rédaction d’une US, vous serez trop attaché au travail que vous aurez investi pour réaliser que tout ou partie de l’US pourrait être inutile. Alors qu’une US écrite en 10 minutes pourra être jetée à la poubelle sans poser de problème à qui que ce soit… Pour écrire de meilleures Stories, écrivez moins !
Mesurez avant de réaliser et après avoir livré. On arrive plus ou moins sur notre premier exemple : avoir une idée c’est bien, mais avoir une idée qui s’inscrit dans un besoin métier qui a été quantifié, c’est mieux. À quoi sert-il d’améliorer un pan de votre application qui ne sera pas utilisé et qui n’aura pas d’impact ? Avoir des indicateurs permettant de connaître l’utilisation de votre application vous aidera prendre de meilleures décisions.
Construisez une équipe user-centric : Dev, PO, testeurs… et faites passer le métier avant toute forme de problème technique. Les réalisations de votre équipe devraient être au service de l’utilisateur.
Pratiquez la suppression comme un sport de haut niveau. Prenez du recul sur les demandes et faites le tri. On peut identifier 4 types de demandes : celles qui sont utiles, celles qui ont de la valeur, celles qui sont faisables et celles qui sont pérennes.
Pour faire simple, ne conservez que celles qui intègrent les 4 catégories.
Cupcake Story par Camille Marquette & Bernard Klymowicz
Et si on ajoutait une nouvelle recette de cupcake au citron ?
À partir de ce besoin simple, comment nous, Product Owner, allons réussir à découper ce besoin en User Story ?
Par petits groupes, nous allons procéder méthodiquement :
- Et si on interrogeait Bernardo, le propriétaire de la boulangerie, pour connaître ses attentes et sa façon de procéder actuellement ?
- Travaille-t-il seul ou en équipe ?
- Quel est le rôle des membres de son équipe ?
- Qu’a-t-il déjà mis en place pour s’approvisionner en matières premières ?, etc.
- Et si on mettait en place des personas pour bien définir nos futures User Stories ?
- Définir correctement ces personas nous permettra de définir les User Stories avec des attentes ciblées
- Imaginons le process de réalisation de l’achat des matières premières, en passant par l’étude de marché, la réalisation de la recette, la commercialisation, la communication et enfin, par la fidélisation de nos clients… On a vu en grand…
- Comment définir la valeur de chaque étape ? Comment définir le MVP ?
- C’est bien d’imaginer (ou d’essayer d’imaginer) un process “complexe”, mais est ce que tout cela est bien nécessaire ?
- Qu’attend vraiment Bernardo de cette nouvelle recette ? Juste ajouter une nouvelle recette à son catalogue ou y a-t-il d’autres objectifs derrière cela ?
- Et quand Bernardo, finalement, nous annonce une date de lancement très courte de cette nouvelle recette, comment allons-nous réussir à délivrer l’essentiel ?
Voilà autant de questions que nous nous sommes posées durant ces 110 minutes. Nous avons confronté nos idées avec les autres groupes mais rapidement nous sommes revenus à “qu’est-ce que l’essentiel pour Bernardo” ? Et “comment délivrer au plus vite la nouvelle recette de cupcake ?”
Rendez l’agilité aux Devs par Fanny Klauk
Fanny nous présente différentes saynètes ou Lili, dev full stack, intègre sa nouvelle équipe. Comment va-t-elle gérer son intégration et quelles sont les difficultés rencontrées ?
La première phase déterminante est l’onboarding. S’il est préparé, il permet à Lili d’avoir un sentiment d’appartenance, d’avoir confiance en elle et de rapidement identifier les membres de son équipe.
À l’inverse, si cette étape est négligée, elle sera très vite démotivée, elle se sentira inutile et ne trouvera pas son rôle au sein de cette nouvelle équipe.
Vient ensuite la notion d’autonomie de l’équipe. On parle souvent d’équipe “autoorganisée”. Si les rôles et responsabilités ne sont pas clairement définis, il sera complexe d’atteindre cette autonomie.
L’objectif est multiple : impliquer les équipes et ainsi gagner en motivation, en légitimité et en confiance pour ne pas hésiter lorsqu’il faut innover ou tester des nouveaux process au sein de l’équipe.
L’inspection est une notion souvent négligée au sein des équipes… mais elle est pourtant essentielle car elle nous permet d’analyser ce que nous faisons (bien ou pas) et surtout de nous améliorer en continu tout au long des itérations.
La mise en place des itérations, délivrer de façon continue, sont une façon d’impliquer l’équipe car cela favorise l’entraide, la responsabilisation, l’engagement et l’adhésion. Nous avons un objectif commun et une vision commune de la valeur que nous souhaitons déployer.
Tout cela n’est pas possible sans partage et sans feedback. Si l’équipe se sent écoutée, elle sera force de proposition et d’autant plus impliquée. Et ne pas oublier de donner du feedback sur ce qui est réalisé, cela sera autant de petites victoires à célébrer.
En conclusion, n’oublions pas ce que nous dit le manifeste Agile : “Les individus et les interactions plutôt que les processus et les outils.”…
L’art de conclure par Antoine Douchet
C’est assez rare pour le souligner, mais cette dernière conférence de la journée aura démarré par une (sombre ?) histoire de coloscopie… En effet, une étude avait démontré que peu importe la durée de l’examen, le patient ne retenait véritablement que deux choses concernant la gêne occasionnée :
- L’intensité maximale ressentie durant toute la durée de l’expérience
- L’intensité finale ressentie à l’issue de l’expérience
Et ce qui est valable pour les coloscopies l’est aussi partout ailleurs et est parfaitement généralisable à beaucoup d’autres situations mettant en jeu une expérience utilisateur. C’est ce que l’on appelle la peak-end rule.
D’un point de vue RH ou managérial, des études montrent que 70% des entreprises ne pensent pas au départ de leurs collaborateurs alors que 85% des collaborateurs pourraient parler en bien de leur dernière entreprise si la fin de leur aventure avait été positive. Des petites idées toutes simples permettent de laisser un bon souvenir :
- La reconnaissance, mettre en valeur la progression du collaborateur dans la société
- Lui donner du feedback, en lui disant clairement ce que l’on a aimé chez lui, comment il peut encore s’améliorer…
- La convivialité, partager un moment collectif (et pas nécessairement aux frais de celui qui part)
- Garder le lien, même si ce n’est pas toujours évident. Idéalement en faisant ressentir au collaborateur que même s’il n’est plus là, il fera toujours partie de la grande famille de l’entreprise.
Maintenant, d’un point de vue product owner ou direction de projet, il serait souhaitable d’impacter positivement la fin de l’expérience utilisateur sur vos projets, notamment en travaillant sur la temporalité.
Par exemple, si vous voulez consulter un article sur le site du journal Le Monde sans être abonné, vous aurez un pic d’intensité de plaisir lors de la lecture des 20% offerts, qui sera contrebalancé par un fort sentiment de frustration lorsque l’on vous demandera de payer quelques euros pour terminer votre lecture. Cela vous laissera un petit goût amer et peu d’envie de réitérer la chose.
Alors que lors de votre prochaine visite chez Ikea, vous pourrez faire un room tour plutôt agréable (même si on a toujours cette sensation de tourner en rond et de se perdre), où vous trouverez peut-être du mobilier qui vous conviendra (on arrive au pic de l’expérience), puis arrivera le final avec la déception du retrait de la marchandise et du passage en caisse… Mais tout ce que vous retiendrez, ce sera le hot dog ou les chocolats suédois que vous dégusterez en récompense de vos efforts à la sortie du magasin.
Enfin, animez vos fins de réunions, ne terminez plus vos visios par un “ désolé, je dois vous laisser, j’ai une autre réunion dans 2 minutes”. Le sentiment de l’équipe sera d’autant plus positif que la fin de vos échanges sera marquante.
Pour aller plus loin sur le sujet, vous pouvez lire le Closing Cook Book, qui vous donnera des pistes pour mieux clôturer vos événements ou vous tourner vers les Debriefing Cards pour un moment collaboratif de prise de recul sur vos événements.
L’Agi’Lille a-t-il répondu à nos attentes ?
J’en ressors conquis, reboosté et avec des nouvelles idées. Les mots qui sont revenus le plus souvent cette année sont : “humain”, “bon sens”, “revenir à l’essentiel”, “feedback”. En plus des concepts intéressants, une bonne piqûre de rappel sur les fondamentaux nous remet les pieds sur terre.
Eric
Première participation, je retiens des concepts intéressants et applicables dès maintenant, qui permettront soit de donner plus de valeur à notre travail, soit d’en améliorer les conditions.
Raphaël
Nous pourrions penser qu’en 2023, après plus de vingt ans d’existence des premières pratiques Agiles, il ne serait peut-être plus utile d’orienter une bonne partie des conférences sur l’humain et/ou les pratiques essentielles. Pourtant, nous avons pu voir des conférences sur des thèmes tels que “Revenir à l’essentiel de nos pratiques Agiles”, “Sans soft skills, que valons-nous ?”, “Rendez l’agilité aux devs”, “Je suis juste humain” et tant d’autres.
Nous ne l’avions pas imaginé au départ, mais peut-être est-ce aussi cela le but de ces Agile Tours : remettre l’accent sur ce qui est vraiment important dans nos pratiques quotidiennes de l’agilité !
Et peut-être serait-il utile de porter ces valeurs auprès de nos clients en les y amenant lors de la prochaine édition…
Un grand merci à Nord Agile pour l’organisation ! Merci également aux nombreux intervenants et bénévoles qui œuvrent pour que cet événement puisse avoir lieu et soit un beau succès.