🤬🗯️ "Scrum y'a trop de réunions" "Le Sprint Planning c'est CHIANT !!!"
Вставка
- Опубліковано 5 лис 2023
- 🎁 Le guide du Scrum Master compétent 👉 sl.run/2CsJJc
Comment faire en sorte que le Sprint Planning de Scrum soit un véritable atelier, qui donne du sens, qui génère de l'énergie et booste l'équipe ?
Voici nos conseils dans cette vidéo réaction d'un des premiers Scrum Life ! #ScrumLife #VIdéoRéaction #SprintPlanning
💜️ Rejoins la communauté Scrum Life 👉 sl.run/JdCnHv (c'est gratuit !)
----------
LIENS EN RAPPORT AVEC CETTE VIDÉO
La vidéo que nous avons regardé et commenté : "L'équipe n'arrive pas à s'engager en Planification d'Itération" • L'équipe n'arrive pas ...
À quoi ressemblent tes Sprint Planning ? Ca se passe comment ? C'est la joie ou c'est CHIANT ? Dis-nous en commentaire 👇👇👇👇🙏
Les jump cuts de l’épisode 7 sont…hallucinants!😅
Est-ce que j’entends un léger décalage ou une complémentarité entre
“L'Objectif de Sprint est créé pendant l'événement de Sprint Planning…” (Scrum Guide)
et 13:48 ?
À noter que je suis très à l’aise avec les propos de Constantin. Cela dit, il n’est p-e pas nécessaire de convaincre l’équipe de l’objectif ("travailler sur ça") si elle participe à sa création lors du Planning.
Imaginez cette formule de Sprint Planning..Mode TDDx
1- Co-création du Sprint Goal
2- Identification / Création des éléments (US) qui aident dans l’atteinte du Goal
3- Création de binômes Dev + [PO, Analyste, QA, …]
4- Création de tests (unitaires) dans un langage omniprésent (ubiquitous language ) qui “Fail”
5- Plénière pour conclure le Planning
---
Le Sprint sert au Pass + Refactor. (Et sûrement plus des tests)
Scrum Life était jeune ! Le montage s'est apaisé par la suite 😅
Autrement, ta proposition me semble assez fidèle à ce à quoi devrait ressembler un Sprint ! Enfin, plus précisément, la première itération du Sprint. D'autres itérations venant potentiellement ensuite dans le cadre du Sprint, tirant déjà parti de ce que la première itération aura permis de découvrir et d'apprendre.
Qu'en dis-tu ?
-- JP
Merci beaucoup encore pour cette vidéo, ça donne des éléments pour renforcer mon approche avec mes équipes. C’est difficile parfois dans une entreprise ultra orientée technique d’amener cette vision produit, les besoins au travers de persona « internes » à l’entreprise
Merci de ton partage ! Qu'est-ce que tu identifies qui rend difficile d'amener cette vision produit ?
-- JP
@@ScrumLife il y a plusieurs critères : le manque de ressources, le manque d’agiliste et une vision top down product centric 😅
Je pense que cette vidéo est surtout à revoir en parallèle de celle dernièrement sortie sur le contexte de travail...
Après, la prise en maturité agile d'une équipe sur ce point est souvent fondamentale, mais elle permet surtout de voir, quand on l'a mise en place, où en est le coaching du PO (capacité à porter une vision produit, capacité pour l'équipe de s'approprier un backlog et à le faire vivre dans le cadre des reviews et raffinements, réflexion d'ensemble sur le flux de valeur...)
Après, le coup de l'objectif de sprint SMART sensé driver l'engagement, c'est cool, mais parfois avant ça y a un travail considérable à porter...
13:57 Ca m'amuse ce point parce que souvent en retour, j'explique aux équipes, qu'ils doivent convaincre le PO que tel ou tel truc est important à faire, mais que c'est le PO qui "organise" le backlog produit. C'est lui qui a le dernier mot et qu'on doit respecter son choix même si on n'est pas d'accord.
En réaction à des membres d'équipe qui parfois contournent les décisions du PO parce qu'ils ne sont pas d'accord.
Ca me semble pertinent que chacun doit convaincre les autres. Les dev doivent convaincre le/la PO que leur plan est bon, la/le PO doit convaincre les dev que l'objectif est important.
Perso, ça me semble être une bonne relation. Et plus on avance, moins ce besoin de conviction se fait sentir car on a confiance en l'autre, on se dit de base "il/elle doit avoir pris la meilleure décision possible".
-- Constantin
@@ScrumLife pour convaincre il faut discuter, la boucle est bouclée
Je dirais aussi que ce n'est pas qu'une question de confiance. En travaillant ensemble on développe le "profil en T" de chacun, que cela soit le "vernis technique" du PO ou la compréhension produit des developers. On réduit donc la distance à parcourir pour se convaincre mutuellement.
-- JP
Concernant le découpage des US en tâches techniques, Sprint planning 1, 2, etc.. Je n'arrive jamais à motiver l'équipe à le faire. Les différentes réactions que j'ai quand je le propose c'est : "non, ça ne vaut pas le coup", "c'est trop simple comme US", "je vois déjà ce qu'il faut faire, pas besoin de faire un découpage", et "c'est à dire quoi.. pour chaque US on mettre 2 sous tâches, back et front?"
Comment t'as fait pour changer de voix comme ca? des cours de théâtre ?
Salut ! En fait la voix que j'avais dans la vidéo d'origine était vraiment dû au fait que j'enregistrais le soir, la nuit, dans mon salon avec la famille qui dort dans la maison.
Si on regarde le tout premier Scrum Life sur le burn-down chart, j'avais déjà cette "voix de théâtre" où je parle fort, à pleine voix : ua-cam.com/video/kicIINwuPuI/v-deo.htmlfeature=shared
Par contre, il est certain que depuis j'ai pratiqué, je me suis simplement habitué et c'est devenu d'autant plus naturel pour moi de prendre à volonté cette voix, et j'ai aussi affiné ma diction et ma posture. C'est l'habitude, la pratique. Pas de cours de théâtre, non !
Assez récemment j'ai eu l'opportunité d'avoir quelques cours de coaching sur ces sujets-là lors de ma collaboration avec Open Classrooms, j'ai trouvé ça très utile et pertinent, même en tant qu'orateur déjà confirmé. Je recommande 👍
-- JP
Si on reprend les 4 premiers éléments clés, ça ressemble fort à une approche OKR (ou alors les OKR obligent à faire du vrai Scrum ^^)
- Sprint Goal : tout commence par là
- Ne pas choisir les éléments depuis le backlog produit mais se demander ce qu’il faut faire pour atteindre le Sprint Goal
- Ne pas essayer d’ajuster la charge du sprint en se basant sur le nombre de “stories” que l’on envisage de prendre mais sur le Sprint Goal lui-même pour garder une cohérence
- Se projeter sur un calendrier reste un excellent outil pour accompagner l’équipe dans son auto-gestion et dans sa pluridisciplinarité !
Ce qui n'existait pas à l'époque c'est la couche "Product Goal", qui rapproche encore plus de l'OKR qui est souvent "à plus long terme".
Je ne suis pas sûr que les OKR obligent à faire Scrum, ou alors, les "OKR bien faits" ?
-- Constantin
@@ScrumLife Je me suis mal exprimé :) Les OKR n'obligent pas à faire du Scrum, mais du Scrum bien fait peut ressembler aux OKR dans l'approche.
Qu'est-ce qui saute quasi systématiquement dans Scrum ?
Le product goal et le sprint goal.
Les OKR obligent à réfléchir à cela et s'affranchissent de backlog limitant en posant la question : "Que faut-il que nous fassions pour atteindre notre objectif ?"
Quand je dis "Les OKR obligent à faire du vrai Scrum", j'entends "penser à l'approche OKR oblige à ne pas oublier ces committments que sont le product goal et le sprint goal".
Avec Scrum on a tendance à raisonner en termes d'events et d'artifacts et pas assez en termes de commitments.
Et ce sont les commitments qui apporteront la motivation et le sens d'un sprint planning ;)
9:26 un danger du descopage c'est de réduire la qualité... Et de faire avec. De ne pas revenir dessus.
Il faut une vigilance et de la discipline sur l'après
11:06 ah ben voilà
9:18 : "C'est un apprentissage en soi qu'on y arrive pas" 👍
Est-ce qu'on doit à tout prix éviter "l'échec" du sprint goal ? 🤔
N'y a t il pas des échecs qui sont de meilleurs réussites que certaines réussites moins ambitieuses et qui permetteraient de se poser d'autres questions en rétrospective ?
Oui !!!
Reste bien entendu le sujet d'avoir fait son maximum pour atteindre le Sprint Goal (dans la limite du rythme soutenable). Mais c'est à mon sens un faux sujet, les équipes de feignants qui se la coule douce, ça n'existe pas, ou alors ce sont des gens démotivés (ou plus précisément, dans un environnement démotivant) => le sujet est donc ailleurs, en dehors du Sprint et de Scrum.
De ton côté, comment amènes-tu les choses vis-à-vis du Sprint Goal et de son atteinte, dans tes équipes ?
-- JP
@@ScrumLife Ce que je fais de mon côté c'est que je commence déjà à en parler en fin de Sprint Review avec les parties prenantes et le product owner.
On jete un œil sur le plan de livraison pour voir si des choses importantes doivent être décidées sans rentrer dans les détails.
Est-ce qu'on continue de tracer la route ou est-ce qu'il faut prendre un cap différent ?
Si on doit changer, quel est ce cap et quel est le 1er pas ?
Qu'est-ce qu'on aimerait voir se passer dans 15 jours ?
En Sprint planning ensuite, on repart de la conclusion de la Sprint review et on regarde si cette vision est suffisamment ambitieuse mais pas trop et on commence à sélectionner le travail à faire.
Particularité (peut-être à ne pas faire) que j'autorise si les raisons sont justifiées :
Si l'équipe estime que l'objectif est important et motivant et qu'il faut + de 2 semaines pour l'atteindre alors on se donne le droit de passer d'un Sprint de 2 semaines à un Sprint de 3 semaines.
On ne fige rien à l'avance.
Ça reste très exceptionnel.
Diviser l'objectif en 2 étapes est souvent possible mais moins motivant.
Ensuite on part en général du plan de livraison (Product Backlog ordonné) en gardant également un œil sur 2 choses.
Ce que nous devons intégrer au Sprint suite à la dernière Sprint rétrospective et s'il y a des éléments qui ne figurent pas dans le Product Backlog et qui pourraient aider à atteindre le Sprint Goal.
Pour terminer, le Daily Scrum est là pour ça : vérifier qu'on est bien sur les rails pour atteindre l'objectif.
Transparence et humilité.
Si le Sprint Goal n'est pas atteignable, on le sait déjà au moins 3 jours avant et on prend le temps en dehors du Daily Scrum de discuter de ce qu'il faut faire.
Parfois on peut atteindre l'objectif en réduisant certaines choses à faire.
Parfois ce n'est pas possible ...
Et je pense qu'il faut savoir dire : nous avons échoué.
Là j'avoue qu'on peut être un peu en roue libre.
Si on a observé un caillou qui nous a fait dévier, tout de suite on va prendre les actions pour s'en débarrasser au lieu de simplement piocher dans le Sprint Backlog en fin de Sprint.
Difficile de faire court désolé 🙄