Salut JP Merci pour tes vidéos. Je viens de découvrir la durée d'intégration à 1 semaine. Et j'étais pas convaincu. Je le suis maintenant. Flexibilité, adaptabilité. Bref, c'est génial.
Bonjour Jean-Pierre, Bravo pour le cap des 500 ! :) Après une première vision de cet épisode, j'ai le cerveau en ébullition ! J'avoue ne jamais avoir pensé à la durée des Sprints sous ces angles ... Je suis plutôt dans le "SHU" sur cet aspect là => merci de m'avoir secoué les neurones :) @+ Franck
Pour notre part, nous avons une équipe de développement composée de 4 personnes. Après quelques tests avec une période d'itération plus longue (et alors que nous avions aussi une équipe plus volumineuse), nous avons décidé de partir sur des itérations d'une semaine. Cela peut sembler court et cela nécessite effectivement d'avoir automatisé un certain nombre de choses, mais nous avons effectivement comme force de pouvoir prendre en charge "rapidement" une demande en l'intégrant au sprint suivant qui n'est pas si loin que ça. Du coup, notre ligne "Urgent task" est généralement vide et est surtout réservée à des bugs ou des pré-requis non-identifiés en amont qui surviendraient au cours du sprint. Si cette durée peut sembler assez courte, elle semble stimuler l'équipe. Attention tout de même à un effet de bord : il faut que l'équipe puisse tenir le rythme dans le temps.
Par le passé, j'ai souvent été perçu comme un hurluberlu (même parmi les SM) d'ouvrir la question de la durée sacro-sainte d'un Sprint (2 semaines) dans une organisation Agile/Scrum. Plusieurs équipes étaient willing et ressentaient la même chose que moi. Au départ, cela a été un simple "non". La raison était simple : garder toutes les équipes sur la même durée d'itération, conserver l'habitude (peur du changement), s'aligner sur la Roadmap officielle. Mais les contraintes étaient toujours bien présentes : des "urgences" qui entraient trop facilement dans un Sprint, des fréquences de Releases trop proches empêchant d'offrir une vraie belle expérience à nos clients et qui généraient alors des "ajustements" car l'idéation n'avait pas le temps de réflexion et préparation nécessaire. Souvent : un sentiment d'inachevé ou de non-complétion réelle par tous les membres. Ou plus métaphoriquement : un cochon d'inde en train de spinner dans sa roue, sans vision, sans but concret. L'Organisation ayant vécu de nombreuses déceptions récurrentes, il a fallu un long accompagnement général pour accepter de tenter l'expérience, surtout en expliquant la réalité différentes des équipes DEV (périmètre d'action, besoin externe vs capacité d'autonomie, etc.). Certains avec des cycles de 3 semaines, d'autres de 1 semaines. Au final, toute cette réflexion a permis à l'organisation de revoir son approche et modèle de délivrables. Soulagés des PO mais aussi des Responsables, parfois à travers les fameuses Roadmaps, mais aussi en comprenant mieux leurs propres capacités opérationnelles. Dans certains cas, cela a aussi permet de modifier des dynamiques d'équipe en interchangeant certains membres. Certains plus à l'aise dans un mode d'itération courte et d'autres plus efficaces et heureux avec du 2 ou 3 semaines. Et je considère cette organisation comme réellement souple, flexible et ouverte aux idées. Ceci dit, je suis conscient qu'il restera toujours une forme d'inertie dans une organisation.
Salut Jean-Pierre, je te félicite pour le travail que tu réalises à travers cette chaîne, il faut être passionné, généreux et quelqu'un de bien pour offrir tout ça comme ça. Bravo. +J'ai une petite question : à la minute 2:10 tu dis quelque chose du genre : "il faut qu'on prenne le temps de faire une phase de QS c'est obligé". QS ? Je ne sais pas si j'ai bien entendu ? S'il s'agit bien de QS, pourrais-tu expliquer ce qu'est-ce ? Merci
Il fallait comprendre "une phase de QA" (avec l'accent anglais bidon d'un français) -- Quality Assurance, une phase de test pour valider que tout marche bien en somme.
Hello JP, tu ne parle pas de « mou » ? Comment traiter le running en plus du dev dans une équipe scrum ? Nous devons gérer des incidents, nous avons un process dans le sprint pour prévoir le coût de ces incidents mais nous ne les occultons pas complètement. Doit on supprimer cette notion ? Comment ? Ou peut on rendre cette notion plus vivable.
bon bah a force de regarder tes vidéos, youtube me propose que ta tête sur toutes ses reco... va falloir que je regarde des vidéos de chats pour contre balancer
Découvrez toute la communauté Scrum Life ! 👉 sl.run/DZgOQa
Salut JP
Merci pour tes vidéos. Je viens de découvrir la durée d'intégration à 1 semaine.
Et j'étais pas convaincu. Je le suis maintenant. Flexibilité, adaptabilité.
Bref, c'est génial.
Bonjour Jean-Pierre,
Bravo pour le cap des 500 ! :)
Après une première vision de cet épisode, j'ai le cerveau en ébullition !
J'avoue ne jamais avoir pensé à la durée des Sprints sous ces angles ... Je suis plutôt dans le "SHU" sur cet aspect là => merci de m'avoir secoué les neurones :)
@+
Franck
Pour notre part, nous avons une équipe de développement composée de 4 personnes. Après quelques tests avec une période d'itération plus longue (et alors que nous avions aussi une équipe plus volumineuse), nous avons décidé de partir sur des itérations d'une semaine. Cela peut sembler court et cela nécessite effectivement d'avoir automatisé un certain nombre de choses, mais nous avons effectivement comme force de pouvoir prendre en charge "rapidement" une demande en l'intégrant au sprint suivant qui n'est pas si loin que ça. Du coup, notre ligne "Urgent task" est généralement vide et est surtout réservée à des bugs ou des pré-requis non-identifiés en amont qui surviendraient au cours du sprint.
Si cette durée peut sembler assez courte, elle semble stimuler l'équipe.
Attention tout de même à un effet de bord : il faut que l'équipe puisse tenir le rythme dans le temps.
Par le passé, j'ai souvent été perçu comme un hurluberlu (même parmi les SM) d'ouvrir la question de la durée sacro-sainte d'un Sprint (2 semaines) dans une organisation Agile/Scrum. Plusieurs équipes étaient willing et ressentaient la même chose que moi.
Au départ, cela a été un simple "non". La raison était simple : garder toutes les équipes sur la même durée d'itération, conserver l'habitude (peur du changement), s'aligner sur la Roadmap officielle. Mais les contraintes étaient toujours bien présentes : des "urgences" qui entraient trop facilement dans un Sprint, des fréquences de Releases trop proches empêchant d'offrir une vraie belle expérience à nos clients et qui généraient alors des "ajustements" car l'idéation n'avait pas le temps de réflexion et préparation nécessaire. Souvent : un sentiment d'inachevé ou de non-complétion réelle par tous les membres. Ou plus métaphoriquement : un cochon d'inde en train de spinner dans sa roue, sans vision, sans but concret.
L'Organisation ayant vécu de nombreuses déceptions récurrentes, il a fallu un long accompagnement général pour accepter de tenter l'expérience, surtout en expliquant la réalité différentes des équipes DEV (périmètre d'action, besoin externe vs capacité d'autonomie, etc.). Certains avec des cycles de 3 semaines, d'autres de 1 semaines. Au final, toute cette réflexion a permis à l'organisation de revoir son approche et modèle de délivrables. Soulagés des PO mais aussi des Responsables, parfois à travers les fameuses Roadmaps, mais aussi en comprenant mieux leurs propres capacités opérationnelles.
Dans certains cas, cela a aussi permet de modifier des dynamiques d'équipe en interchangeant certains membres. Certains plus à l'aise dans un mode d'itération courte et d'autres plus efficaces et heureux avec du 2 ou 3 semaines.
Et je considère cette organisation comme réellement souple, flexible et ouverte aux idées. Ceci dit, je suis conscient qu'il restera toujours une forme d'inertie dans une organisation.
Un grand merci pour ce partage et retour d'expérience ! 👍👍👍
Salut Jean-Pierre, je te félicite pour le travail que tu réalises à travers cette chaîne, il faut être passionné, généreux et quelqu'un de bien pour offrir tout ça comme ça. Bravo.
+J'ai une petite question : à la minute 2:10 tu dis quelque chose du genre : "il faut qu'on prenne le temps de faire une phase de QS c'est obligé". QS ? Je ne sais pas si j'ai bien entendu ? S'il s'agit bien de QS, pourrais-tu expliquer ce qu'est-ce ? Merci
Il fallait comprendre "une phase de QA" (avec l'accent anglais bidon d'un français) -- Quality Assurance, une phase de test pour valider que tout marche bien en somme.
@@ScrumLife Merci beaucoup pour ta réponse rapide.
Hello JP, tu ne parle pas de « mou » ? Comment traiter le running en plus du dev dans une équipe scrum ?
Nous devons gérer des incidents, nous avons un process dans le sprint pour prévoir le coût de ces incidents mais nous ne les occultons pas complètement.
Doit on supprimer cette notion ? Comment ? Ou peut on rendre cette notion plus vivable.
Merci pour les réponses. À vrais dire j’ai déjà toute ces pistes d’explorées. Bon courage pour la faq.
bon bah a force de regarder tes vidéos, youtube me propose que ta tête sur toutes ses reco... va falloir que je regarde des vidéos de chats pour contre balancer
2 semaines
Merci ! Est-ce que tu trouves que cela correspond bien à votre contexte et à vos enjeux ?
-- JP