En fait ce que vous décrivez dans le représentant des utilisateurs est exactement le PO que décrit le Scrum guide!!! Dans les faits pour nombre de pratiquants de Scrum, le PO est un rôle IT de rédaction de spécs pour alimenter des développeurs qui sont des "machines à coder" (toi aussi tu as reconnu la relation AMOA/MOE "agilifié"?). Et d'ailleurs nombre de développeurs ne sont aujourd'hui pas prêts (au niveau mindset ou maturité) à co-construire le produit avec ce "PO". Je vous renvoie au scrum guide, pour étayer mon propos : "Le Product Owner peut lui-même accomplir les tâches susmentionnées ou les déléguer à l’équipe de Développement."
Tout à fait, c'est le sens de l'intervention. Pour le "représentant des utilisateurs" les fonctions occupées sont effectivement similaires à celle d'un Product Owner,, telles qu'elles sont décrites dans le Scrum Guide. La question pourrait se poser en ces termes : Est-ce qu'un utilisateur d'un logiciel consacrant un peu de temps chaque semaine pour exprimer les besoins, les prioriser, qualifier les fonctionnalités... ne portant pas le titre de Product Owner, n'ayant jamais entendu ce terme, ni celui de backlog, de sprint ou de Scrum, est-il encore un "Product Owner" ? Le sens du propos étant de plutôt privilégier le fond, l'esprit (chercher une personne pouvant être l'interlocuteur de l'équipe de développement, peu importe son intitulé de poste) plutôt que la forme, la lettre : créer coûte que coûte un poste de Product Owner, avec les risques de dérives que l'on voit sur le terrain et que vous décrivez fort bien de votre commentaire.
Après cella dépend du temps que cette personne métier peut dégager pour la prio et le feed back test. car souvent il est 100% comptable et 0% feed back et priorisation chaque semaine.
Merci pour ce retour. C'est effectivement un point d'attention. Nous annonçons au client dès le début de la relation que cette personne doit avoir du temps à consacrer à l'équipe. Combien ? Cela dépend beaucoup du nombre de développeur qu'il y a dans l'équipe, de la nature du produit... A titre d'illustration, pour 4 développeurs à temps plein, nous pouvons proposer 2 demi-journées par semaine.
@@fredericleguedois5608 Merci pour ta réponse, en effet un petit contrat moral de 1/5 du temps voir 1/4 est indispensable. On a trop souvent des demandes prioritaires non testées sur des mois ou plusieurs sprints sans personnes aux revues.
@@mmimmi73 Nous ne fonctionnons pas en Scrum (même s'il y a de nombreuses similitudes). Chaque partage avec le client fait l'objet d'un rendez-vous (qui peut être récurrent). Et si le client ne vient pas au rendez-vous (ce qui n'est arrivé que très rarement mais est de triste augure), alors il y a un vrai sujet à traiter. Donc si après 15 min. d'attente, si personne n'est présent, annulation d'un point avec expédition d'un mail au client pour planifier de nouveau le point rapidement. Sans réponse, escalade commerciale, voire suspension du développement.
SCOOP : En fait Frédéric sait se tenir !! :p Ça change par rapport à ses conférences (dont je suis grand fan)... Surement l'effet "Caméra". Sinon, je suis tout à fait en phase... Selon le contexte (un produit pour un client ou pour plusieurs clients) le PO n'est pas indispensable.
Découvrez toute la communauté Scrum Life ! 👉 sl.run/gfIgVQ
Bel exemple d'intelligence situationnelle - le meilleur outil du praticien d'Agilité ! Merci à tous les deux pour cet épisode !
Merci Paul-Emmanuel.
En fait ce que vous décrivez dans le représentant des utilisateurs est exactement le PO que décrit le Scrum guide!!! Dans les faits pour nombre de pratiquants de Scrum, le PO est un rôle IT de rédaction de spécs pour alimenter des développeurs qui sont des "machines à coder" (toi aussi tu as reconnu la relation AMOA/MOE "agilifié"?). Et d'ailleurs nombre de développeurs ne sont aujourd'hui pas prêts (au niveau mindset ou maturité) à co-construire le produit avec ce "PO".
Je vous renvoie au scrum guide, pour étayer mon propos : "Le Product Owner peut lui-même accomplir les tâches susmentionnées ou les déléguer à l’équipe de Développement."
Tout à fait, c'est le sens de l'intervention. Pour le "représentant des utilisateurs" les fonctions occupées sont effectivement similaires à celle d'un Product Owner,, telles qu'elles sont décrites dans le Scrum Guide. La question pourrait se poser en ces termes : Est-ce qu'un utilisateur d'un logiciel consacrant un peu de temps chaque semaine pour exprimer les besoins, les prioriser, qualifier les fonctionnalités... ne portant pas le titre de Product Owner, n'ayant jamais entendu ce terme, ni celui de backlog, de sprint ou de Scrum, est-il encore un "Product Owner" ? Le sens du propos étant de plutôt privilégier le fond, l'esprit (chercher une personne pouvant être l'interlocuteur de l'équipe de développement, peu importe son intitulé de poste) plutôt que la forme, la lettre : créer coûte que coûte un poste de Product Owner, avec les risques de dérives que l'on voit sur le terrain et que vous décrivez fort bien de votre commentaire.
Ca me semble plus viable que les PO sans équipe.
Sans aucun doute 😂
Après cella dépend du temps que cette personne métier peut dégager pour la prio et le feed back test. car souvent il est 100% comptable et 0% feed back et priorisation chaque semaine.
Merci pour ce retour. C'est effectivement un point d'attention. Nous annonçons au client dès le début de la relation que cette personne doit avoir du temps à consacrer à l'équipe. Combien ? Cela dépend beaucoup du nombre de développeur qu'il y a dans l'équipe, de la nature du produit... A titre d'illustration, pour 4 développeurs à temps plein, nous pouvons proposer 2 demi-journées par semaine.
@@fredericleguedois5608 Merci pour ta réponse, en effet un petit contrat moral de 1/5 du temps voir 1/4 est indispensable. On a trop souvent des demandes prioritaires non testées sur des mois ou plusieurs sprints sans personnes aux revues.
@@mmimmi73 Nous ne fonctionnons pas en Scrum (même s'il y a de nombreuses similitudes). Chaque partage avec le client fait l'objet d'un rendez-vous (qui peut être récurrent). Et si le client ne vient pas au rendez-vous (ce qui n'est arrivé que très rarement mais est de triste augure), alors il y a un vrai sujet à traiter. Donc si après 15 min. d'attente, si personne n'est présent, annulation d'un point avec expédition d'un mail au client pour planifier de nouveau le point rapidement. Sans réponse, escalade commerciale, voire suspension du développement.
SCOOP : En fait Frédéric sait se tenir !! :p
Ça change par rapport à ses conférences (dont je suis grand fan)... Surement l'effet "Caméra".
Sinon, je suis tout à fait en phase... Selon le contexte (un produit pour un client ou pour plusieurs clients) le PO n'est pas indispensable.
Effectivement, à média différent, comportement différent.