Être plus réactif avec Kanban - Introduction à Kanban - Scrum Life 72

[@ScrumLife]

Découvrez toute la communauté Scrum Life ! 👉 sl.run/42jgHk

[@AmorAguilera]

Merci pour cette introduction si claire ! Avoir la vision versus Scrum est très intéressant pour bien se faire une idée. 👍

[@ScrumLife]

Après Kanban et Scrum ne sont pas incompatibles et peuvent co-exister bien sûr ! Robin

[@colaps]

Bonjour Jean-Pierre, Merci pour cette vidéo. Kanban et Scrum sont deux "choses" différentes que l'on ne peut, à mon sens, pas comparer et qui peuvent être complémentaires ! L'un, comme tu l'expliques très bien, est un outil, une technique, qui permet 1) d'optimiser les flux en fonctionnant en flux tiré 2) d'obtenir des KPI (pertinents à l'intant T) et 3) qui mets en avant les problèmes de synchro MAIS qui ne met rien en place, au contraire de Scrum, pour améliorer le produit, le fonctionnement interne de l'équipe et la résolution de problèmes autre que le flux de production. L'objet de ce commentaire n'est pas de prendre partie pour Scrum ou Kanban. C'est juste, pour dire que selon moi, "SCRUM vs KANBAN" n'existe pas. Kanban est un super outil hyper visuel, Scrum est un super cadre pour l'amélioration continue. Chacun avec leurs + et leurs -. Peut-être que je me trompe quelque part ? En revanche (et là, c'est le deuxième objet du commentaire :) ) , n'ayant jamais pratiqué Scrumban, je serais super intéressé d'avoir ta vision sur cet outil/méthode/cadre (????). Comment ça marche ? Est-ce que c'est la fusion du meilleur des 2 mondes ? du bricolage ? est-ce que c'est pertinent ? Pour toutes les équipes ? ... Peut-être que c'est déjà dans le backlog de ScrumLife ? Merci encore Jean-Pierre :) @+ FranckC

[@ScrumLife]

Salut Franck ! Je n'ai pas abordé Scrumban par manque de place dans la vidéo, mais il n'y a pas grand-chose à dire dessus... En quelques mots c'est Kanban + les rôles, évènements et artefacts de Scrum, avec une certaine liberté. - Plus d'estimation qu'on remplace par des indicateurs Kanban - Fréquence des évènements plus flexibles qu'en Scrum, on pourrait par exemple faire un "planning" (généralement traduit en "remplissage de la colonne de gauche") toutes les semaines, et une Rétro toutes les 4 semaines - Plus d'itération, le travail est en continu En résumé c'est un mélange des deux mais pas l'addition des deux. Scrumban est donc plus strict que Kanban mais plus flexible que Scrum. J'ai du mal à considérer du Scrum ave des limites de WIP comme Scrumban. Pour moi il faut casser plus le framework pour passer à Scrumban que juste utiliser cet outil pour fluidifier le flux en cours d'itération.

[@timothyalcaide]

Merci JP j'ai bien retenu 9:59 😂 (Bon travail comme toujours)

[@aymericrichard6931]

Ah bien, je vais passer aux potes :)

[@jdassonval]

Top comme vue globale

[@oniyonkuru]

Très belle vidéo comme d'habitude. Je passe une certif PSK le 21/06 (Professional Scrum with Kanban) car j'ai adoré travailler avec du Kanban ainsi que l'ensemble des métriques qui vont avec (cycle time, takt time, lead time, throughput...)

[@Jacq4y]

C'est compliqué de parler français dans ce contexte apparemment

[@ScrumLife]

😅

[@tinico17]

Super vidéo, bravo ! Etant fervent promoteur de Kanban, je ne peux qu'acquiescer 😊 Il y aurait en effet énormément de choses à dire sur Kanban, et ton introduction en 10’ est très bien faite. J’ai deux petites remarques pour préciser certains points que tu abordes. Tu présentes les limites de WIP comme un outil pour gérer les stocks, mais ce n’est pas vraiment leur finalité (même si on est d'accord sur le coût qu'ils engendrent). Le kanban, c’est un flux tiré comme tu l’as très bien dit, et la limite de WIP est surtout là pour challenger ce flux tiré de manière mécanique. Quand l’étape N a fini, elle ne peut pas « pousser » son travail tant que l’étape N+1 n’a pas la capa de le prendre (i.e. a atteint sa limite de WIP). C’est qu’à partir du moment où l’étape N+1 a de la capa qu’elle peut ainsi « tirer » le travail prêt de l’étape précédente. Et ainsi de suite sur toutes les étapes. Ce qui m’amène à la deuxième précision primordiale : le travail est finalement « tiré » non pas par l’équipe, mais par le client (qui est l’étape finale). Voilà, c’était juste deux petites remarques sur le périmètre que tu abordes. Encore bravo pour cette vidéo en 10 minutes, c’était un vrai challenge 😊

[@ScrumLife]

Un grand merci pour ces précisions !

[@ghoulemfareskhireddine756]

Buc

[@cyrilvacavant9775]

Cool cette introduction à Kanban. Ce serait sympa de faire la même chose pour Scrumban maintenant.

[@ScrumLife]

Y a-t-il vraiment tant de choses à dire sur Scrumban ?

[@cyrilvacavant9775]

Scrum Life ben, je ne connais pas très bien, donc du coup j’aimerais un peu en savoir plus 😉

[@ScrumLife]

Je reprends ma réponse à +colaps: Je n'ai pas abordé Scrumban par manque de place dans la vidéo, mais il n'y a pas grand-chose à dire dessus... En quelques mots c'est Kanban + les rôles, évènements et artefacts de Scrum, avec une certaine liberté. - Plus d'estimation qu'on remplace par des indicateurs Kanban - Fréquence des évènements plus flexibles qu'en Scrum, on pourrait par exemple faire un "planning" (généralement traduit en "remplissage de la colonne de gauche") toutes les semaines, et une Rétro toutes les 4 semaines - Plus d'itération, le travail est en continu En résumé c'est un mélange des deux mais pas l'addition des deux. Scrumban est donc plus strict que Kanban mais plus flexible que Scrum. J'ai du mal à considérer du Scrum ave des limites de WIP comme Scrumban. Pour moi il faut casser plus le framework pour passer à Scrumban que juste utiliser cet outil pour fluidifier le flux en cours d'itération.

[@cyrilvacavant9775]

Scrum Life ok merci pour les précisions.

[@JeanBenjaminDamas]

... Parfois, ne rien faire, c'est plus constructif que continuer de travailler et d'en rajouter" ...

[@mrb1484]

@ScrumLife merci pour la vidéo. Un livre à conseiller pour creuser un peu plus le sujet Kanban ? Thanks !

[@ScrumLife]

Bonjour 👋 le livre de Laurent Morisseau « Kanban pour l’it » est plutôt très bon. - Robin

[@tianadede349]

cool

[@ScrumLife]

Merci ! Qu'est-ce que tu as apprécié en particulier dans cette vidéo ? -- JP

[@tianadede349]

@@ScrumLife tu fais le drôle tout en enseignant , kkk

[@ScrumLife]

💪💪💪

[@Antoine-gx4yl]

et bah merci!

[@huguespeccatte1532]

À la fin de la vidéo, ton développeur qui ne veut pas créer de bouchons décide de repasser sur son PoC. Je ne sais pas si c'est une erreur, mais j'aurais tendance à mettre PoC et spike (que tu présentes dans la vidéo 64) dans le même panier. Et du coup, je me demande comment matérialiser ces PoC / spike. Faut-il les faire apparaître dans le (sprint) backlog ? 1/ Non => j'ai tendance à penser que ça risque de passer à la trappe par rapport à ce qui est explicité (on ne peut pas toujours se rappeler qu'on a défini oralement de travailler sur un sujet durant le sprint) ; 2/ Oui => dans ce cas-là, ça risque de contribuer à créer des bouchons également. Constantin et toi, avez-vous des conseils sur ce point s'il vous plaît ? Merci !

[@ScrumLife]

Je précise que dans l'idée de cette mise en scène, ce POC tient plus de la veille technique. De ce point de vue, ce n'est pas délirant de ne pas le matérialiser.

[@BatPierrot]

Je veux pas faire ma bêcheuse mais, dans les deux cas du "push" ou "pull", tu déplaces tes post-it de la gauche à la droite du board... Et au final, quelque soit la méthode, tu fais une tâche et tu en commence une autre. Même si tu as terminé les tâches déterminées du sprint, tu vas en scoper une nouvelle pour pas glander justement. Au final, à quoi sert vraiment la méthode agile, si ce n'est donner une forme plaisante au concept simple de "faire une tâche puis une autre" ?

[@maximemassicard-tarmak-6034]

"C'est fait quand c'est fait". si je comprends le philosophie, je me pose malgré tout la question de 1/ Comment garantir que les objectifs qui amènent aux actions du board sont bien atteints, une fois en Done ? (et dans le temps où il sont escomptés) et 2/ de quelle manière évaluer et animer le rythme d'un dev (ou autre rôle) ? De quels outils dispose son manager. Merci!

[@ScrumLife]

Bonjour Maxime et merci pour ton commentaire. Puis-je te répondre en te posant d'autres questions ? ➡️ Comment fais-tu aujourd'hui, sans Kanban ? ➡️ Qu'est-ce qui te fait penser que ces approches ou solutions ne fonctionneraient pas en Kanban ?

[@maximemassicard-tarmak-6034]

@@ScrumLife (wahou, réactif !!! :). Non, je ne conteste pas en fait. Je me pose vraiment la question. Kanban étant une méthodo pour fluidifier le cycle de production, quelle(s?) façon de "manager" lui est bien complémentaire ? A ce jour, plutôt sur du Scrum, avec un nombre de point réalisable par sprint.

[@ScrumLife]

D'accord et merci. Je crois lire que l'habitude, avec Scrum, est donc de demander aux développeurs de sortir un certain nombre de points dans le Sprint -- sous-entendu, s'ils en font moins, c'est qu'ils ne "performent" pas. Je vois beaucoup de problèmes dans cette approche -- y compris en Scrum. (Précisons d'ailleurs qu'il est possible de faire du Scrum sans estimations ni vélocité, le problème n'est donc vraiment pas lié à Kanban ou Scrum) Tout d'abord, de manière très terre à terre, vu que les "points" sont fixés par les développeurs eux-mêmes (ce sont bien eux qui estiment leur propre travail ?) alors ces mesures et indicateurs sont faciles à fausser. Ensuite, plus important encore, un tel focus sur la productivité (plutôt que sur la qualité, ou sur l'impact réel pour l'entreprise ou les utilisateurs) peut être extrêmement destructeur pour les personnes, pour l'équipe et pour le produit. Notons que quel que soit le framework choisi, en agile on fait le travail bien et la qualité doit être présente. Alors comment faire, managérialement parlant ? Un bon point de départ est de bien voir que tout ce qui mesure de performance individuelle (plutôt que collective) pose énormément de problèmes. Au mieux, on peut se reposer sur l'avis de ses pairs -- à condition que la dynamique soit bonne évidemment. Il faudrait faire une liste de précédents Scrum Life... Divers sujets compléteraient ce commentaire.

[@maximemassicard-tarmak-6034]

@@ScrumLife Je n'anime pas sur le nombre de points. C'est bien un indicateur de vélocité. Et tu as raison, principalement utile aux devs pour estimer la charge du sprint, et biaisable. C'est un comment, pas un but. La mesure de la performance collective me semble en effet un élément de réponse clef. Mais un individu peut aussi se noyer dans le collectif sans être capable de réellement mesurer son apport. C'était là une partie de ma question. Je prends le point sur le feedback collectif, mais j'en déduis que tu ne cherche pas à aller plus loin sur la mesure (sans être fordiste) de la performance individuelle sur les différents rôles ? L'autre aspect de ma question était l'animation du délai, ou comment, sans faire du push, mesurer la valeur temps dans le projet. Exemple concret: une feature qui a pour conséquence attendue de booster les performances commerciales d'une opération prenant place au Black Friday. Si tu ne la sors pas à temps, tu réalises bien la feature, mais tu rates ton en partie ton objectif commercial. Comment "stresser la roadmap" et trouver les bons leviers d'augmentation de la cadence, tout en gardant la philosophie kanban de non encombrement ? Merci en tout cas de prendre le temps de répondre, et bravo au passage pour la chaine et les vidéos, j'ai pas encore tout vu mais la réalisation est très intéressante et pédagogue!

[@mickaelarazor5260]

@@maximemassicard-tarmak-6034 L'équipe de développement a une capacité à produire (vélocité). On peut l'aider à se mesurer et à s'améliorer via certains frameworks comme Accelerate. Par contre, "Stresser" le backlog et les équipes risque d'avoir un effet contraire à ce vous souhaitez obtenir. La pression des délais pousse les équipes à rogner sur la qualité, ce qu'on paie toujours à l'arrivée... Si l'équipe doit travailler en priorité sur l'opération commerciale (parce que c'est ce qui a le plus de valeur pour l'entreprise), alors le meilleur moyen de l'aider est de prioriser ce sujet, et de déprioriser les autres tâches du backlog. Pour une équipe mature qui est efficace dans le découpage en tâche, on peut quand même avoir une idée des délais en prenant en compte le temps moyen de réalisation d'un ticket, que l'on multiplie par le nombre de tickets à traiter. Mais une fois de plus, personne n'est capable de tout estimer exactement, donc le jalon obtenu ne reste qu'une estimation qu'il faudra réévaluer régulièrement. Si le jalon prévisionnel glisse, il faut soit revoir le périmètre qui sera livré à date, soit donner plus de ressources à l'équipe (attention, 9 femmes ne font pas 1 bébé en un mois), soit simplement revoir la prévision et se poser les bonnes questions. L'équipe est elle focus sur ses tâches ou parasité par du run ou de la dette technique accumulée? Est ce qu'il faut investir dans de la formation ou un renfort plus expérimenté? Est ce que le dimensionnement de l'équipe est cohérent ? Est-ce qu'il y a beaucoup de retours sur les livraisons, et si oui, quels process peut on mettre en place pour améliorer la qualité globale des livrables?

[@jacobboa464]

Mais en même temps c'est la DT qui choisit ce qu'elle prend dans le sprint backlog. Le product backlog est chargé par le PO.

[@eudesml5637]

LA COURONNE POUR LE BOSS HOMME?

[@ScrumLife]

C'est censé être l'accessoire représentant un développeur, mais ce n'est pas très explicite 🤣

[@lutaseb]

après 71 scrum life, nous avons enfin la conclusion de ce qu est scrum: charger la mule.... on dirait une fin à la Game of Thrones ... V_V;

[@ScrumLife]

😆

[@farttahi1014]

En même temps, quand à la fin d'un sprint, t'as des points non fini, t'as toujours le scrum master (akka le gars qui passe ces journées sur JIRA à regarder les stats, spécialité brasseur d'air) venir dire "ahh mais on a un engagement donc il faut finir"

[@lutaseb]

@@farttahi1014 tu t engages a faire le maximum possible, mais meme en t'engageant à faire le maximum... ça reste toujours qu une garantie à faire le maximum... pas un résultat

[@farttahi1014]

@@lutaseb généralement, le brasseur d'air n'aime pas, car il faut tenir ses engagements.

[@lutaseb]

@@farttahi1014 j'imagine...

[@eudesml5637]

LE BONNET C'EST POUR FAIRE LA FILLE? LOL

[@ScrumLife]

L'accessoire "bonnet" représente, selon la situation, le patron ou le manager.

[@eudesml5637]

@@ScrumLife je plaisantais...mais intéressant !