Je vous propose un petit jeu.
Forcément, il y a des choses vraies et des choses moins vraies.
A vous de trouver les failles et les éléments qui vous paraissent incompatibles avec la bonne pratique de l’agilité… mettons de côté le framework utilisé dans ce jeu.
Qu’est ce qui vous choque ?
L’idée est d’échanger sur les bonnes pratiques à avoir quand on est un PO.
Vous êtes prêts ? C’est parti !
Le PO gère ou ou plusieurs produits. Et donc, est dans plusieurs équipes… théoriquement.
En fait, le PO est hors des équipes, il est juste là pour créer des US.
Le PO est le responsable de son ou ses produits. Et donc, s’il y a un problème en prod c’est lui le responsable.
Le PO gère son ou ses backlogs et priorise ses tickets.
Le PO ne dérange pas les devs. Il doit passer par le SM quand il veut leur poser une question et poser une réunion pour ne pas les déranger dans leur travail.
Le PO est toujours disponible pour les membres de l’équipe à tout moment. Les devs ou le SM peuvent venir lui parler quand ils veulent.
Le PO présente les US en refinement.
Le PO ne participe pas au « chiffrage » des US avec l’équipe.
Le PO ne participe pas au sprint planning de l’équipe.
Le PO est présent au DM mais ne parle pas, ou alors tout à la fin s’il a quelque chose à dire.
Le PO ne participe pas à la rétrospective.
Le PO ne décide pas quand une US rentre dans un sprint, c’est le SM qui décide ça.
Qu’en pensez-vous ?
Que faut-il changer dans toutes ces affirmations pour retrouver un cadre agile efficace et juste ?
Est-ce qu’il faut mettre oui ou non derrière chaque phrase ?
Allez je me lance, je suis là pour apprendre
Le PO gère ou ou plusieurs produits. Et donc, est dans plusieurs équipes… théoriquement. → Non. On pratique que c’est ce que je fais en ce moment mais je trouve que c’est très compliqué, je n’ai pas de temps pour faire le métier de manière aussi élaborée comme je veux
En fait, le PO est hors des équipes, il est juste là pour créer des US. → Non, on ne fait pas que des US
Le PO est le responsable de son ou ses produits. Et donc, s’il y a un problème en prod c’est lui le responsable. → responsable du produit oui, en terme de vision et de stratégie. Pour la partie développement et prod, la responsabilité est partagée avec l’équipe.
Le PO gère son ou ses backlogs et priorise ses tickets.–> oui
Le PO ne dérange pas les devs. Il doit passer par le SM quand il veut leur poser une question et poser une réunion pour ne pas les déranger dans leur travail. → c’est le cadre qu’on m’impose maintenant et je prouve beaucoup de frustration d’avoir la SM comme le seul interlocuteur. Je dirais non dans le cadre idéal
Le PO est toujours disponible pour les membres de l’équipe à tout moment. Les devs ou le SM peuvent venir lui parler quand ils veulent → oui, si on n’est pas disponible il faudra qu’on revienne assez rapidement
Le PO présente les US en refinement → oui
Le PO ne participe pas au « chiffrage » des US avec l’équipe. → tu veux parler de poker planning ? C’est les dev qui chiffrent
Le PO ne participe pas au sprint planning de l’équipe → Oh si !.
Le PO est présent au DM mais ne parle pas, ou alors tout à la fin s’il a quelque chose à dire → on n’a pas besoin d’être présent (je le fais maintenant mais avec la casquette SM).
Le PO ne participe pas à la rétrospective → Si, PO fait partie de l’équipe !.
Le PO ne décide pas quand une US rentre dans un sprint, c’est le SM qui décide ça. → Non, PO décide avec les dev (par contre sur un de mes projets, c’est bien la SM qui décide )
Je n’ai pas été assez précis sur la question 8. Je voulais carrément dire le PO n’assiste pas au planning poker. C’est encore pire
Merci pour ton retour d’expérience.
Je me suis appuyé sur l’existant pour voir à quel niveau il y a vraiment des couacs et où c’est plutôt moi qui suis à la ramasse quant à mon ressenti.
Pour la remarque concernant le PO fait partie de l’équipe, tu comprendras qu’à la question 1, lorsqu’il y a plusieurs produits, c’est plutôt compliqué de faire partie de plusieurs équipes… je ne parle même pas des DM qui ont lieu en même temps… des sprint plannings également…
Normalement c’est au PO de proposer la liste des US prioritaires , et les développeurs choisissent à partir de cette liste, donc pour moi , tous les deux participent dans la décision (en deux étapes)
Si on suit le guide scrum, le PO indique en quoi il veut améliorer le produit, dans le sens apporter de la valeur en plus via un incrément. Pour répondre à ça, ce sont les développeurs qui choisissent les éléments de backlog qui répondent à l’enjeu et sont réalisables dans le sprint.
Les items du backlog sont sensés être clairs pour tout le monde grâce aux différents affinages.
L’enjeu du sprint argumenté par le PO, les items sélectionnés par les développeurs, aboutissent à un objectif clair, non ambigu, communicable, atteignable, challengeant, derrière lequel se regroupe l’équipe complète.
Le backlog lui même est évolutif et le PO doit rédiger les US au fur et à mesure en fonctionne de la direction qu’il veut avancer (la priotisation).
Les dev ne peuvent choisir ce qu’ils veulent parmi les US « prêts » (c’est-à-dire rédigés, discuté sur la difficulté, 3 amigos etc). Donc il y a déjà une sorte de tri n’est-ce pas ?
Je suis plutôt d’accord avec @Hanh_NGUYEN . En effet les dev choisissent selon l’objectif. Et peut être pendant le sprint ils vont même proposer une nouvelle US qui n’avait pas été créé par le PO, dans le but de répondre à la direction donnée. Mais dans les fait le PO a déjà réfléchi à cette direction et a déjà un backlog priorisé, donc il y a de forte chance que les US entrants dans le sprint soit en majorité celle qui sont en haut. Et les devs de peuvent pas choisir une story sans que le PO soit aussi d’accord, même si ils pensent que ça correspond à l’objectif.
c’est génial ce que vous êtes en train de faire car ces questionnements, ces échanges sont super constructifs et c’est exactement ce vers quoi l’équipe doit tendre et être capable de faire… il y a une base qui est posée, disons un objectif présenté par le PO à atteindre avec l’équipe puis c’est l’équipe qui fait vivre tout ça exactement comme vous le faites en échangeant ! C’est super top ce forum et vos idées sont super intéressantes et constructives. Chacun a un avis, chacun a une idée et rien que le fait de proposer et d’échanger démontre que vous avez la bonne approche pour améliorer les choses ! Merci à vous pour ça !
Selon moi, un des éléments qui est trop souvent relégué au second plan, c’est « l’objectif » du sprint.
Trop souvent j’ai été confronté à un sprint planning où le PO dit à l’équipe :
PO : « Bon, sur ce sprint, on doit sortir telle, telle et telle US »
Dev : « OK, moi j’au une US tech (montée de version Springboot) à prendre »
PO : « D’accord. Bon, on met quoi dans l’objectif du sprint ? »
Pour moi, l’objectif du sprint doit être le préalable à tout. Pour atteindre mon objectif je prends les US nécessaires. Et non pas "j’adapte mon/mes objectif(s) aux US choisies…
Ce point a été un des trucs les plus compliqués à faire adopter
Déjà le terme US apporte un biais qui joue beaucoup sur la compréhension du système par l’équipe.
Tout est tourné vers l’User, et quand bien même c’est une approche indispensable, elle est fondamentalement insuffisante. L’architecture du code est importante (tâches bas niveau et techniques), le process est important (amélioration continue et aménagements décidé à la rétro), la compréhension du contexte est importante (spikes, travaux de recherches). Une approche où on ne pense qu’en US à tendance à invisibiliser tout ça. Besoin de prendre du temps pour améliorer un temps de réponse d’un serveur trop lent ? SBI. Besoin de temps pour en apprendre plus sur des notions métiers nécessaires au développement ? SBI. Besoin de prendre du temps pour accueillir une nouvelle personne dans l’équipe ? SBI. Tout ça dans une volonté de transparence du travail.
A partir d’une approche comme celle là, on commence à s’ouvrir des portes en termes de Sprint Goals qui vont bien plus loin qu’une paraphrase des « US » envisagées.
Dépend du contexte. Pour plusieurs produits simple, dans une structure simple, ça ne me dérange pas. (autant dire que ça n’arrive que très rarement hein…)
OMG…
Dépend de ce qui est entendu par « problème en prod ». Si c’est un bug technique, l’équipe de dev est seule et entière responsable de cet état de fait. Le pauvre PO a pas écrit une ligne de code, laissez le tranquille. xD
Product backlog, oui.
Au secours, quelle horreur. C.o.m.m.u.n.i.c.a.t.i.o.n. Si l’équipe de développement ne supporte pas d’être interrompue, je me fais du soucis pour sa façon de travailler…
C’est virtuellement impossible. Un PO a des stakeholders à voir, des choses à faire de son côté et ce potentiellement pas sur site… A la limite, un téléphone « d’urgence » est une bonne chose, mais à utiliser avec parcimonie.
Non. Il présente des PBI. Si pour les faire comprendre plus en détail il y a besoin d’US, ou (je préfère) de use-cases, go for it. Mais l’US n’est jamais un prérequis ni une finalité.
Si. Parce que le but premier du « chiffrage », c’est avant tout la communication.
Si. Parce que le but premier du sprint planning, c’est avant tout la communication.
Si. Parce que le but premier du DM, c’est avant tout la communication.
Si. Parce que le but premier de la rétrospective, c’est avant tout la communication.
Top, ce la montre bien le problème de base qui est la COMMUNICATION…
Point le plus urgent à corriger pour améliorer l’équipe.
Pour toutes tes remarques, je suis d’accord avec ton point de vue.
J’ai l’impression que je suis à mi-chemin de la bonne pratique. En général je propose à l’équipe " pour ce sprint, j’aimerais donner aux utilisateurs la possibilité de XXX", on discute ensemble de ce qu’on va prendre, mais comme on arrive pas à prendre tous ce qui faut pr réaliser ce qu’on veut, on se retrouve avec un sprint goal (qui est une partie de l’objectif initial) fixé après voir choisi les US
Dans la mesure du possible tu dois toujours essayer de faire en sorte que ton livrable à la fin du sprint soit une ou plusieurs fonctionnalités qui apportent un plus à ton client et qui correspondent au but du sprint. Toutes les fonctionnalités ne rentrent pas forcément sur un sprint, dans ce cas, tu auras besoin de plusieurs sprints pour la ou les terminer. Mais tant que tu n’as pas terminé l’intégralité de ta fonctionnalité, tu n’en parles pas, on va dire, et tu ne fais pas apparaitre tes tickets dans ton bon de livraison. Il ne faut pas confondre non plus le fait que l’équipe développe et le fait que l’équipe livre… tant que la fonctionnalité n’est pas complète, ils ne la livrent pas sur ton master (pour résumer simplement)
)
