Après quelques années dans une (petite) agence web en tant que webdesigner où on fonctionnait en mode projet et pas en mode produit et n’ayant jamais travaillé selon une méthode Agile (encore moins Scrum), j’ai décidé de changer de boite et de poste pour être PO pour une boite qui développe un CRM (c’est un exemple bateau).
Demain, c’est mon premier jour**, et bien évidemment, avec l’équipe Scrum, on ne va pas faire tout de suite notre premier sprint. Du coup afin et avant nos 3-4 premiers sprints :
qu’est-ce que je suis censé faire ?
(Scrum life) Parmi les ateliers que vous proposez dans vos vidéos (Delegation board, DoD Kards, Planning poker, Rôles et responsabilités…)
Dans quel ordre ?
Avec qui ?
Avec quels outils ? Jira ? Monday ?
Sans compter qu’il faut que :
je me familiarise avec le fonctionnement du produit (s’il existe déjà)
je constitue les parties prenantes « utilisateurs » (est-ce que je les constitue vraiment d’ailleurs ? Si oui, comment ?), que je prenne contact avec eux/elles voir que je les rencontre. Comment ça se passe d’ailleurs quand le produit n’existe pas encore ?
je rencontre le reste de l’équipe scrum (le SM et les developers) et que je prenne mes marques avec eux via notamment les différents ateliers cités plus haut
…
En bref, il y a tout un travail à faire avant de lancer le(s) premier(s) sprint et « démarrer » la machine Scrum. Du coup, que doit contenir le kit de survie, des premiers jours/secours, du petit PO(ucet) junior/débutant ? Autrement dit, qu’est censé faire un PO junior/débutant dans les premiers jours avant de commencer les sprints ? Avec qui ? Avec quels outils ? Quels ateliers faire ?
Autre question : (non pas que je sois impatient, mais) Combien de temps dure cette période avant de faire les premiers sprints ? Je suppose que ça varie selon le produit (sa complexité notamment), s’il est déjà créé ou s’il est « à créer », non ?
Merci par avance pour vos éclairages de vétérans
Bonne journée
P.S : ** En réalité :
demain, c’est férié
je suis toujours dans ma boite en tant que webdesigner
je suis en train de me former en tant que PO/SM, d’où mes questions parfois bêtes, aux réponses évidentes pour vous, vétérans
je n’ai pas encore cherché de boulot au poste de PO
je n’ai pas encore été embauché
mais c’est un exemple pour avoir des réponses, du feedback pour les « petits » PO(ucets) dans le même cas que moi
Ce n’est pas représentatif de ce qui se passera dans la majorité des cas. La plupart des postes ouverts concernent des produits déjà existants, et parfois il y avait déjà un PO sur le produit. Ça rend ton démarrage plus simple parce qu’il y a déjà des choses en place, les sprints sont déjà lancés, et il « suffit » de rentrer dans le moule. Tu pourras t’appuyer sur les autres POs s’il y en a, sur le Scrum Master s’il est bon, sur ton manager s’il comprend ton rôle, sur l’équipe si elle est expérimentée…
Mais je suis arrivé dans une boîte sur un produit non existant il y a ~6 mois donc je peux raconter un peu comment ça s’est passé, histoire de ne pas être dans la théorie
Au début, mon activité a été principalement de comprendre le domaine métier. Donc pas mal de lectures, et pas mal d’entretiens avec des gens en interne pour saisir à la fois ce que fait l’entreprise, comment elle se place dans son écosystème, qui sont les clients potentiels, quels sont les avantages et inconvénients de notre technologie, etc, etc.
J’ai aussi cherché à challenger la vision en place. Le but était de construire tel produit d’ici telle date, et donc je me suis demandé si c’était la bonne chose à faire. En particulier, quelle est la cible du produit, quelles sont leurs attentes et leurs besoins, est-ce que c’est bien ce produit qu’on doit leur mettre en face, pourquoi vouloir sortir à telle date, etc, etc.
Je ne crois pas avoir suivi un framework particulier pour faire ça, je me suis simplement laissé guider par ma curiosité pour bien comprendre ce qui se passe.
Quelques outils utiles que j’ai pu utiliser quand même :
Un atelier d’idéation où je présentais aux gens un profil d’utilisateur potentiel, et où je leur demandais de s’imaginer quels étaient leurs besoins et leurs difficultés, et comment on pourrait leur être utile. C’était avant d’avoir fait les entretiens réels, mais c’était plus facile à organiser, et c’était intéressant pour voir ce à quoi les gens pensent. Et surtout, une fois qu’on a fait les entretiens, ça permet de se dire « ah tiens ça on avait bien compris mais par contre ça c’était totalement faux ».
Des entretiens avec des utilisateurs potentiels, centrées sur la compréhension de leurs besoins et de leur contexte, puisque justement on n’a pas encore de produit à leur proposer. Quand j’ai commencé à avoir une idée de ce que pourrait être le produit, j’ai pas mal utilisé la technique d’écrire un faux communiqué de presse décrivant le produit potentiel, de leur faire lire et de jauger leur réaction.
Le questionnement « le produit qu’on envisage de faire est-il désirable, faisable et viable ? » : j’essayais de lister tout ce qui me faisait penser que oui, tout ce qui me faisait penser que non, et ce que j’avais besoin d’apprendre pour mieux répondre à la question
La modélisation de l’écosystème : dans mon job précédent dans l’immobilier, ça se représentait sous la forme d’un document où on listait les grandes étapes du parcours de chaque acteur d’un projet immobilier. Le locataire, l’acheteur, l’agent immo, etc. L’idée est d’avoir un langage commun pour pouvoir se dire ensuite « le but de tel produit ou de telle fonctionnalité est rendre service à telle(s) personne(s) à tel(s) moment(s) du projet ».
Le story mapping : une fois que j’ai eu suffisamment d’information et que la vision produit commençait à émerger, alors j’ai pu rassembler les gens de différentes spécialités, leur présenter les grandes étapes du parcours, et leur faire lister ce qu’on avait besoin de construire pour les rendre possibles. La story map m’a ensuite servi de base pour la constitution d’un premier backlog et d’un premier sprint.
Le questionnement constant « comment on fait pour mettre un truc entre les mains d’utilisateurs le plus vite possible ? » : surtout dans un environnement où les gens sont perfectionnistes, c’est une question à tout le temps se poser.
La période entre mon arrivée et le premier sprint a été relativement longue (~2 mois), mais c’est parce que le premier développeur de l’équipe n’était pas encore recruté, et le domaine est assez complexe donc j’avais besoin d’une bonne mise à niveau.
Tu remarqueras que j’ai assez peu parlé de Scrum ou des outils parce qu’au final ce n’est pas bien important. Il suffit de s’adapter à ce qui existe, ça rend la collaboration plus facile avec les gens qui sont déjà là et qui n’ont pas besoin d’apprendre un truc nouveau.
Au final, l’important n’est pas de respecter tel process ou d’utiliser tel outil, l’important c’est de comprendre ce qui se passe. Qu’est-ce qu’on veut faire et pourquoi on veut le faire. Et partager sa vision et ses interrogations avec les autres.
Les détails, ils varient grandement suivant le projet et le contexte. Mon contexte était particulier (pas de produit existant, pas de designer, domaine très technique), mais tous les contextes ont quelque chose de particulier :
Parfois tu seras très cadré, plein de choses seront définies pour toi et il faut « juste » faire les détails.
Parfois c’est beaucoup plus libre et il faut arriver à explorer, mais sans se perdre.
Mon exemple ci-dessus est plutôt le 2ème cas.
Bon, je ne sais pas si ça répond à la question parce que ça ne te donne pas de recette prête à appliquer, mais je ne crois pas aux recettes et j’espère que ça sera quand même un retour d’expérience utile
Bonjour
Cela fait maintenant 5 mois que j’ai intégré une entreprise en tant que Product Owner, malgré le fait que mon expérience précédente n’ait aucun lien avec le développement ou l’informatique.
Mes premiers jours/semaines ont été consacrés à la découverte de l’équipe, des projets en cours, ainsi qu’à la recherche et à la documentation. J’ai assisté à des réunions avec mon responsable pour comprendre le processus en place.
J’ai également pris le temps de lire les backlogs des projets actuels et futurs. Étant novice dans ce domaine, j’ai saisi quelques opportunités pour effectuer des recherches approfondies sur mon métier.
