Je suis Scrum Master dans une équipe qui développe et maintient une appli qui sert à gérer des adhérents, des événements, etc. pour le compte d’une grosse association.
Notre P.O. est du côté ‹ client ›.
Elle est consultante d’une ESN, recrutée par le client,
Elle n’a pas vocation, donc, à rester plus de 2 ans dans la boîte (je crois savoir que les ESN ont des contrats à durées limitées pour leurs consultants)
Elle est aussi le bras droit du directeur du Service Informatique chez le client,
Elle a fait entrer chez le client une de ses collègues de l’ESN à laquelle elle appartient, qui lui sert de Proxy P.O. pour une partie bien précise de son travail (et qui deviendra peut-être la prochaine PO, quand elle-même arrivera à son maximum de durée de contrat possible chez le client. C’est mon intuition, rien d’officiel)
Enfin, la PO fait aussi les tests sur les plateformes de qualif, après que la QC ait fait les siens.
Devinez… elle a beaucoup de retard dans la gestion du Product Backlog…
J’ai fait ce que j’ai pu pour l’inciter à s’en occuper, en priorité, je lui proposé mon aide, etc. Rien n’y fait.
Elle reconnaît ne pas vouloir renoncer à ses autres rôles chez le client (notamment ce rôle de bras droit du directeur du SI, et toutes les réunions qui vont avec).
J’aimerais vos avis, svp.
Qu’est ce qui vous choque le plus dans la liste que j’ai fournie?
Est-ce que c’est normal, souhaitable qu’elle assiste à toutes les réunions qui ont un rapport de près ou de loin avec le S.I. ? (ça pourrait. L’appli dépend de la santé de tout le reste du système informatique)
Dans un monde idéal ou dans vos propres entreprises, est-ce que toutes ces tâches sont effectivement dévolues à la/au P.O. ?
Ma réponse sera déjà « plombée » par le fait que quand je lis « proxy po » je lis « messager tampon pour casser l’élément le plus important : la communication »
Un PROXY PO = intermédiaire d’un faux PO qui veut pas se mouiller.
==> Ok pour continuer mais arretons avec l’agile/scrum bullshit.
==> Ok pour partir d’où on est , et d’apprendre à s’améliorier mais dites moi qui décide vraiment et qu’il se mouille, qu’il vienne montrer ce qu’il veut, qu’il accepte d’ouvrir le dialogue.
Et s’il dit qu’il n’a pas le temps, qu’il fasse un delegation poker avec le « Proxy » PO qu’on lui retire cet adjectif ridicule et dégradant pour quelqu’un qui lui est prêt à se mouiller.
Et si le client n’est pas d’accord, alors à votre boite de voir si elle se plie aux exigences et de se laisser dire comment faire votre boulot, ou si elle veut défendre son image de boite qui a choisi un mode de travail agile.
Pour moi, la personne cherche autre chose que son role de PO.
Un PO est LE responsable du product backlog et son ordre/priorisation
Il peut déléguer des taches de son rôle mais il en est reponsable. Donc oui, je suis en phase avec toi, il y a un sujet
Tu décrit ce que j’appelle un chef de projet qui a pris un porte de PO pour entrer dans la boite mais pas réellement pour etre responsable du produit
Ce n’est pas un problème que quiconque fasse des « tests ».
Mais
==> l’équipe est responsable du livrable.
==> le PO fait partie de l’équipe.
==> l’équipe est responsable du livrable.
Le testing est une partie de la DOD, des membres de l’équipe assurent le testing.
Le testing est fait hors de l’équipe => ça s’appelle du feedback, c’est « une information » pour que le PO choisisse comment orienter son backlog et ses objectifs.
Est-ce qu’en tant que S.M.le sujet a été abordé avec le PO et le proxy PO ?
L’avez-vous évoqué ensemble à la Rétro (en présence des devs, des (*) PO ?
Oubliez les étiquettes PO proxy, Po testeur, sm …
Listez tous les livrables de l’activité.
Clarifier avec un RACI pour rappeler les livrables et l’ensemble des responsabilités sur chaque livrable.
On n’oublie pas qu’une responsabilité se prend, elle ne se donne/impose/force pas.
Délégation poker peut aider à clarifier aussi pas mal de chose sur chaque livrable.
Nous n’avons aucune « perspective » (je ne trouve pas comment le dire) : les tickets arrivent à la dernière minute, sans cohérence en termes de thématique, il n’y a pas de Sprint goal pré-imaginé.
La P.O. se dépêche de fabriquer quelques tickets, vite, vite, pour donner du boulot aux dév, et nous n’avons donc aucune matière à réfléchir collectivement, en Sprint planning, par exemple, sur la stratégie à adopter pour parvenir à un objectif de Sprint qui serait cohérent d’avec les priorités du client.
Il y a bien eu quelques thématiques principales censées être les priorités du client, mais les tickets ne sont pas en cohérence avec elles.
En fait, cette « proxy P.O. » n’est pas officiellement intitulée ainsi.
Elle a été recrutée comme « Business Analyst », mais au final, elle s’occupe d’une partie du boulot de la P.O. : notre appli a une partie mobile et une partie web. La « Proxy » s’occupe de faire le boulot de P.O. sur la partie mobile. Ca aurait dû bien décharger la P.O., mais manifestement toujours pas assez…
D’autant plus difficile, que dans mon cas, mon organisation c’est le sous-traitant du client, et le client est le responsable hiérarchique de la P.O.
Autrement dit, non seulement il y a DEUX organisations à convaincre de l’utilité d’installer du Scrum mais en plus la P.O. joue pour notre client, et en l’occurrence, il y a de grosses tensions entre mon orga et le client (grosse défiance de la part du client à notre égard, pour des raisons historiques, et suite à un gros turn-over des personnes responsables de leur service informatique qui ne sont plus dans le même état d’esprit que leurs prédécesseurs).
Donc, la P.O. a tendance à défendre les intérêts du client, au prix des intérêts de l’équipe… C’est logique, vu sa situation, mais ça tue la dynamique de collaboration, de transparence, de confiance qu’on est censé-es alimenter en équipe Scrum.
A quoi penses-tu concrètement, @TheLimande quand tu parles de « démarrer une transformation », stp?
Merci pour tes messages, @Moosh, mais j’avoue ne pas avoir tout compris …
Notamment le passage sur les tests. Que cherches-tu à dire, en rapport avec ma publication?
Sinon, oui, le problème a été abordé à plusieurs reprises dans plusieurs rétro, en présence de tout le monde.
Qu’est ce que tu appelles les « livrables »? Parles-tu des artefacts Scrum? (Sprint Backlog, PB, increment?).
Est ce que tu suggères que je fasse un rappel des accountabilities de chacun dans l’équipe?
Pour en revenir à ta première question, le PO peut avoir une « vie » hors l’équipe, hors le produit, moi ça ne me choque pas du tout.
Par contre le Po a des impératifs : indiquer en quoi le prochain sprint apporterait de la valeur, travailler avec vous sur la sélection des items de backlog nécessaires et la définition de l’objectif de sprint. Il doit répondre aux questions des développeurs tout au long du sprint, rien n’interdit qu’un besoin fonctionnel ne soit que très peu détaillé en sprint planning mais qu’une collaboration avec la devteam en cours de sprint aboutisse à de très beaux résultats. Donc forcément tout ça prend du temps pour le PO
Si l’équipe doit fournir des résultats, vous avez des attentes vis à vis du PO, c’est légitime, et ces attentes vous devez les formuler au PO. Mais ces attentes le PO doit comprendre aussi pourquoi vous en avez. Je m’explique, si vous lui demandez de la dispo, des tickets triés et des tickets détaillés, elle peut prendre ça comme une attaque, un caprice, comme un botte en touche. En lui expliquant par contre que vous avez besoin de transparence, d’une vision, d’une collaboration pour assurer que la mission qu’elle mène sera la plus qualitative possible alors ça peut peut-être mieux passer.
Tu dis par exemple qu’elle teste en qualif, très bien, mais comment ça se passe ? Teste-t-elle en continu à chaque petite livraison ou bien en fin de sprint ? Tester en cours de sprint à chaque petite livraison c’est top pour impliquer les gens et récupérer du feedback et tout ça avant la fin de sprint.
Je comprends que le PO fait des tests… et que ca nuit sur son temps de travail sur le backlog…
Et je réponds que le problème c’est bien que « s’occuper du backlog » passe après autre chose.
Mais un PO qui teste ca ne me dérange pas.
Pour autant que le résultat du test soit une information pendant le sprint pour valider que la story est finie. Mais attention dans ce cas, le PO teste au même titre que tous les autres membres de l’équipe.
Le PO n’est pas là pour valider le travail de l’équipe. L’équipe dont le PO est un des membres est là pour valider le travail de l’équipe. (L’effet de bord néfaste qu’on rencontre parfois c’est "le PO doit tout tester avant livraison. Faux, c’est l’équipe qui est responsable de ce qui est livré, pas le PO.
Et si le test est fait après la livraison/le sprint, alors c’est juste une source de feedback. Et de nouveau c’est pas avec sa casquette de PO,
Par livrable j’entends la liste des choses à faire pour que le travail fonctionne.
Qui s’occupe du board ?
Qui organise la revue de sprint ?
Qui envoie les invitations pour la revue de sprint ?
Qui réserve la salle pour …
Qui s’occupe du backlog ?
Qui teste ?
Si on est en scrum , les réponses sont dans le guide.
Si on veut faire différemment, alors il faut clarifier et aligner tous les protagonistes sur qui fait quoi.
quand je parle de démarrer une transformation, c’est passer du cycle en V à l’agile
que le PO soit celui qui fait communiquer l’équipe et les utilisateurs
moi, si le PO n’écrit pas les US, ce n’est pas un problème, ça peut aussi être coécrit par l’équipe et l’utilisateur.
ce qui est important, c’est que le PO ordonne, qualifie (ça fait ou non partie du backlog), etc.
tout ce qui est noté dans le Scrum Guide en gros
il faut rappeler le scrum guide, la version actuelle est tellement courte que cela est dommage de ne pas le faire
ce qui fera prendre conscience qu’il y a des tâches non faites, à faire ou à redistribuer, ce que vous pouvez faire avec un RACI
j’aime bien mettre des fiches d’activité pour chaque profil de l’équipe, organisé en 3 colonnes : je fais/je suis, je peux faire/je peux être, je ne fais pas/je ne suis pas
bonjour @TheLimande
les fiches en questions tu les construis avec chaque équipe ou tu leur fourni une version que tu as travaillé de ton coté? (genre matrice des attendus)
merci
avec le temps, j’ai une fiche officielle validée par la société, donc facile à diffuser en interne
mais pour la construire, il est intéressant de donner la liste des activités et d’essayer de faire placer l’équipe dans les 3 colonnes
les fiches officielles sont la cible, validée par la hiérarchie, le cadre
ce que construit l’équipe est souvent plus intéressant, ils y ont participé, ils échangent sur ce qui est attendu, ce qui semble implicite
j’aime aussi faire l’atelier de DoD et DoR avec l’équipe, aussi par ce que je suis plutôt en Kanban qu’en Scrum et que du coup j’ai un Board avec plus d’états qu’en Scrum de base mais surtout que ça permet de faire échanger sur ce qu’attends chaque personne de l’autre, et comment on va travailler ensemble
La P.O. teste les tickets au fur et à mesure qu’ils sont créés par les dév, après que la QC (Quality Controler) ait fait ses propres tests. Aussi bien la QC que la PO font leurs tests sur des environnements dédiés (je me rends compte que ces environnements isolés et réservés aux tests, ne sont peut-être pas ce qu’on appelle environnements de « qualif »! Désolée si j’ai induit qui que ce soit en erreur!).
Moralité, elle fait ses tests comme une testeuse n°2, personne d’autre n’est impliqué, et on n’a aucun feedback à ce stade.
Si elle est satisfaite des tests, elle « accepte » le ticket, qui est considéré comme pouvant être déployé en Préprod, et c’est seulement ensuite qu’elle peut faire faire les tests par le métier, ou les faire elle-même pour s’assurer que ça fonctionne toujours.
Donc, la partie chronophage où elle fait les tests sur son environnement dédié, ne sert à rien d’autre qu’à tester.
Et elle tient beaucoup à garder ça (j’ai déjà proposé de les faire à sa place pour la libérer), et les dév aussi préfèrent qu’elle en soit seule responsable, pour éviter que la responsabilité d’une erreur de test retombe sur l’équipe (Dév + Scrum).
C’est vous dire l’ambiance de défiance qui règne entre la P.O./client et nous (dév & SM)…
Ok, donc c’est pas l’activité de test qui est un réel problème, c’est le fait qu’elle devienne un goulot d’étranglement si toutes les cartes doivent repasser par elle.
C’est un sujet à craquer, les DoR et DoD peuvent montrer ça ou mieux, un bon cieux Cumulative Flow peut aussi montrer les blocages si vous tracez votre flow.
Chez nous, quand quelqu’un de l’équipe produit participe aux tests, c’est avec les testeurs, sous la responsabilité du Test Lead
la notion d’équipe, One Team est sûrement à creuser également, ce qui sort de l’équipe, toute l’équipe en est responsable
tant qu’il n’y aura pas de confiance, esprit d’équipe, un objectif commun (sprint goal) ça ne bougera pas
tu peux essayer déjà en fixant des sprint goals avec l’équipe et le métier : qu’est ce qu’on peut te délivrer pour dans 15j ?
et l’équipe tous les jours veille à ce que cet objectif soit atteint, que les cartes les plus importantes sortent.
