Pourquoi et comment utiliser la méthode Shape Up ?

Поділитися
Вставка
  • Опубліковано 6 жов 2024
  • Shaping, Betting, Building... 🤯
    La méthode Shape Up, destinée à aider ceux qui peinent à délivrer de la valeur dans leurs produits, ne laisse pas indifférent, mais est-elle facile à dompter ? 👀
    Comment appréhender cette approche Agile ? Quelles différences avec les méthodes Scrum, Kanban...?
    🎙 Nicolas De Greef, Product Manager et Aurélia Amalvict, Data Product Manager chez Trustpair nous donnent leur retour d'expérience sur la méthode Shape Up ! 💥
    -----------------
    📽 Ne rate plus les webinars live Maestro ! Les prochains programmés sont dispo ici : cutt.ly/pPAEMaO
    🎶 Comme tu le sais, chez Maestro on propose des formations d'excellence au Produit 👉 www.joinmaestr...
    Une question ? flavie@joinmaestro.co
    👀 LinkedIn 👇
    Nicolas De Greef : / nicolas-de-greef
    Aurélia Amalvict : / aurelia-amalvict
    Rachida Laraache : / rachida-laraache
    Flavie : / flavie-chanut
    Join Maestro : / join-maestro

КОМЕНТАРІ • 1

  • @sculderoy
    @sculderoy 9 місяців тому

    En tant que Coach Agile et Scrum Master depuis plus de 10 ans, je suis désolé de te dire, Nicolas, que basé uniquement sur les informations que tu partages, vous ne faisiez pas du Scrum, mais du VScrum ou ScrumV. Voici quelques erreurs dans ce que j'ai entendu qui me laisse penser ça :
    - Scrum est un Framework, un cadre de travail, qui défini des règles. Contrairement à une méthode, il n'est pas prescriptif mais décrit des principes à appliquer mais sans expliquer comment faire.
    - 10:24 : Scrum ne dit pas de faire des Sprint de 2 semaines.
    - 10:33 : Respecter les dates de livraison sont simple en Scrum puisqu'une équipe Scrum doit créer un nouvel incrément utilisable (et potentiellement livrable) à la fin de chaque itération. Potentiellement plus souvent, car certaines équipes bien accompagnées livrent plusieurs fois par semaine.
    - 10:45 : Déborder sur la semaine prochaine prouve que le framework n'a pas été comprit par votre organisation. Un Sprint a une durée fixe. Comme une journée, ou un mois. Le 31 janvier 2023 se terminera à 23:59:59 plus 1 seconde peu importe ce que vous ferez ou direz. Si une équipe n'a pas terminé c'est qu'elle n'est pas autonome (sans doute, une fois de plus, du à un mauvais accompagnement). Et aussi parce que l'équipe est focalisée sur la réalisation de ses Product Backlog items plus que sur l'atteinte du Sprint Goal. Et si les deux sont intimement lié à chaque Sprint, alors une fois de plus l'organisation n'a pas comprit Scrum. De plus, lorsqu'un Sprint se termine, les items non terminés retournent dans le backlog au même titre que les autres. Et peu importe si un effort a déjà été fourni, potentiellement il n'est plus pertinent. Dans l'usage on applique une règle de 30 / 50 / 20. 30% d'items sont indispensables, 50% sont important, 20% sont accessoires.
    - 11:00 : Si il y a beaucoup de question en cours de Sprint, c'est parce qu'il n'y a pas eu suffisamment de discussions (Product Backlog refinement) avant son démarrage. Le PO n'a pas pour vocation à tout spécifier, mais à engager des discussions avec toute l'équipe et les parties-prenantes pour orienter le produit.
    - 11:26 : Ne pas savoir POURQUOI on travail sur une feature est un problème de compétence du PO qui n'a sans doute pas suffisamment communiqué le Product Goal, et qui n'a pas défini avec l'équipe un Sprint Goal.
    - 11:40 : Si le développeur a l'impression d'avoir un rôle d'exécutant, c'est encore une fois car vous ne faisiez pas de Scrum mais du ScrumV ou Cycle en V en cycle court (ce coach explique rapidement la différence : ua-cam.com/video/l6MNfyi4feo/v-deo.html)
    - 12:17 : L'adoption d'une feature n'a absolument rien à voir avec le cadre, mais avec les compétences produits (tracking, analyse et connaissance de son marché, et capacité d'adaptation).
    Je m'arrête là car il y a déjà pas mal de matière, mais en tout cas, AUCUN de ces points ne peut changer avec une simple réorganisation d'un cadre. Tout est dans l'état d'esprit Agile de l'équipe Relisez au moins les 4 piliers du manifeste agile et le Scrum Guide, et vous verrez que vous étiez à côté de la plaque de votre implémentation du framework.
    Allez, je continue la vidéo en passant ce passage qui est un peu horripilant pour un vrai agiliste :')