Déjà merci pour tout ce contenu ! Je rebondis également sur l'interaction direct PP=>dev dans le cas de la découverte d'un bug. J'ai pu constater que ce type d'interaction peut être extrêmement perturbant et désorganisant pour l'équipe de développement. Chaque PP estimant que le bug qu'il détecte est urgent, et l'équipe de développement, tout en étant focus sur le sprint, ne dispose pas toujours du recul nécessaire pour challenger et évaluer ce niveau de criticité.
Salut @antoine7117, Ton point de vue sur l’interaction directe PP=>dev lorsque des bugs sont découverts est très pertinent ! 🧐 En effet, ce genre de situation peut facilement perturber l’équipe de développement et créer des tensions si chaque Product Owner (PP) considère son bug comme une priorité absolue. L'idée serait peut-être de mettre en place un processus clair pour la gestion des bugs en cours de sprint. Par exemple, organiser un événement spécifique pour l’évaluation et la priorisation des bugs pourrait permettre de maintenir la concentration de l’équipe de développement sur leurs objectifs tout en assurant une gestion efficace des imprévus. Qu’en penses-tu ? As-tu déjà expérimenté des solutions pour mieux gérer cette problématique ? Bien amicalement, Robin de Scrum Life
Merci pour le contenu, je suis en train de bingewatcher toute la playlist ahah. Je m'interroge quand même par rapport à l'affirmation selon laquelle le product owner n'est pas le point d'entrée si un bug impactant est découvert par une partie prenante, qui peut le faire rentrer dans le sprint backlog via l'accord des devs. Dans l'orga où je travaillais, la rédaction des US comme des bugs suivait un formalisme stricte et d'ailleurs la correction d'un bug peut impliquer des choix fonctionnels qui sont plutôt de la responsabilité du PO. Du coup j'ai le sentiment que cette affirmation devrait être nuancée, en fonction de la nature du bug. des avis?
Salut @Apo595, Ton questionnement est très pertinent et soulève un point crucial dans la gestion des bugs en environnement Scrum. En effet, la responsabilité du Product Owner (PO) dans la gestion des anomalies peut varier d'une organisation à l'autre. Dans l'approche Scrum classique, le PO est le garant de la valeur et de la direction des produits, ce qui inclut souvent des décisions clés sur la correction des bugs impactants. Cependant, il y a effectivement des cas où le degré d'impact ou d'urgence du bug peut nécessiter une collaboration rapide et directe avec l'équipe de développement sans passer par le PO comme point d'entrée initial. Il est aussi important de souligner que chaque équipe doit adapter Scrum à son contexte particulier. Le dialogue continu entre le PO et les développeurs est essentiel pour assurer que les corrections de bugs soient bien alignées avec la vision produit tout en permettant une certaine flexibilité opérationnelle. Tu as raison, cette affirmation mérite d'être nuancée et doit souvent être ajustée en fonction de la nature du bug et des protocoles internes de l'organisation. Merci pour ton commentaire éclairé, ça pourrait être super intéressant d'échanger davantage sur ce sujet ! Amicalement, Robin
2 роки тому+2
Je réagis sur la "transgression" du circuit partie prenante => po => developers. Qu'une partie prenante aille voir directement un développeur, effectivement, ça arrive... Mais je pense nécessaire que le po soit mis au courant de cet échange, même si la décision en terme de faisabilité, de timing revient in fine à la charge des développeurs concernés et qu'ils devront en assumer les conséquences. Le fait de chuinter le po, c'est possible, mais il ne faut pas qu'il le prenne mal, et il ne faut pas casser sa vision du produit. Sinon, en rétro, ça risque d'être funky !!
Alors dans cette vidéo ce n’est pas précisé mais dans d’autres oui -> les dev doivent être transparent sur le sprint backlog. Le PO doit évidemment être dans les confidences… ou du moins qu’il n’y ait pas de confidence justement
Salut [Nom de l'auteur du commentaire] ! Je trouve ton point de vue très pertinent. L'idée de contourner le Product Owner (PO) peut effectivement être délicate. En fait, ce genre de situation peut vraiment mettre à l'épreuve la transparence et la communication au sein de l'équipe. Quand une partie prenante s'adresse directement aux développeurs, il est crucial de maintenir une boucle de feedback claire. Ça permet de préserver la vision du produit et d'éviter les malentendus. Ton avis sur le fait que le PO ne doit pas "le prendre mal" est intéressant. C'est aussi une excellente opportunité pour aborder ces questions lors des événements Scrum comme la revue de sprint ou encore la rétrospective. Cela permet de mettre en lumière ces cas et d'améliorer en continu le workflow de l'équipe. D'ailleurs, chez Scrum Life, on a souvent des discussions autour de ces sujets. Peut-être que tu pourrais également nous partager tes expériences ou poser des questions sur notre chaîne ? Au plaisir d’échanger plus avec toi ! Robin from Scrum Life
Déjà merci pour tout ce contenu !
Je rebondis également sur l'interaction direct PP=>dev dans le cas de la découverte d'un bug.
J'ai pu constater que ce type d'interaction peut être extrêmement perturbant et désorganisant pour l'équipe de développement. Chaque PP estimant que le bug qu'il détecte est urgent, et l'équipe de développement, tout en étant focus sur le sprint, ne dispose pas toujours du recul nécessaire pour challenger et évaluer ce niveau de criticité.
Salut @antoine7117,
Ton point de vue sur l’interaction directe PP=>dev lorsque des bugs sont découverts est très pertinent ! 🧐 En effet, ce genre de situation peut facilement perturber l’équipe de développement et créer des tensions si chaque Product Owner (PP) considère son bug comme une priorité absolue.
L'idée serait peut-être de mettre en place un processus clair pour la gestion des bugs en cours de sprint. Par exemple, organiser un événement spécifique pour l’évaluation et la priorisation des bugs pourrait permettre de maintenir la concentration de l’équipe de développement sur leurs objectifs tout en assurant une gestion efficace des imprévus.
Qu’en penses-tu ? As-tu déjà expérimenté des solutions pour mieux gérer cette problématique ?
Bien amicalement,
Robin de Scrum Life
Merci pour le contenu, je suis en train de bingewatcher toute la playlist ahah.
Je m'interroge quand même par rapport à l'affirmation selon laquelle le product owner n'est pas le point d'entrée si un bug impactant est découvert par une partie prenante, qui peut le faire rentrer dans le sprint backlog via l'accord des devs.
Dans l'orga où je travaillais, la rédaction des US comme des bugs suivait un formalisme stricte et d'ailleurs la correction d'un bug peut impliquer des choix fonctionnels qui sont plutôt de la responsabilité du PO.
Du coup j'ai le sentiment que cette affirmation devrait être nuancée, en fonction de la nature du bug. des avis?
Salut @Apo595,
Ton questionnement est très pertinent et soulève un point crucial dans la gestion des bugs en environnement Scrum. En effet, la responsabilité du Product Owner (PO) dans la gestion des anomalies peut varier d'une organisation à l'autre.
Dans l'approche Scrum classique, le PO est le garant de la valeur et de la direction des produits, ce qui inclut souvent des décisions clés sur la correction des bugs impactants. Cependant, il y a effectivement des cas où le degré d'impact ou d'urgence du bug peut nécessiter une collaboration rapide et directe avec l'équipe de développement sans passer par le PO comme point d'entrée initial.
Il est aussi important de souligner que chaque équipe doit adapter Scrum à son contexte particulier. Le dialogue continu entre le PO et les développeurs est essentiel pour assurer que les corrections de bugs soient bien alignées avec la vision produit tout en permettant une certaine flexibilité opérationnelle.
Tu as raison, cette affirmation mérite d'être nuancée et doit souvent être ajustée en fonction de la nature du bug et des protocoles internes de l'organisation. Merci pour ton commentaire éclairé, ça pourrait être super intéressant d'échanger davantage sur ce sujet !
Amicalement,
Robin
Je réagis sur la "transgression" du circuit partie prenante => po => developers. Qu'une partie prenante aille voir directement un développeur, effectivement, ça arrive... Mais je pense nécessaire que le po soit mis au courant de cet échange, même si la décision en terme de faisabilité, de timing revient in fine à la charge des développeurs concernés et qu'ils devront en assumer les conséquences. Le fait de chuinter le po, c'est possible, mais il ne faut pas qu'il le prenne mal, et il ne faut pas casser sa vision du produit. Sinon, en rétro, ça risque d'être funky !!
Alors dans cette vidéo ce n’est pas précisé mais dans d’autres oui -> les dev doivent être transparent sur le sprint backlog. Le PO doit évidemment être dans les confidences… ou du moins qu’il n’y ait pas de confidence justement
Salut [Nom de l'auteur du commentaire] !
Je trouve ton point de vue très pertinent. L'idée de contourner le Product Owner (PO) peut effectivement être délicate. En fait, ce genre de situation peut vraiment mettre à l'épreuve la transparence et la communication au sein de l'équipe. Quand une partie prenante s'adresse directement aux développeurs, il est crucial de maintenir une boucle de feedback claire. Ça permet de préserver la vision du produit et d'éviter les malentendus.
Ton avis sur le fait que le PO ne doit pas "le prendre mal" est intéressant. C'est aussi une excellente opportunité pour aborder ces questions lors des événements Scrum comme la revue de sprint ou encore la rétrospective. Cela permet de mettre en lumière ces cas et d'améliorer en continu le workflow de l'équipe.
D'ailleurs, chez Scrum Life, on a souvent des discussions autour de ces sujets. Peut-être que tu pourrais également nous partager tes expériences ou poser des questions sur notre chaîne ?
Au plaisir d’échanger plus avec toi !
Robin from Scrum Life