Vianney LEMAN, auteur/autrice sur EKITE https://ekite.info Vos défis, notre passion Wed, 08 Apr 2026 13:55:47 +0000 fr-FR hourly 1 https://wordpress.org/?v=7.1.3 https://ekite.info/wp-content/uploads/2023/06/cropped-favicon2-150x150.png Vianney LEMAN, auteur/autrice sur EKITE https://ekite.info 32 32 ? J’ai vibe codé mon app en 5 jours : entre magie et consommation https://ekite.info/2026/02/08/jai-vibe-code-mon-app-en-5-jours/ Sun, 08 Feb 2026 14:55:10 +0000 https://ekite.info/?p=4458 L’article ? J’ai vibe codé mon app en 5 jours : entre magie et consommation est apparu en premier sur EKITE.

]]>

Une sacrée aventure

Bon, on va se dire les choses franchement : après des années de frustration en tant que CEO à avoir des idées sans pouvoir les coder, quand j’ai vu arriver l’IA, je me suis dit qu’enfin je pourrais moi aussi transformer mes idées en projet sans savoir coder ! 

J’ai passé 5 jours à « vibe coder » avec plein de bonnes intentions. C’était une expérience avec des hauts et des bas, mais pour la première fois, MES idées devenaient du code. Et ça a marché. Je vous partage tout ça.

 

Suivez cet article en vidéo

Vivez cet article avec moi en 3 vidéos, disponibles ici:

Vibe coding story 1: La préparation! Vibe coding story 2: On génère notre app Vibe coding story 3: Les conclusions

 

 

Le déclic : la frustration de CEO

Flashback?: dans une ancienne vie, j’étais CEO de ma boîte. Et ma plus grosse frustration?? 

Je voyais TOUT?: les user journeys, les features, les versions, les écrans de mon produit… Je savais exactement ce qu’il me fallait. 

Mais voilà?: je ne savais pas coder. 

C’était frustrant. Être dépendant des devs, ne pas avoir assez de budget pour avoir une vraie équipe… J’avais l’impression d’avoir une Ferrari dans la tête et un vélo pour avancer. 

Et puis?l’IA est arrivée. Elle s’est?améliorée. Et maintenant, apparemment,?elle sait coder. 

L’idée du?vibe coding?c’est de «?parler naturellement à une IA qui code tes idées pour toi?». Pas forcément besoin de plan précis, pas de structure rigide. Tu lances ton idée, l’IA code, ça bug, vous corrigez ensemble, et hop on recommence. Qu’est-ce qui pourrait mal se passer?? 

Pour la première fois de ma vie, je pouvais passer de l’idée au code. Direct. Et?itérer?plusieurs fois?par heure. 

Alors vous me connaissez, en tant que product owner, je me suis préparé, j’ai créé un plan précis, étape par étape… que je n’ai pas du tout suivi?! L’IA est imprévisible, je me suis laissé porter et même emporté. Ça fait partie de l’expérience… et bizarrement… ça marchait.? 

 

Alors oui, j’ai découvert après coup que le?context engineering?existe et que c’est plus efficace. Mais pour un ex-CEO frustré qui voulait juste voir ses idées prendre vie… le vibe coding, c’était une première libération. ? 

 

Avant de commencer Mon setup

Les outils que j’ai utilisés?:

    • Cursor?: l’IDE avec IA intégrée le plus connu (plan pro + 5?US$ de crédits Anthropic = 40?US$ au total). 
    • Claude?: mon architecte personnel (plan pro 20?US$). 
    • ChatGPT?: mon illustrateur (plan gratuit). 

    Petit conseil?: prenez directement le plan pro de Cursor. Moi j’ai voulu faire le malin avec la version gratuite… double passage en caisse et galères en prime?! 

 

? Le workflow qui a (presque) tout changé

 

Étape 1?: L’idéation avec Claude 

L’idée était simple?: créer une app à la Duolingo pour apprendre des choses utiles aux product owners pendant 3 minutes par jour. 

Alors c’est ce que j’ai demandé à Claude.ai. Sans rien d’autre. 

  • Des specs techniques?? Je ne suis pas développeur. 
  • Des écrans dessinés?? Je ne suis pas designer.
  • Un nom d’application?? J’en avais des milliers. 
  • Des user journeys?? Mon idée était trop vague. 

Je voulais surtout?voir où tout ça allait nous emmener. 

Et je n’ai pas été déçu?! Claude m’a sorti?: 

  • une architecture complète?; 
  • les technos à utiliser (React, Vite, Tailwind… que je ne connais pas)?; 
  • des suggestions de features auxquelles je n’avais même pas pensé. 

C’était dingue?: mon idée floue devenait un vrai projet structuré. En direct. J’avais l’impression que quelqu’un travaillait avec moi sur mes idées, comme une équipe?! 

Mon retour d’expérience?: l’IA est géniale pour transformer une idée vague en plan concret. Mais attention, j’ai perdu 1?heure parce qu’elle m’a fait rêver à partir sur des choses géniales mais beaucoup trop complexes. Même avec une idée floue, donnez le maximum de contexte. 

 

Étape 2 : La préparation (un si beau plan jamais exécuté)

Vivez cette étape en live avec la vidéo 

Vibe coding story 1: La préparation!

 

PO organisé et pour bien préparer cette expérience, j’ai créé?: 

  • un workflow en 7 étapes?; 
  • une liste des outils d’IA que j’allais utiliser à chaque étape. 

Ce workflow précis me permettait de construire une application de A à Z en passant par toutes les étapes critiques sans rien oublier. 

Ça, c’est dans la théorie, car l’IA m’a emmené autre part. C’est à la fois très bien, car ça ouvre des portes, mais aussi très mal, ça m’a facilement détourné de là où je voulais aller.

 

Mon retour d’expérience?: ici j’ai fait exprès de ne pas recadrer pour voir où est-ce que cela nous emmenait, ça faisait partie de la découverte et de ce que je voulais vivre. Et partager. Les phrases «?Parfait?!?», «?Super?!?», «?Très bonne idée?!?», «?Tu as totalement raison?!?», etc. que l’IA génère pour des interactions positives sont trompeuses et participent au fait de dévier de là où je voulais aller au départ. 

 

Étape 3 : L’exécution avec Cursor (le vrai vibe coding commence)

Vivez cette étape en live avec la vidéo 

Vibe coding story 2: On génère notre app

 

C’est là que ça devient dingue. Cursor génère le code, et moi je regarde, fasciné (au début) puis un peu inquiet (avec de l’expérience). 

 

Premier impression?: bluffant ? 

  • Il explique TOUT en langage humain?– «?Je crée un composant pour afficher les questions.?», «?J’ajoute une logique pour tracker les bonnes réponses.?» 
  • Le debug simple?– Quand ça plantait (70?% du temps), il créait des pages de debug spécifiques juste pour isoler le problème. 
  • Le dialogue constant?– «?Peux-tu vérifier si tu vois un bouton bleu???», «?Est-ce que le texte s’affiche maintenant???» 
  • Un gain de temps monstrueux – par exemple, si je lui disais?: «?Il me faut 200 questions pour PO avec 3 niveaux de difficulté?», 5 minutes plus tard, j’avais ma base de données complète, formatée, catégorisée. J’aurais mis 5 jours à faire ça à la main. 
  • Il sait me contredire?– Quand mon idée ne semble pas bonne, il me le dit (avec beaucoup de pommade) mais il le fait. 

 

Deuxième impression?: vortex à temps ?? 

  • Parfois 15 minutes d’attente où tu pars chercher un café (ou deux). 
  • Dans 70?% des cas, le code généré est buggé. 
  • Dans 20?% des cas, le code généré casse autre chose. 
  • Les allers-retours constants?: code ? test ? bug ? fix ? test ? bug… 
  • Ses phrases mettent toujours l’utilisateur en avant et elles deviennent lourdes?: «?Incroyable?!?»?; «?Super idée?!?»?; «?Mais oui c’est génial?!?» pour la 100ème fois fait l’effet inverse.

 

Troisième impression?: vortex à tune ? 

On ne va pas se le cacher, c’est pas donné. Avec mes différentes galères, j’ai dû payer?: 

  • un abonnement pro à Cursor?: 20?US$ /mois?; 
  • un abonnement pro à Claude?: 20?US$ /mois (inutile pour Cursor mais je ne savais pas)?; 
  • des crédits pour accéder aux API d’Anthropic pour utilisation de Claude dans Cursor Pro (20?US$), 

soit un total de 60?US$ pour comprendre comment tout ça fonctionne. Une leçon chèrement apprise. 

Mon retour d’expérience?: prenez simplement?Cursor Pro, Claude et d’autres IA sont intégrées, pas besoin du reste.

 

Impression finale 

Pour la première fois depuis que j’ai quitté mon rôle de CEO, j’ai pu créer quelque chose de A à Z. Pas une idée complexe avec 50 specs, juste un «?Duolingo pour PO?» qui est devenu réalité. Sans intermédiaire. Sans attendre. Juste moi, une idée vague, et une IA qui structure et code. Et rien que ça, c’est fou. 

 

? Les vraies leçons

Ce qui marche vraiment?: 

  1. Le contexte est ROI?– Sans bon contexte, l’IA fait n’importe quoi.
  2. Les prompts optimisés?– Je prompte ? Je demande à une IA d’optimiser ce prompt ? Je demande à une IA d’implémenter ce prompt.? 
  3. La structure avant tout?– Mes fichiers de structure (architecture, vision, base de données, etc.) ont sauvé le projet. 

 

Ce qui m’a surpris?: 

  • L’IA debug mieux que moi (elle isole, teste, corrige). 
  • C’est ultra addictif (j’ai bossé des soirées entières). 
  • Les erreurs sont des opportunités d’apprentissage et vous rendent plus précis. 
  • L’IA pose RAREMENT des questions?– Elle ne vérifie pas ses assomptions et son code, même si elle n’a rien compris. 
  • L’IA structure tes idées floues?– Tu dis «?Duolingo pour PO?», elle te sort un plan complet. 

 

Le piège à éviter?: 

L’IA ne te dira jamais?: «?Attends, t’es sûr de ton truc???». Elle exécute. Point. Si tu dis «?fais-moi un bouton qui supprime tout?», elle le fait. Sans confirmation. Sans warning. 

 

Mon retour d’expérience?: 

Faites des sessions de planification. Il existe maintenant un mode «?planification?» pour préparer un sujet avec la base de code à disposition avant de commencer à coder. Durant la préparation, demandez à l’IA de créer un document et pendant le développement de se baser sur ce document.  

 

Mes workflows finaux? 

Workflow général 

  1. Donnez à Claude un MAX de détails sur votre projet. 
  2. Demandez quels documents sont indispensables pour commencer le projet. 
  3. Travaillez avec lui sur ces documents et demandez-lui de choisir des technologies connues des LLM. 
  4. Mettez ces documents dans votre projet (dossier «?docs?» par exemple). 
  5. Dans Cursor, dites-lui de se référer à ces documents avant tout développement. 
  6. Avant de demander quelque chose de complexe, demandez à une IA de vous poser des questions et de faire un prompt optimisé. 
  7. Mettez ce prompt optimisé dans Cursor et laissez-le travailler. 
  8. Si bug ? capture d’écran + prompt de correction avec l’attendu ? Cursor corrige ? Vous testez. 
  9. Demandez-lui de commit / merge & répéter. 

 

Workflow nouvelle fonction 

  1. Parlez de votre fonction à une IA ou dans le mode «?Planification?» de Cursor. 
  2. Demandez-lui de vous poser des questions si des choses ne sont pas claires. 
  3. Demandez-lui de créer un plan ou un prompt optimisé. 
  4. Donnez ce prompt à Cursor et regardez-le le générer. 

 

Workflow débuggage 

  1. Faites une capture d’écran du bug. 
  2. Détaillez où il se situe (quelle page, quelle partie, titre de la section, etc.). 
  3. Donnez l’état actuel. 
  4. Donnez l’état attendu. 
  5. Mettez en avant les choses qu’il ne doit PAS toucher. 
  6. Donnez ce prompt à Cursor et regardez-le le corriger. 

 

Vibe coding vs context engineering?: la vraie différence 

Mettons les choses au clair. Ce que j’ai fait n’est?pas du?vibe coding?c’est plutôt du?context engineering?car?: 

    • j’avais préparé des documents en amont avec l’aide d’une IA?: 
    • base de données?; 
    • vision du projet?; 
    • technologies à utiliser en front et back?; 
    • architecture, 
  • cela a permis à l’IA d’avoir tout le contexte du projet?; 
  • ce qui a énormément réduit le nombre de bugs et d’hallucinations?; 
  • cela m’a fait gagner beaucoup de temps et beaucoup de crédit. 

 

Mon analyse perso

Vivez cette étape en live avec la vidéo 

Vibe coding story 3: Les conclusions

 

Les points forts?: 

??C’est incroyable de pouvoir faire des apps sans savoir coder?– Sérieux, après des années de frustration, voir mon idée devenir réalité… magique?! 

??L’IA = Guide bienveillant?– Elle vous prend par la main, vous explique, vous rassure quand ça plante. 

??Ça se debug «?tout seul?»?– L’IA analyse, isole le problème, propose la solution. Vous validez, ça roule. 

??Un coéquipier qui bosse H24?– Pas de pause-café, pas de congé, juste focus sur VOS idées 

??Learning by doing?– Vous comprenez enfin ce que font vos devs. 

??Rapidité de prototypage?– 5 jours vs 5 mois avec une équipe classique. 

 

Les limites?: 

??Workflow de départ?? Oublié direct?– J’ai commencé avec un plan, puis j’ai vibé… chaos total. 

??Ça fait parfois n’importe quoi?– Genre vraiment n’importe quoi. Des fois on se demande si l’IA a fumé. 

??L’IA = Guide énervant?– Quand elle ne comprend pas après 5 reformulations, on veut la secouer. 

??Faut être ULTRA précis?– On oublie un détail?? Elle fait l’inverse de ce qu’on veut. 

??Zéro question de sa part?– Elle suppose, elle code. Même si c’est pas du tout ce qu’on voulait. 

??Prix élevé?– 40? partis (Cursor Pro + crédits). Pour un proto, ça pique. 

??70?% buggé au départ?– Oui, 70?%. Les 30?% qui marchaient, c’était déjà un miracle. 

??La qualité du code???– Aucune idée, mais probablement pas terrible. 

??La dette technique?– On en reparle dans 6 mois. 

 

Le vrai bilan?: 

Malgré les galères, le ratio effort/résultat est dingue. Oui c’est frustrant, oui c’est cher, oui ça bug. Mais j’ai codé une app fonctionnelle en 5 jours sans savoir coder?! 

 

Ma vision?: plus il y aura d’IA plus il y aura de développeurs. 

Vous pensez que l’IA prendra le travail des développeurs?? Après cette expérience, c’est sûr que non. 

Le travail des développeurs va peut-être un peu évoluer, mais il est absolument essentiel pour cadrer, pour comprendre, pour corriger, pour orienter et bien plus encore, car aujourd’hui c’est clair,?ce n’est pas prêt pour la production. 

Le vibe coding et le context engineering, c’est très intéressant pour un?projet personnel?qui n’aurait de toute façon?pas eu les moyens d’embaucher des développeurs. 

Mais dans la vraie vie et en production chez des clients, vous ne POUVEZ PAS l’utiliser pour une seule et bonne raison?: on ne peut pas lui faire confiance. Sans confiance, pas d’utilisation et donc pas de production. 

 

Qu’en disent les développeurs?? 

J’ai demandé à des développeurs d’analyser la base de code?(disponible sur GitHub)?et même de tester par eux-mêmes le vibe coding et en résumé?: ils ont pété un câble. 

«?Je n’ai pas confiance.?» 

Entre les fois où l’IA ne respectait pas ce qu’on lui demandait, où elle crée des classes qui s’appellent littéralement Hello World et qui sont inutiles, quand elle modifie une partie du code de manière arbitraire ou qu’elle en supprime d’autres soi-disant non utilisées, quand on lui dit qu’elle se trompe mais qu’elle continue quand même, quand elle fait des erreurs de débutant avec des classes, dans des classes, dans des classes en Java… C’est risible. 

Mais très utile pour certains cas. 

Créer la structure pour développer?:?par contre, un cas d’utilisation intéressant est pour lancer un dev?: lui donner le ticket Jira et lui demander de créer toute la structure nécessaire en prenant exemple sur une autre partie du code, ça, ça marche très bien et ça fait gagner beaucoup de temps, car la structure est faite?; le dev peut commencer en quelques minutes au lieu de quelques heures. 

Créer des scripts?:?pour créer des scripts, l’IA crée exactement le même code que ce que le développeur avait en tête. Sauf qu’elle a mis deux minutes à le faire, alors que le dev aurait mis quatre heures. 

 

Mes conseils pour vous lancer?: 

  1. Commencez petit?: si vous avez une grande idée, découpez-la en petits bouts. 
  1. Pour le context engineering?: préparez vos docs AVANT (vision, archi, features) 
  1. Pour le vibe coding?: lancez-vous direct, découvrez en route. 
  1. Acceptez l’échec?: mon app a planté 47 fois (et c’était du context engineering?!) 
  1. Optimisez les prompts?: économisez vos crédits. 
  1. Choisissez votre style?: 
  • Vous êtes PO/structuré?? ? context engineering 
  • Vous voulez explorer?? ? vibe coding 
  1. Préparez le café?: le code ne s’écrit pas instantanément, c’est plus long que ce que vous pensez. 

 

Le mot de la fin 

Après cette expérience, je ne vois plus le développement de la même façon. 

Est-ce que je vais remplacer mes développeurs?? Non?! Sauvez-moi, surtout pas. 

J’ai eu le sentiment d’avoir besoin d’un développeur pour savoir ce que l’IA faisait et je me suis retrouvé plusieurs fois démuni face à des choix techniques. 

Est-ce que je comprends mieux leur taf?? Carrément. 

Mais surtout?: j’ai enfin cassé cette barrière qui me frustrait depuis des années. Je suis enfin passé de l’autre côté pour comprendre le développement et l’IA. 

Le?context engineering?(ce que j’ai fait sans le savoir), c’est parfait pour un ex-CEO/PO habitué à structurer. Vous préparez vos docs, vous donnez le contexte, l’IA exécute. C’est rassurant, c’est efficace, ça limite les bugs. 

Le?vrai vibe coding?? Je ne l’ai pas encore testé. Mais maintenant que je sais que je PEUX créer, j’ai envie d’essayer. Partir sans filet, juste avec une idée et voir où ça mène. 

Pour un P.O. structuré, le context engineering c’est génial. Pour explorer et s’amuser, le vibe coding doit être dingue. Pour du sérieux en production?? Embauchez des vrais devs même s’ils sont augmentés par l’IA… 

La prochaine fois?? Je pense créer une équipe d’agents IA qui travaillent entre eux et je suis déjà en train d’expérimenter sur le sujet. Est-ce que ce sera un prochain article?? Peut-être… ? 

Alors voilà, j’ai créé une app sans savoir coder. Et vous savez quoi?? Vous pouvez le faire aussi. 

 

Envie de tester?? Commencez par un petit projet en mode vibe coding. C’est fun et formateur. Puis passez au context engineering quand vous serez à l’aise. Et n’oubliez pas?: en vibe coding, c’est normal que ce soit le bordel au début. 

Des questions?? Des retours d’expérience?? N’hésitez pas à nous écrire?! 

 

 

 

Bonus: Quelques prompts

Objectif  Prompt 
Brainstorming  Je voudrais faire une application qui permet d’apprendre Jira en 3 minutes par jour. 

Cette application est destinée aux product owners. 

Son but est de proposer différents types d’exercices pour apprendre aux PO à utiliser les fonctions de Jira basiques et de plus en plus poussées. 

Elle doit être simple et fun à utiliser. 

Brainstormons ensemble sur le sujet. 
Évoquer Duolingo et recentrer  Merci pour ces idées?! J’avais plus en tête une application super simple et gamifiée comme Duolingo?! Mais adaptée aux PO. J’avais pensé à un parcours d’apprentissage qui commence par les bases de Jira jusqu’aux fonctions avancés, qu’en penses-tu?? 
Demander un logo  Je vais demander à ChatGPT de me générer un logo pour l’application, fais-moi un prompt optimisé avec tout le contexte qui explique le nom. Je veux laisser toute la créativité à ChatGPT. 

 

Structure du MVP 

Objectif  Prompt 
Génération de la structure du MVP  OK maintenant avançons sur la structure que nous voulons pour notre MVP (pas le contenu des exercices, nous ferons ça plus tard). Propose-là-moi. 

 

Prototype initial 

Objectif  Prompt 
Générer le prototype de mon app en React  Créez la version fonctionnelle initiale de PO?Bingo à partir des fichiers de contexte fournis. 

 

Workflow git 

Objectif  Prompt 
Générer un workflow git  J’aimerais créer un fichier de rules dans Cursor en markdown qui gère proprement le versionning. J’aimerais aussi faire en sorte que chaque nouvelle feature soit dans une branche à part (que je peux voir sur Versel pour tester). Une fois testée, j’aimerais qu’elle soit mise dans la branche principale. Créer un fichier où j’injecte des commandes custom et simples et ensuite Cursor lance tout automatiquement. 

 

L’article ? J’ai vibe codé mon app en 5 jours : entre magie et consommation est apparu en premier sur EKITE.

]]> 4458 9 astuces pour que vos démos démontent https://ekite.info/2024/11/29/9-astuces-pour-que-vos-demos-demontent/ Fri, 29 Nov 2024 09:50:55 +0000 https://ekite.info/?p=2112 “Tu n’as jamais participé à une démo de Vianney ? Tu devrais y aller, elles sont trop bien !” Bonjour à tous! Je suis Vianney, PO depuis presque 8 ans et voila ce qu’on dit à propos de mes démos. Les « démos » jouent un rôle essentiel dans ce processus, offrant une occasion unique de mettre en lumière […]

L’article 9 astuces pour que vos démos démontent est apparu en premier sur EKITE.

]]> “Tu n’as jamais participé à une démo de Vianney ? Tu devrais y aller, elles sont trop bien !”

Bonjour à tous! Je suis Vianney, PO depuis presque 8 ans et voila ce qu’on dit à propos de mes démos.

Les « démos » jouent un rôle essentiel dans ce processus, offrant une occasion unique de mettre en lumière les fonctionnalités, de recueillir des retours précieux et de susciter l’enthousiasme autour du produit. Cependant, réussir une démo ne se résume pas simplement à cliquer à travers les écrans. Cela nécessite une préparation minutieuse, une compréhension approfondie des besoins des utilisateurs, et une dose subtile de savoir-faire.

Dans cet article, je partage quelques astuces personnelles, qui ne sont dans aucun livre et que j’ai affinées au fil du temps. Ces conseils pratiques vont au-delà des aspects techniques, plongeant dans l’art de communiquer efficacement, de captiver l’audience et de transformer chaque démo en une expérience mémorable. Que vous soyez un product owner chevronné ou que vous débutiez dans ce rôle, ces astuces sont conçues pour vous aider à exceller lors de vos présentations et à maximiser l’impact de votre produit. Préparez-vous à élever vos démonstrations au niveau supérieur !

 

DISCLAIMER : cet article s’inscrit dans les limites de mon contexte transverse et international. Cette démo se fait sur l’exemple d’un tout nouveau projet. Sur ce, bonne lecture !

1. Restez serein: créez un modèle réutilisable

Ne réinventez pas la roue à chaque démo, créez un modèle!

Dupliquez-le à chaque nouvelle démo et partez de là pour la construire, cela permettra de :

  • vous faciliter la vie lors de la préparation ;
  • faciliter la vie de votre auditoire. Garder la même structure, la même identité visuelle permet à tout le monde de connaître son environnement et de se concentrer sur ce qu’il y a de plus important : ce que vous avez à présenter.

?N’oubliez pas que votre modèle n’est pas figé et doit continuer à évoluer : ajoutez, retirez des sections au fil des feedbacks et tenez-le à jour avec la nouvelle charte graphique de votre entreprise !

Concrètement, voici la structure que j’utilise (fait sur Google Slide):

– La page d’attente

Cette page est utilisée au début de la démo pour attendre les retardataires. Elle présente le nom de mon produit, le nom de mon équipe, une mention « Live demo » pour bien dire que ce n’est pas enregistré, et la date du jour.

? N’hésitez pas à aussi y ajouter une musique d’attente à faible volume, c’est toujours plus sympa.

Page d'attente d'une démo agile

– Le sommaire

Cette slide indique tout ce que nous allons voir durant cette démo et change très rarement:

Cette slide indique tout ce que nous allons voir durant cette démo et change très rarement :

  1. infos sur l’équipe : voir « Créez une grande famille » ;
  2. résolution des bugs et améliorations : les bugs, il faut en parler. Listez ceux que vous avez résolus sans forcément les montrer mais avec au moins une capture d’écran pour le contexte ;
  3. nouvelles fonctionnalités : montrez les maquettes puis la fonctionnalité en direct. Préparez bien cette partie pour éviter l’effet démo (voir « Ce n’est pas grave si ça bug ») ;
  4. feuille de route : montrez à votre auditoire que vous avancez (voir « Fournissez un bon moyen de suivre votre avancement »). Pour éviter d’utiliser des dates, classez les choses à faire dans votre roadmap selon 4 critères :
    • maintenant : ce que vous allez faire au prochain sprint ;
    • suivant : ce que vous allez faire durant le sprint d’après ;
    • plus tard : vos objectifs moyen terme ;
    • après : vos objectifs long terme ;
  5. one more thing : le seul élément facultatif (voir « Restez surprenant ») ;
  6. AMA (ask me anything) : laissez un petit temps durant lequel votre auditoire peut vous poser des questions en direct (voir « Créez une grande famille »).

Agenda d'une rétro agile

 

2. Restez surprenant: le « One more thing »

Ajoutez parfois un élément surprenant comme une section « One more thing » pour annoncer de grandes nouvelles ou partager des victoires ! Avec cette section facultative votre auditoire se demande s’il y aura une nouvelle surprise et cela les incitera à venir voir votre démo !

 

 

3. Créez une grande famille

Même si vous et votre équipe développez des logiciels, vous n’êtes pas des robots. Vos utilisateurs ont parfois du mal à le comprendre. Pour éviter cela vous pouvez:

– Session question/réponse

Lancer une session question/réponse

Cette section peut faire peur au départ, car elle vous met face à tout le monde sur n’importe quel sujet, mais elle vous rend aussi très accessible. Vous n’êtes plus PO d’une autre équipe, vous vous rendez disponible pour tous maintenant. Pour cet exercice, rassurez-vous :

  • vous connaissez votre sujet sur le bout des doigts ;
  • vous n’êtes pas seul, votre équipe est là pour vous aider ;
  • vous n’avez pas de réponse ? Pas de panique, utilisez la fameuse phrase « Je n’ai pas la réponse à votre question mais je la note et je reviens vers vous par mail dans la journée » ;
  • vous êtes accessible.

– Infos sur l’équipe

Avec l’accord de votre équipe, faites une section « Infos sur l’équipe » dans laquelle vous communiquez plein d’infos d’équipe : nouvelle arrivée, départ, congé paternité ou maternité, formation, vacances, etc. De cette manière, tout le monde suit les événements et se rend compte que la capacité à faire n’est pas toujours de 100 %, il y a des aléas ! Et en cas de retard, cela est plus facilement justifiable : 4 arrêts maladies imprévus, les engagements vont être difficiles à tenir, tout le monde s’en rendra compte.

Team update dans une rétro agile

 

4. Ne cachez pas la complexité…

Faire de l’informatique c’est parfois complexe et présenter la complexité à un auditoire qui ne comprend pas la technique est parfois compliqué.

Exemple avec le lancement d’un nouveau projet

Dernièrement, j’ai lancé un nouveau projet et j’ai annoncé 6 mois de travail pour 5 écrans. Pour que tout le monde se rende compte que pour que ça fonctionne il faut aussi pleins de module.Dans ce cas, voici ma méthode:

 

4.1. Pour chaque écran utilisateur (maquette à l’appui pour le contexte), décrivez chaque module nécessaire à son fonctionnement

UI et module d'un nouveau projet

 

4.2. Regroupez tous les modules dans une seule slide pour montrer la complexité…

Sche?ma Complexe sans explication pour une démo agile

 

4.3. … Mais restez simple

Une fois que vous avez montré la complexité, redescendez d’un cran (voire même plusieurs !), vous n’êtes pas là pour perdre tout le monde.

Pour ce faire, réexpliquez le rôle de chaque élément avec des notions compréhensibles par tous :

  • ce module est pour les utilisateurs ;
  • ce module pour la sécurité ;
  • celui-ci pour la rapidité ;
  • celui-là pour la communication, etc.

Module et explications d'un nouveau projet agile

 

 

5. Fournissez un bon moyen de suivre votre avancée

Pour indiquer votre avancement, reprenez votre schéma directeur que vous connaissiez déjà et présentez-le à chaque démo. Ajoutez-y une légende simple pour différencier ce qui n’est pas fait, ce qui est en cours et ce qui est terminé et présenté en démo :

Sche?ma Complexe d'un nouveau projet agile

 

6. Soyez régulier ??

Ne prenez pas le rituel de la démo pour une chose facultative. Soyez régulier. Envoyez une invitation récurrente toutes les x semaines selon votre sprint et faites-la. Peu de choses à présenter ?

Ce n’est pas grave !

Expliquez un de vos concepts techniques plus en détail avec des schémas, partagez vos interrogations avec votre auditoire, faites un petit atelier brainstorming, présentez de nouvelles maquettes d’interface. Il y a plein de choses à communiquer. Ne pas faire une démo ça arrive, mais souvenez-vous : votre régularité prouvera votre sérieux, votre engagement et augmentera la confiance (et la tolérance) de tous envers vous, votre équipe et votre projet.

 

7. L’effet démo ?

Il n’y a que ceux qui ne font rien qui ne se trompent pas.

Gardez bien ça en tête quand vous vouliez montrer quelque chose et que ça ne fonctionne pas. Très récemment ça m’est arrivé : 3 jours de préparation. Un gros teasing sur plein de fonctions. « Soyez là, ça va être fou » et tout le teasing. Le lundi, ça fonctionne. Le mardi soir, ça fonctionne. Le mercredi matin : 20 min avant la démo, je me rends compte que, à cause d’une autre équipe, ça ne fonctionne plus.

Après la frustration, finalement ce n’était pas si grave ! Le but est de montrer ce que vous avez fait et vous n’avez pas pu le faire à ce moment-là, mais souvenez-vous que vous pourrez aussi le faire à la prochaine démo ! Ce n’est pas annulé, c’est reporté. Les fails ça arrive, ça montre aussi à tous que vous et votre équipe êtes humains, on n’est pas parfaits, on fait de notre mieux.

Pourquoi ne pas enregistrer sa démo?

Le direct, c’est la vie ! Montrez le travail de votre équipe vous-même ou donnez-leur l’occasion de le faire. Tout ça augmente la confiance de votre équipe, la cohésion et permet à tout le monde de s’améliorer en cas de fail.  J’ai déjà participé à des démos enregistrées et c’est d’une morosité incroyable.

Les démos en direct ont bien plus d’âme et de dynamisme alors n’hésitez pas ! Durant vos démos régulières vous avez le droit à l’erreur, faites-les en direct. Si vous avez des démos extraordinaires, n’hésitez pas à préparer une démo enregistrée si ça vous rassure ! Elle pourra vous être utile si quelque chose se passe mal durant la démo en direct le jour J. ?

 

8. Récoltez des avis avant de partir au front ?

Avant les démos, prenez 30 minutes maximum pour montrer les points principaux à quelqu’un de votre équipe (ou d’une équipe externe) pour lui présenter rapidement les éléments clés, les notions complexes. Assurez-vous que vos schémas et images sont assez parlants et ajustez si besoin.

En savoir plus sur le contexte :

  • 1 démo à la fin de tous les sprints (3 semaines) pour présenter les nouveautés et avancements ;
  • présentation de 2 produits ;
  • 45 min de démo en anglais ;
  • j’assure maintenant 100 % de la démo. Celle-ci se faisant en anglais devant 50 personnes invitées, la démo était source de beaucoup de stress pour l’équipe. Plus à l’aise à l’oral et dans la langue de Shakespeare, j’ai pris la responsabilité de ce rituel.

 

9. Pas besoin de neuvième astuce

Bonne nouvelle! 8 astuces sont suffisantes alors relisez les et appliquez celle qui vous va le mieux!

 

Avec un peu de recul…

Pour conclure, cette démo s’inscrit dans un contexte transverse, impliquant plusieurs pays. L’enjeu principal reste la valeur apportée : chaque fonctionnalité doit démontrer son impact, adapté à des besoins en constante évolution. Dans le cas du search by GTIN, par exemple, une amélioration ciblée a multiplié sa valeur par 10. Toutefois, il manque une vraie phase de feedback en fin de démo pour mieux capitaliser sur les retours et continuer à progresser.

L’article 9 astuces pour que vos démos démontent est apparu en premier sur EKITE.

]]> 2112 Shape Up, 8 mois après, on fait le bilan avec le Boss https://ekite.info/2023/11/23/shape-up-8-mois-apres-on-fait-le-bilan-avec-le-boss/ Thu, 23 Nov 2023 09:16:45 +0000 https://ekite.info/?p=1500 Cet article est le troisième de la série Shape Up (3/3). Vous avez peut-être manqué les articles précédents Rencontre avec la Scrum Master et PO (1/3). Qu’en pense le tech lead (2/3). Rencontre 3?: le point avec le business leader Aujourd’hui nous avons la chance de passer un peu de temps avec une personne qui n’en […]

L’article Shape Up, 8 mois après, on fait le bilan avec le Boss est apparu en premier sur EKITE.

]]> Cet article est le troisième de la série Shape Up (3/3). 
Vous avez peut-être manqué les articles précédents Rencontre avec la Scrum Master et PO (1/3). Qu’en pense le tech lead (2/3).

Rencontre 3?: le point avec le business leader

Aujourd’hui nous avons la chance de passer un peu de temps avec une personne qui n’en a pas beaucoup?: Jean Pascal, 10?ans de maison chez Adeo, business leader et «?boss?» de l’équipe que nous suivons depuis plusieurs.
Il revient sur son passé d’agiliste, nous donne des infos exclusives sur la genèse de la transition vers Shape Up et dresse un bilan, de son point de vue, de la mise en place de cette méthode.

 

 

Contexte : Le rôle de Jean-Pascal sur le projet

 

Chez Adeo (maison-mère de Leroy Merlin) depuis 10?ans, Jean-Pascal est BPL (Business Product Leader)?: un rôle qui est souvent lié au DPL (Digital Product Leader).
Néanmoins, il assure quasi intégralement les 2 rôles grâce à un background technique combiné à une profonde connaissance de l’entreprise.

Étant moi-même prestataire chez Adeo, je peux décrire ces 2 rôles comme ceci :

  • BPL?: quels sont les besoins des utilisateurs et les fonctions métiers??
    Ex.?: un utilisateur veut pouvoir annuler un inventaire alors qu’il est déjà commencé. Est-ce que ça s’inscrit dans le process cible?? Creuser le sujet.

 

  • DPL?: est-ce que la fonction est techniquement réalisable et comment la réaliser??
    Ex.?: ajouter cette fonction dans l’application est faisable mais comment partager cette information aux autres applications?? Quelles données envoyer?? Est-ce que c’est faisable chez eux?? Est-ce que ça casse quelque chose??

Habituée à des cycles en V plus classiques, l’agilité est une méthode de gestion de projet que JP pratique depuis 4?ans, sa plus grande expérience étant le Scrum.
Au moment où Perrine lui en parle il n’a jamais entendu parler de Shape Up, la découverte est totale.

 

Shape Up?: une solution qui semble adaptée à une problématique

 

Ça ne peut plus durer?! L’organisation Scrum n’est plus adaptée à notre projet. Face à nos interconnexions et nombreuses dépendances, 2?semaines c’est trop court, il faut trouver une autre organisation.

C’est en réponse à cette problématique que Shape Up a été présentée par Perrine, la scrum master du projet. Cette organisation, qui présente des sprints plus longs (appelés cycles), semble répondre à la problématique.
C’est en accord avec toute l’équipe que cette méthodologie «?Shape Up?» a été mise en place?!

 

Le bilan du Shape Up, selon JP

 

? POSITIF

? PAS FOU FOU

Tout le monde, même les développeurs, parle le même langage?: le métier. 
Toute l’équipe est cohérente?!

L’année passe très vite. Avec des cycles de 2 mois il n’y a que 6?cycles dans l’année, tout retard ajoute plus de stress.

Possibilité de couvrir une fonction complète et pas une micro tâches. 

Certains membres de l’équipe qui ne sont pas liés au business (ex.?: devops) ne se sentent pas intégrés dans Shape Up. 

Donner plus de sens, une vision plus globale. 

N’a pas drastiquement amélioré la communication avec les autres équipes. 

Une gestion de la dette via un temps qui lui est destiné. 

 

Aucun problème pour  travailler en cycles de 8?semaines avec des équipes en sprints de 2?semaines. 

 

 

Retour d’expérience et conseil

 

Jean-Pascal est content d’être passé en Shape Up mais est-ce adapté à votre projet?? Voici ses retours.

Le Shape Up est adapté quand?:

  • il n’y a pas de deadline courte?;
  • on est en phase de build d’une application.

Il n’est pas adapté quand?:

  • on veut déployer des fonctions rapidement?;
  • on souhaite obtenir des retours rapides des utilisateurs?;
  • on est dans une phase de déploiement ou de run.

 

?Mon analyse

 

Changer pour changer n’est pas une solution.
Par contre, changer pour résoudre une problématique, ça c’est top?! C’est exactement ce à quoi la méthodologie Shape Up a servi et je trouve ça génial. Et courageux aussi?! Bouleverser toute une organisation aussi drastiquement n’est pas une mince affaire et l’équipe s’est adaptée avec brio.

Certes, tout n’est pas rose?:

  • certains aspects de la méthodologie Shape Up ne sont pas utilisés (la notion d’appétit par exemple)?;
  • certaines problématiques, notamment la synchronisation avec d’autres équipes, n’ont pas été résolues?;
  • même le retour au Scrum est sur la table?!

Mais ils y sont allés à fond?!
Ils ont vraiment testé, ils ont modifié tous leurs rituels, leurs tickets, leur organisation et en tant que PO je sais tout le travail que cela représente pour chaque membre de l’équipe.

Comme l’a si bien dit JP, Shape Up permettait de résoudre un problème dans un contexte ou livrer de la valeur rapidement n’avait pas de sens.
Le fait que le Scrum soit de retour sur la table et que l’équipe puisse, peut-être, repasser dans ce mode de fonctionnement n’est pas un échec. Tout comme Shape Up a été une solution, le Scrum l’est tout autant dans le contexte dans lequel avoir des cycles plus courts a vraiment du sens.

C’est pour moi un parfait exemple d’agilité et de maturité?: savoir s’adapter face aux changements.
Certains diront peut-être qu’ils ont perdu du temps à gérer tous ces changements.
Je dirais qu’ils ont investi du temps pour devenir bien plus résilients, matures et agiles.

L’article Shape Up, 8 mois après, on fait le bilan avec le Boss est apparu en premier sur EKITE.

]]> 1500 Shape Up, qu’en pense le tech lead après 8 mois ? https://ekite.info/2023/02/13/shape-up-quen-pense-le-tech-lead-apres-8-mois/ https://ekite.info/2023/02/13/shape-up-quen-pense-le-tech-lead-apres-8-mois/#respond Mon, 13 Feb 2023 13:06:11 +0000 https://ekite.info/?p=1447 Dans les précédents articles de la série Shape Up, nous avons pu parler de sa mise en place avec Perrine, la scrum master, et Sophie, la product owner, et avons pu assister à la première rétrospective en équipe. Aujourd’hui nous nous retrouvons pour l’interview de Logan, tech lead de l’équipe suivie, qui va pouvoir nous […]

L’article Shape Up, qu’en pense le tech lead après 8 mois ? est apparu en premier sur EKITE.

]]>

Dans les précédents articles de la série Shape Up, nous avons pu parler de sa mise en place avec Perrine, la scrum master, et Sophie, la product owner, et avons pu assister à la première rétrospective en équipe.

Aujourd’hui nous nous retrouvons pour l’interview de Logan, tech lead de l’équipe suivie, qui va pouvoir nous livrer son ressenti par rapport à Shape Up.

Logan est tech lead de l’équipe depuis 2 ans, il était là depuis plus d’un an avec l’équipe avant de suivre le passage à Shape Up il y a désormais 8 mois. Tech lead chevronné, Logan est dans la tech depuis plus de 15 ans ; sur ces 15 années, seules 3 ont été passées sur des projets en cycle en V. L’agilité il connait donc bien, il a pratiqué le Kanban, Scrum, l’agilité à l’échelle et maintenant Shape Up dans des projets impliquant entre 3 et 150 personnes sur des sprints durant de 2 à 4 semaines.

 

Comment Logan a-t-il connu Shape Up ?

Lors d’un slack day (jour consacré à de la veille ou la découverte de sujets en équipe), Perrine la scrum master, avait fait la présentation de Shape Up à l’équipe en lui fournissant la documentation et en laissant le temps à l’équipe de s’approprier les concepts.
Après des discussions sur des compréhensions qui pouvaient diverger au sein de l’équipe, l’envie d’essayer est apparue.
Le deal initial était d’essayer pendant 2 cycles (de 8 semaines) et de faire un point en rétro pour voir si l’équipe continuait ainsi ou revenait sur une organisation Scrum plus traditionnelle.

 

Quelles étaient les attentes et les réticences de Logan ?

Réticence :

  • Aller à contrecourant de bonnes pratiques tech de continuous delivery :

Dans la tech Logan cite le livre de Gene Kim « Accelerate » qui pousse à aller plus vers une mise en prod par jour en optimisant la CI. Ici on va un peu à contrecourant de toutes ces idées en se laissant le temps de faire des cycles longs.

Attentes :

  • Réduire le temps en réunion :

Avec l’organisation Scrum toute l’équipe avait l’impression de passer beaucoup trop de temps en réunion. Les tickets sont très précis, peut-être trop, et cela engendre beaucoup de discussions.

  • Pousser les développeurs à livrer de la valeur :

Les devs ont l’ impression d’avoir des entrants pas assez clairs. En Shape up un projet (équivalent d’une Epic) est découpé en scopes (équivalent des US) par l’équipe et non par le PO uniquement. Cela permettrait d’impliquer les développeurs dans le fonctionnel, les poussant à réfléchir à apporter de la valeur en tant qu’ingénieur développeur en s’éloignant d’un découpage purement technique (back/front/bdd etc.).

  • Améliorer la collaboration avec une autre équipe :

Les développeurs travaillent avec une autre équipe avec laquelle ils ont beaucoup d’adhérence. En les impliquant pendant la phase de Shaping, ils pensent pour travailler mieux ensemble.

  • Avoir une meilleure gestion de la dette :

Avec la période de cooldown de 2 semaines toutes les 8 semaines, Logan voit une occasion de gérer la dette. On met un peu ce que l’on veut dans le cooldown mais pour Logan, l’idée est de faire ce qui plait en allant dans le sens du projet quand même (dette/qualité/ci test coverage etc.)

 

Comment s’est passée la transition vers Shape Up ?

Finalement la transition s’est faite assez facilement, le backlog a été repris : les US existantes ont été transformées en scope et un cycle a été nécessaire pour réaliser ce reliquat.

Ensuite, chaque nouvelle fonctionnalité était un projet qui devait être « scopé » (découpé en scopes) par l’équipe et les rituels existant ont été repris (refinement/3 amigos /example mapping etc.) la différence est qu’ici les développeurs ont une vision d’ensemble.

Le workflow a été un petit peu adapté pour gérer les différents états et une definition of scoped a été ajoutée (aux existantes definition of ready et definition of done) pour s’aligner sur ce que l’on considère « scopé ».

Les estimations sont passées au niveau du projet concernant risque et délai.

 

La transition est-elle complète aujourd’hui ? Peut-on dire que l’équipe est en Shape Up ?

Shape Up oui mais avec des limites, une adaptation est donc en train de se mettre en place.

 

Shape Up a-t-il répondu à tes attentes ?

  • Réduire le temps en réunion : NON, le temps en réunion est toujours aussi important, une nouvelle organisation émerge pour condenser les réunions sur une semaine et laisser aux devs de longs créneaux productifs.
  • Pousser les développeurs à livrer de la valeur : OUI et NON, les développeurs ont tendance à rester sur leur scope back par exemple et à passer un cycle sans délivrer de la valeur.
  • Améliorer la collaboration avec une autre équipe : NON, la collaboration avec l’autre équipe n’est jamais arrivée, ils sont eux en Scrum.
  • Avoir une meilleure gestion de la dette : OUI et NON, sur 4 cycles de cooldown, 2 ont été utilisés pour terminer des tâches non accomplies pendant le cycle (build).

 

Un avis sur Shape Up ? Le recommanderais-tu ?

Après 2 cycles pas de conclusions tirées, il a été décidé de continuer.

Après 4 cycles : l’avis de Logan est que cela peut convenir, oui et non. Il faut l’adapter.

Logan se demande si la méthode est adaptée à l’IT dans le retail. La méthode est bien pour un éditeur (comme basecamp les créateurs de Shape Up) mais chez Adeo c’est plus compliqué.
La notion d’appétit pour savoir si on met de l’argent sur une fonctionnalité (trouver une solution pour un montant donné en envisageant un compromis) n’est pas complètement applicable.
Dans un contexte retail on fait trop peu de concessions sur les fonctionnalités. On ne se pose pas beaucoup la question du coût.

Pour conclure, l’avis de Logan est mitigé, il pourrait recommander Shape Up en fonction du contexte et de la maturité de l’équipe.
Comme il aime le dire, en tant que tech il commence toujours ses réponses par « Ça dépend ».
Il faut garder de l’agilité dans l’application de son framework agile, comprendre les concepts au cœur de l’outil et voir s’ils sont pertinents dans le contexte en question.

L’article Shape Up, qu’en pense le tech lead après 8 mois ? est apparu en premier sur EKITE.

]]> https://ekite.info/2023/02/13/shape-up-quen-pense-le-tech-lead-apres-8-mois/feed/ 0 1447 Shape Up: Vivez son adoption par une équipe Agile https://ekite.info/2022/06/08/shape-up-vivez-son-adoption-par-une-equipe-agile/ https://ekite.info/2022/06/08/shape-up-vivez-son-adoption-par-une-equipe-agile/#respond Wed, 08 Jun 2022 14:28:59 +0000 https://ekite.info/?p=979 Cet article est le premier de la série Shape up (1/3). Suivez l’histoire passionnante d’une équipe agile qui passe de Kanban à Shape up! Découvrez leurs succès, leurs craintes et les solutions qu’ils ont trouvés à travers une série d’articles et d’interviews menés tout au long de leur transformation!   Rencontre 1: Hello Scrum Master, […]

L’article Shape Up: Vivez son adoption par une équipe Agile est apparu en premier sur EKITE.

]]>

Cet article est le premier de la série Shape up (1/3).

Suivez l’histoire passionnante d’une équipe agile qui passe de Kanban à Shape up!

Découvrez leurs succès, leurs craintes et les solutions qu’ils ont trouvés à travers une série d’articles et d’interviews menés tout au long de leur transformation!

 

Rencontre 1: Hello Scrum Master, hello Product Owner !

Nous débutons notre série par la rencontre des stars du projet:

  • Perrine: Scrum Master qui mène la bonne adoption de la méthodologie Shape up.

  • Sophie: Product Owner qui vit le changement au jour le jour

Vous pouvez retrouver leur interview ici et un résumé écrit juste en dessous. Enjoy!

Au début de l’interview, il y a des références à des dessins qui illustrent le Shape up, ils sont ici

 

Selon vous, le Shape Up, qu’est-ce que c’est?

 

Shape Up est un cadre de travail agile créé en 2017 par Basecamp, une entreprise de logiciels Américaine. Il a été créé en réponse à l’insatisfaction de Basecamp face à leur utilisation de Scrum, qui est un cadre plus abstrait.

Shape Up se concentre sur la résolution de problèmes et s’assure de garder le problème initial en vue, contrairement à Scrum qui peut rapidement arriver à une solution. Shape Up offre également plus de temps pour résoudre un problème complètement alors que Scrum ne laisse du temps que pour le résoudre par petit bout. 

Cette méthode est articulée autour du:

  • Shaping : c’est un rituel pour travailler sur différents projets et problématiques dans le but de les expliquer clairement. Le Shaping apporte une ébauche de solution qui sera affinée lors de la prochaine étape: le Betting.

Note de Perrine et Sophie: Comme seule une ébauche de solution est décidée lors du shaping, parfois il apparaît plus complexe que prévu lors du Betting, il faut donc bien s’assurer que le sujet a été complètement traité même si la solution n’a pas été complètement trouvée.

  • Betting : rituel dans lequel tous les décideurs sont réunis. Nous parlons ici de PO, Digital Leader, Business Leader, UX, Tech Lead et Scrum Master. Le but est de sélectionner les sujets sur lesquels l’équipe va travailler durant la phase de build.

Note de Perrine et Sophie: Pour le moment l’équipe n’a pas encore pu transitionner tous les sujets Scrum vers Shape up. Pour compenser, ils ont mis en place une méthode temporaire CRRI (Confidence: Confiance dans la faisabilité – Risk: Est-ce que mettre en place cette fonction est risquée – Reach: impact sur les utilisateurs, les autres applications – Impact: Une fonction back peut être invisible pour les utilisateurs mais accélérer les dev de 50%)

  • Building : période de 6 semaines pendant laquelle l’équipe travaille sur la réalisation des différents sujets. La première semaine est marquée par une période de conception pour affiner l’ébauche de solution du Shaping. Durant cette période la Product Owner et la Scrum Master « shapent » les sujets du prochain cycle (et non pas sprint 😉 ).

  • Cooldown period: la dernière période du cycle du 2 semaines et permet de régler les bugs, optimiser l’architecture, se former, traiter la dette, etc… C’est durant cette période surtout orientée technique que le/la PO et le/la Srcum Master sont en « Betting » avec le reste de l’équipe.

Une autre notion à retenir: L’appétit

Adieu les story points!

Cet indicateur intervient durant la session de Betting, il est défini par le business et indique « Combien de temps le métier souhaite qu’un développeur passe sur un sujet. »

Note de Perrine et Sophie: Cette notion apporte un gros challenge car il est possible que le métier ne veuille pas passer beaucoup de temps sur le sujet mais que sa réalisation en nécessite bien plus par l’équipe de développement. Les négociations commencent alors et la criticité de la fonction peut être revue. Une solution à ça est de faire un maximum d’aller-retours entre le métier et l’équipe de développement pendant la période de Betting pour bien définir les sujets et leur complexité.

 

Pourquoi la mettre en place la méthodologie Shape up?

 

Pour 3 raisons :

  • Le fait d’avoir des « impact teams« : avoir une équipe dédiée tout le temps du projet sur une problématique pour la résoudre une fois pour toute.

  • Le fait que les développeurs puissent se concentrer sur une problématique complète, qui a du sens et qui peut être traitée de A à Z.

  • La cooldown période : il y avait une frustration dans l’équipe car les sujets techniques n’étaient presque pas priorisés par rapport au métier. Avec Shape up, la cool down période sert justement à ça: c’est une sorte de période hors du temps qui n’est pas pressée par l’urgence du build. Cette période fait du bien, elle permet de souffler, de se relâcher, de créer des choses qui facilitent la vie de l’équipe pour mieux reprendre.

 

Qu’en pensent les autres acteurs avec qui vous travaillez?

 

  • Le métier / les clients : ils ne connaissent pas l’organisation de l’équipe > Aucun impact.

  • Autres équipes de l’entreprise : ils ne connaissent pas l’organisation de l’équipe > Aucun impact.

  • Business Leader: n’a pas freiné ce changement. Il est intéressé par la résolution de problématique complète. Si urgence: dans tous les problématiques traités durant le cycle de 6 semaines, 1 peut “sauter” pour avoir le temps de gérer les cas non prévus.

 

Comment s’est passée la transition entre Scrum et Shapeup?

 

Elle aurait pu mieux se passer.

Nous nous sommes données 2 semaines de pour passer de Scrum à Shape Up mais ce n’était pas assez: en 2 semaines nous n’avons pas pu prévoir 6 semaines de travail; nous conseillons 4 semaines de transition au moins.

 

Les attentes de cette nouvelle méthodologie

 

Attentes QUALITATIVES

Attentes QUANTITATIVES

Mieux travailler avec les autres équipes et baisser les tentions

Avant nous avions 50 tickets minimum au début de chaque sprint.

?Augmenter la qualité de travail, donner du sens.

?Maintenant 5 tickets : 1 ticket par projet / problématique. Chaque ticket à ses sous tâches.

Faire des développements de meilleure qualité.

?

?Régler la dette technique grâce à la cooldown période

?

Investissement de l’équipe plus approfondi pour traiter tout un sujet au lieu de bribes.

?

Implication du métier qui participe au shaping: passer plus de temps avec lui pour mieux le comprendre.

?

 

 

 

 

 

 

 

 

 

 

 

 

 

 

? Mon analyse

 

Cette méthodologie est prometteuse!

Je trouve ça super qu’une équipe Agile puisse expérimenter et bouger ses habitudes chez son client.

Est-ce que je la mettrais en place? Pour une question de temps non (je suis à la fois PO et Scrum Master) mais j’ai hâte de savoir comment eux évoluent!

Il est encore trop tôt pour savoir s’ils garderont cette méthode à terme car avec d’autres avantages viennent d’autres inconvénients comme vous le verrez dans le prochain article qui parlera de leur première rétro!

Si vous avez des questions, posez les dans les commentaires et je ferais de mon mieux pour les relayer dans les prochaines interviews.

 

En savoir plus sur l’auteur & la démarche

? Bonjour à toutes et à tous! Petit nouveau chez EKITE, je suis Vianney, PO depuis 7 ans.

Malgré une expérience de création et direction d’entreprise, qui m’a permis de voir (beaucoup) d’autres choses au milieu de ces 7 années, il n’y a pas à dire, quand on est chez un client ou qu’on travaille sur un projet Agile, on est bien installé dans nos rituels, la tête dans le guidon, pour délivrer de la valeur A.S.A.P. comme diraient les Américains.

Depuis 2 ans que je suis chez mon client, après avoir lancé 5 projets, je peux vous dire que, même si elle s’adapte en permanence, notre méthode ScrumBan est basée des rituels solides. Cette routine nous apporte le cadre idéal pour nous concentrer sur les problèmes de nos clients.

Alors quand j’ai appris qu’une autre équipe allait exploser leur routine pour adopter une nouvelle méthodologie “Shape Up”, j’ai décidé de les suivre au travers de leurs rituels et une série d’interviews.

  • Comment sont-il passés d’une méthode Scrum à une méthode Shape Up ?

  • Pourquoi ?

  • Quelles ont été leurs difficultés et leurs réussites ?

  • Qu’en pensent la PO, la scrum master, les devs, les leaders ?

  • Est-ce que le Shape up a été inventé par Tibo in Shape (up) ?

Je vous partage mes réflexions et leur expérience pour que vous puissiez vous faire votre avis!

 

L’article Shape Up: Vivez son adoption par une équipe Agile est apparu en premier sur EKITE.

]]> https://ekite.info/2022/06/08/shape-up-vivez-son-adoption-par-une-equipe-agile/feed/ 0 979