Je sais que c’est difficile et ça me peine qu’on en arrive là, crois moi.
C’est valable pour tout.
Et quid quand le CEO de la boite est malaide ou absent ?
Ou le manager d’une équipe ?
Ou le Scrum master ?
ou…
Il y a beaucoup de rôles « uniques » dans « un contexte ».
Ce n’est pas parce que le rôle est unique que la personne est irremplaçable.
Si le PO ne peut pas être absent plus de X jours, alors on met en œuvre ce qu’il faut pour que le cas échéant il soit remplacé.
Ca n’a rien de « SCRUM » c’est de la gestion de Talents.
En ITIL (je vous laisse choisir un autre cadre de gouvernance s’il vous en plait), l’objectif principal de la pratique Gestion des effectifs et des talents est de s’assurer que l’organisation dispose des personnes ayant les profils et les connaissances appropriées pour les différents rôles nécessaires.
http://www.ab-consulting.fr/blog/itil-4/guide-itil-4-de-a-jusqua-z
Ce que j’essaye donc de dire, c’est qu’il ne faut pas demander à SCRUM de tout faire.
Scrum propose un CADRE de développement pour des équipes pluridisciplinaires et auto-organisées.
Scrum n’indique pas comment elles doivent s’organiser, ni quelles disciplines elles doivent exploiter.
Et pour en revenir au « Un seul PO dans Scrum »
Imaginez un car ou un train ou une auto. Il peut y avoir plusieurs « conduct-owner » mais un seul au volant à la fois
Bah euh… si ? Nommément avec des rituels, artefacts et rôles.
Oui, mais tout le monde n’a pas le permis :0
Oui mais juste pour le traitement du backlog, pour le comment faire des choix dans ce qu’on va faire, comment se donner du temps pour inspecter, …
Mais pas le reste.
On a une idée de la durée d’un sprint mais ca dit juste « un cadre »
Ca ne précise pas l’horaire d’une journée, ca ne précise pas comment on doit coder, juste qu’il faut s’appuyer sur un principe de qualité. Mais ne dit pas comment on obtient ou on mesure cette qualité…
Je crois que tu te stresses un peu trop. Tu ne peux pas porter tous les problèmes de la boite sur tes épaules, sinon attention au craquage. C’est très idéaliste de penser que tout le monde va appliquer la méthode parce que c’est écrit dans le scrum guide. En fait, ça n’arrive jamais…
Dans les boîtes, les organisations sont souvent structurées par les ambitions et les intérêts des gens en fait. Donc ce n’est pas parce que c’est écrit dans le Scrum Guide que les gens vont l’appliquer mais plutôt parce que c’est dans leur interêt. Or, il est fort à parier que ton directeur et l’autre sont en concurrence dans leur évolution de poste. Il est fort probable d’ailleurs que l’un essaie de piquer les équipes de l’autre. Dans ce cas de figure ta démarche est très mal perçue par les directeurs, mais peut être aussi par ceux dans les équipes qui apprécient leur directeur et pas l’autre.
Tu seras perdante si tu essaies d’imposer ta vision comme ça. Si tu veux être entendue, il faut essayer d’aligner ce vers quoi tu veux aller avec leurs interêts. Très progressivement ça peut décoincer tout ça. Ne te stresse pas sur ton apprentissage, ça en fait partie. Personne n’a complétement la recette, sinon il n’y aurait pas ce forum, le scrum guide suffirait.
Le rôle de SM n’est pas un rôle opérationnel, c’est un rôle d’accompagnement, interchangeable. Pour preuve, les orga avec SM « tournant ».
Le CEO est entouré de managers, d’architectes, …
Le PO est le détenteur des attentes fonctionnelles, celui qui est le « propriétaire produit », celui qui maîtrise aussi tout l’histoire de son produit. Son rôle ne peut être repris par le 1er quidam venu. Sans PO, qui valide les US livrées ? Qui produit les US ? Qui répond aux questions fonctionnelles des Dev ? Qui travaille avec les utilisateurs pour mûrir les besoins ?
Je reste convaincu que c’est un des rôles les plus critiques au sein d’une équipe Scrum
C’est une comparaison réductrice. Le conducteur d’un train ou d’un car est comparable aux Dev : il emmène son bus où on lui a dit d’aller. Sa seule liberté c’est qu’il peut choisir la route. Et encore.
Le PO, il a déterminé qui monte dans le bus, à quelle date doit rouler le bus, si il doit s’arrêter ici ou là prendre/déposer des passagers …
A moins d’avoir des clones, qui ont les mêmes connaissances, compétences, sensibilités etc … tu n’auras pas les mêmes décisions. Donc tu mets du risque sur les projets
Hum… ça se débat. Un mauvais SM a autant de chance de faire planter une équipe qu’un PO manquant. Suffit d’une équipe encore très peu mature.
Pas moi. Le rôle critique, c’est l’équipe de Dev.
Pas d’équipe de dev, pas de produit.
Pas de produit, pas de palais.
Pas de palais, pas de palais.
Bonjour,
Je suis nouveau sur le forum et je dois avouer être surpris par plusieurs commentaires mais j’ai peut-être des choses à apprendre.
J’ai l’impression que la discussion dérive et ne répond plus éventuellement à la question initiale.
Pour aider @Hanh_NGUYEN, j’aimerai te conseiller d’éviter de prendre le rôle de coach agile. Cela demande de l’expérience car la transformation d’organisation est un sujet particulier avec différents savoir-faire. Mais je félicite ton courage.
Le cadre n’est pas respecté. Malheureusement sur une période de stage, il ne me semble pas sérieux de te proposer de faire évoluer ton environnement de manière significative.
Par contre, je te propose de jouer l’innocente. « Je ne sais pas », pouvons-nous lire ensemble le scrum guide ? Si tu arrives à leur faire lire et à se poser des questions dessus. tu pourras être fier de toi
Bonne chance.
Je vous remercie sincèrement pour vos conseils. Je suis PO de 3 produits différents avec des équipes différentes (+la casquette de SM pour 2 entre eux).
Ça fait plusieurs semaines que je n’ai plus de vie à côté, toutes les soirées et WE sont consacrés à Aix rédaction des documents, préparation des réunions et toutes les journées seront la course entre des réunions.
Je n’ai même plus temps de me poser pour réfléchir sur le travail à réaliser ou documenter pour la montée en compétence
Récemment, un de mes produits est mis en stand-by temporairement car restructuration interne de l’équipe dev (manque de compétence technique pour être autonome, changement de personnes, souci personnelle etc). Et je viens de demander de me retirer du produit interne que l’entreprise veut développer pour eux. Même au dernier moment, le directeur me disait que cette gouvernance est parfaitement 100% agile.
Pour moi, il me semble important d’acquérir de bonne pratique surtout au début. Si je prends ce que fait la SM comme normalisé, et je cherche à reproduire quand je serai en poste, c’est problématique. Je pense que j’apprends davantage en lisant et en regardant les différents documents.
En espace de quelques jours, je me trouve avec un seul produit au lieu de 3. Même si j’ai un pincement au cœur des situations de départs, je réjouis du fait que j’aurai un peu plus de temps pour réfléchir sur la façon de travailler, ce qui est à mettre en place dans l’équipe.
Hello @Hanh_NGUYEN , depuis le temps j’imagine que tu as trouvé une autre activité ? As-tu pris le temps de relire cette expérience ? Quel regard portes-tu sur la situation a posteriori maintenant que tu as (j’espère) sorti la tête du guidon ?