Agile Tour Nantes 2011 - Dorothée le seac'h devenir product owner, c'est changer le paradigme
•Als PPT, PDF herunterladen•
6 gefällt mir•2,778 views
Une part des difficultés rencontrées dans l’adoption des méthodes agiles est liée au rôle que joue le client, et aux relations qu’il noue avec l’équipe de développement.Pourtant sa participation à la réalisation de son produit est l’un des facteurs clés de réussite du projet. Pour le client, ou son représentant, passer d’un fonctionnement classique à un mode agile n’est pas qu’une nouvelle façon de travailler, avec de nouveaux outils… Il s’agit d’un changement profond dans son rôle, dans ses relations, dans sa vision des choses. C’est un changement de paradigme. Qui demande une certaine ouverture d’esprit, une certaine remise en question, et donc du courage. Quel est le chemin à parcourir ? Quelles sont les aides sur lesquelles s’appuyer ?
![Le programme ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],Agile Tour Nantes 2011 Devenir PO, c'est changer de paradigme Agile Tour Nantes 2011 Devenir PO, c'est changer de paradigme](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Andere mochten auch
Andere mochten auch (20)
Ähnlich wie Agile Tour Nantes 2011 - Dorothée le seac'h devenir product owner, c'est changer le paradigme
Ähnlich wie Agile Tour Nantes 2011 - Dorothée le seac'h devenir product owner, c'est changer le paradigme (18)
Mehr von Association Agile Nantes
Mehr von Association Agile Nantes (20)
Agile Tour Nantes 2011 - Dorothée le seac'h devenir product owner, c'est changer le paradigme
- 1. Devenir PO, c’est changer de paradigme Dorothée Le Seac’h Agile Tour Nantes 2011
- 3. Paradigme ? Agile Tour Nantes 2011 Devenir PO, c'est changer de paradigme
- 4. Paradigme ? Agile Tour Nantes 2011 Devenir PO, c'est changer de paradigme
- 5. Changer de paradigme Agile Tour Nantes 2011 Devenir PO, c'est changer de paradigme
- 6. Changer de paradigme Agile Tour Nantes 2011 Devenir PO, c'est changer de paradigme Agile Tour Nantes 2011 Devenir PO, c'est changer de paradigme
- 7. Un Product Owner Agile Tour Nantes 2011 Devenir PO, c'est changer de paradigme
- 8. Changer d’outils, de pratiques Agile Tour Nantes 2011 Devenir PO, c'est changer de paradigme
- 9. Changer d’outils, de pratiques Agile Tour Nantes 2011 Devenir PO, c'est changer de paradigme
- 10. Apprivoiser la valeur métier Agile Tour Nantes 2011 Devenir PO, c'est changer de paradigme
- 11. Apprivoiser la valeur métier Agile Tour Nantes 2011 Devenir PO, c'est changer de paradigme
- 12. Avoir la vision produit Agile Tour Nantes 2011 Devenir PO, c'est changer de paradigme
- 14. Avoir la vision produit Agile Tour Nantes 2011 Devenir PO, c'est changer de paradigme
- 15. Suivre les règles du jeu Agile Tour Nantes 2011 Devenir PO, c'est changer de paradigme
- 16. Suivre les règles du jeu Agile Tour Nantes 2011 Devenir PO, c'est changer de paradigme
- 17. Représenter, à l’extérieur Agile Tour Nantes 2011 Devenir PO, c'est changer de paradigme
- 18. Etre chef d’orchestre Agile Tour Nantes 2011 Devenir PO, c'est changer de paradigme
- 19. Etre chef d’orchestre Agile Tour Nantes 2011 Devenir PO, c'est changer de paradigme
- 20. Etre chef d’orchestre Agile Tour Nantes 2011 Devenir PO, c'est changer de paradigme
- 21. Faire partie d’une équipe Agile Tour Nantes 2011 Devenir PO, c'est changer de paradigme
- 22. Faire partie d’une équipe Agile Tour Nantes 2011 Devenir PO, c'est changer de paradigme
- 24. Faire partie d’une équipe Agile Tour Nantes 2011 Devenir PO, c'est changer de paradigme Agile Tour Nantes 2011 Devenir PO, c'est changer de paradigme
Hinweis der Redaktion
- PO, rôle indispensable, et pourtant il est courant de voir des projets sans PO clairement défini, ou alors avec un PO absent, indisponible… Peut-être parce qu’on part de l’idée (fausse évidemment) que l’agilité, ça ne concerne que les équipes informatiques ? Je pense que bien souvent c’est parce qu’on n’a pas conscience de ce que signifie être PO, devenir PO ? Il est assez facile de trouver de l’information sur les activités d’un PO, et ses responsabilités. Mais on parle peu de la difficulté que cela peut représenter d’endosser ce rôle. Ce que j’aimerais vous démontrer aujourd’hui, c’est que devenir PO, c’est un changement « multi facettes » : c’est changer d’outils, de pratiques, de méthodes… c’est aussi changer sa façon de voir les choses. C’est pourquoi je parle de changement de paradigme.
- Qu’est-ce qu’un paradigme ? Un paradigme, c’est une façon de voir les choses. Conditionnée par le vécu, la culture, etc de chacun. On peut représenter un paradigme par une paire de lunettes, au travers desquelles on voit le monde.
- Et il existe un nombre infini de façons de voir le monde. De paires de lunettes. Changer de paradigme, c’est voir une même réalité différemment. C’est changer de lunettes. Je vais vous raconter une histoire, pour illustrer un tout petit changement de paradigme : C’est l’histoire d’un consultant, Bob, qui après un déplacement se rend à l’aéroport pour rentrer chez lui. Il a faim, alors en attendant son vol, il va s’acheter un paquet de cookies. Il s’installe sur un banc, pose ses sacs à ses pieds. A côté de lui, un autre homme attend. Bob se baisse pour attraper son paquet de cookies. L’homme à côté de lui le regarde très bizarrement. Bob ouvre le paquet, et prend un biscuit. L’homme continue de le fixer. Ce qui met mal à l’aise Bob, mais il décide de ne rien dire. Quand tout à coup l’homme plonge sa main dans le paquet de cookies, et se sert !! Bob en reste muet. Mais il se dit qu’il vaut peut-être mieux pour sa sécurité qu’il ne dise rien. Ce doit être un fou. Ils se partagent ainsi le paquet. L’heure du vol arrive. Bob récupère ses sacs pour se diriger vers la passerelle d’embarcation. C’est là qu’il se rend compte que son paquet de cookie est intact. D’un coup, Bob ne voit plus en son voisin un fou, mais un monsieur très sympa d’avoir partagé ses biscuits. Il a suffit d’un élément pour voir la même situation très différemment.
- Dans notre cas précis, qui concerne la réalisation d’un produit, la réalité ne change pas : L’objectif reste le même : le produit (ici, notre petit drapeau) Je me mets dans la situation où la personne qui connaît le besoin et qui a pour travail de le décrire reste la même : l’utilisateur, le client, la MOA, l’AMOA… Ici, notre bonhomme. Et il y a toujours une équipe qui va travailler à la réalisation du produit. Je fais une parenthèse. Selon le contexte, la personne qui va endosser le rôle de PO sera différente : le client direct (dans le cas par exemple d’une petite société qui se fait faire son site web), un opérationnel (dans le cas par exemple d’une plus grande société qui se fait faire un outil de gestion par exemple), ou parfois un assistant à maîtrise d’ouvrage (ou « chef de projet fonctionnel»). Ce qui est nécessaire, en termes de compétences : qu’il ait la connaissance métier et la légitimité. Dans ces différents contextes, on voit apparaître parfois des PO délégués, des proxys PO… Afin de pallier en général au fait que le « véritable » PO n’est pas suffisamment disponible. Evidemment ce n’est pas l’organisation idéale. Mais il faut savoir s’adapter. Et faire au mieux. Avant de fermer la parenthèse, un point important : l’équipe est un tout avec un seul et même objectif. On essaie donc de ne plus parler de MOA et MOE. Alors je ferme la parenthèse. Nous disions donc que la réalité ne change pas : même personne, même objectif, une équipe de réalisation…
- Par contre, c’est la façon de voir le chemin à parcourir pour atteindre l’objectif qui va changer. Le PO en devenir va probablement changer de lunettes. Tout d’abord, les outils changent un peu. On ne spécifie plus tout à fait de la même manière. On ne fait plus tout à fait le même reporting (encore que). Mais ce n’est pas tout. Le futur PO doit envisager son rôle dans le projet différemment. Ses relations aux autres différemment. Son engagement différemment. Ce que je vous propose, c’est de regarder ensemble ce qu’implique être PO, ses activités (rapidement), ses responsabilités, ses difficultés éventuelles, et finalement ce qui va changer en profondeur.
- Alors voilà, le rôle d’un PO est représenté ici. Et nous allons suivre le chemin à parcourir pour devenir PO…
- En général, lorsque vous devenez PO sur un projet, l’une des premières choses que l’on vous demande, c’est de réaliser un backlog du produit. De planifier les release et de gérer la roadmap. Puis de rédiger des user stories…
- Difficulté(s) Ce sont de nouvelles façons de décrire le besoin, de planifier le projet. Ce n’est pas juste de la mise en forme différente. Il ne faut pas négliger la difficulté que cela peut représenter. Ca peut déstabiliser tout le monde de changer d’outils. D’autant plus lorsque cela fait longtemps que l’on utilisait les précédents. Aide(s) : Formation initiale Accompagnement par quelqu’un au début (pour l’initialisation et les premières itérations).
- Une fois que l’on a un backlog, il faut le prioriser. C’est alors que l’on nous parle de « valeur métier ». C’est ce qui va permettre de prioriser le backlog, et donc de définir les fonctionnalités qui doivent être réalisées en premier.
- Difficulté(s) C’est une nouvelle pratique. Schématiquement, en méthode classique, on décrit l’ensemble du produit, et on essaie de le réaliser entièrement. En méthode agile, on « casse » le rocher, et on en recueille ce qui a le plus de valeur, les pépites d’or. Mais pour cela il faut réussir à les repérer. C’est là qu’on se sert de la valeur métier. Aide(s) : Prendre conscience de ce que c’est en faisant par exemple un Business Value Game. Définir le modèle de l’entreprise (grille et pondération = tamis), s’assurer qu’elle est en cohérence avec la stratégie d’entreprise. Revoir régulièrement la grille. Pour la notation, travailler de manière relative, plutôt qu’absolue. On peut organiser cela sous forme de jeu : Jeu Priority poker. Le PO a tout intérêt à se faire aider : Il lui faudra alors organiser des ateliers de priorisation avec des intervenants bien choisis (d’autres utilisateurs, la direction, le marketing…).
- Saint-Exupery a parfaitement décrit la vision, lorsqu’il a écrit :
- Difficulté(s) Lorsque l’on a un plan précis de l’endroit où on veut aller, il suffit d’une erreur ou d’une incompréhension pour se perdre. Alors qu’avec juste la notion de direction, on s’en sort. D’autant plus si on la partage. Il y a plusieurs difficultés concernant la vision. La première c’est de la définir. La seconde c’est de réussir à la partager. Et la troisième c’est de réussir à garder suffisamment de recul tout au long du projet pour ne pas l’oublier, malgré le fait que l’on soit plongé avec l’équipe dans le quotidien. Aide(s) : Pour la définir, il existe des outils sur lesquels s’appuyer : Document de vision Jeu du Product box Vision du produit en mindmap Pour la partager, je vous proposerai de la reformuler, et la rappeler dès que l’occasion de présente à l’équipe (aux bilans d’itération par exemple). Quant à la difficulté de ne pas la perdre de vue, je vous proposerai de vous créer des petits rituels personnels. Comme par exemple, avant chaque préparation d’itération, se la rappeler. Et vérifier qu’elle est toujours bonne. La confronter régulièrement à d’autres acteurs.
- Difficulté(s) Le fonctionnement (même s’il diffère un peu d’une organisation à l’autre) demande de la rigueur de la part de tout le monde. Pour le PO, cela se traduit notamment par les 2 règles suivantes : Ne rien changer durant l’itération, malgré une grande tentation parfois, LE DESSIN Accepter ou refuser, clairement, au moment de la démonstration du produit en fin d’itération, les fonctionnalités présentées. Ces 2 points sont fondamentaux. A REVOIR Sans se faire influencer par les autres. Aide(s) : Se faire une affiche avec les règles du jeu. Souvent, les développeurs ont les-leurs (on pair-programme) L’aide : le scrummaster !!
- Je passe rapidement sur ces activités, car elles sont classiques.
- En quoi est-ce nouveau ? Dans les schémas classiques, une certaine distance existe (du fait entre autre, du temps passé entre la demande et le produit fini, et du champ des possibles incompréhensions du besoin) entre la personne qui a défini le besoin et le produit fini. Et donc une déresponsabilisation. Pourquoi le PO est-il responsable du succès du produit ? Parce qu’il est un peu comme un chef d’orchestre. Lui seul a la partition entière en tête. Et son rôle est d’emmener l’équipe vers l’objectif. Le produit est notre objectif. Notre challenge : qu’il réponde au mieux au besoin. Ce challenge doit être poursuivi tous les jours, en sachant qu’il y aura des moments plus difficiles que d’autres. Les moments difficiles, ce peut être des changements ou des problèmes. Ici, je n’ai pas de baguette magique, je ne vais pas vous proposer des solutions qui répondent à toutes les situations. Par contre, je vais vous parler de 2 habitudes à prendre, et qui aident énormément, dans toute situation.
- Habitude n°1 : Pas peur des changements (changement d’octave) Ils nous rapprochent un peu plus du BON produit Proposition pour y parvenir : Lorsqu’un changement de programme intervient (changement dans une US, changement de priorité…) : En général, on commence par réagir avec agacement, ou découragement, ou même refus… Essayer de garder ces premières réactions dans notre tête, ne pas les exprimer au reste de l’équipe, car ça pourrait les perturber, les démotiver… Revenir avec recul & discernement sur le sujet, avec en tête l’idée que si ce changement de programme est légitimement demandé, c’est qu’il est nécessaire pour atteindre l’objectif. Se dire : c’est finalement une chance : une marche en plus vers le bon produit. Normalement, une fois que l’habitude est acquise, on n’a plus les réactions négatives Habitude n°2 : Pas peur des problèmes (fausse note) Leur résolution nous fait avancer un peu plus vite vers le BON produit Proposition pour y parvenir : C’est un peu la même que pour la peur des changements : Il faut essayer de mettre de côté tout ce qui est de l’ordre de l’émotionnel. Ne pas hésiter à échanger les points de vue avec d’autres personnes, pour y voir plus clair. Avoir une démarche pragmatique. Discerner les vrais problèmes des faux problèmes. Plus facile à dire qu’à faire, mais l’idée est surtout de prendre du recul sur les problèmes rencontrés. On ne peut peut-être pas traiter tous les problèmes.
- Le PO fait partie intégrante de l’équipe. Travailler en équipe est l’un des facteurs de réussite du projet. Pourtant ça n’est pas ce qui est le plus facile. Kofi Annan le dit très bien lui-même :
- ??? Ca ne s’apprend pas à l’école, mais il n’est jamais trop tard. Le coaching d’équipe aide énormément. Comme tout à l’heure je vous propose 5 idées, 5 habitudes, qui aident beaucoup.
- Certaines habitudes peuvent nous aider à XXX Habitude n°3 : L’entraide Savoir demander de l’aide (même en tant que PO) Exemple : un projet où Offrir son aide dès que possible Habitude n°4 : Chacun est différent Savoir détecter les qualités et s’appuyer dessus Exemple : Habitude n°5 : En cas de problème, On ne cherche pas les coupables mais les solutions Habitude n°6 : On ne parle pas à la place des autres Chacun parle en son nom Habitude n°7 : Ecouter Si nous avons 2 oreilles et une bouche, c’est certainement parce nous devrions écouter 2 fois que l’on ne parle. Note : atelier de Thierry Montulé, « les oreilles de l’agilité » à 16h45. Je vous ai présenté 7 habitudes, mais pour ceux à qui ça fait penser au livre de Covey sur les 7 habitudes, c’est un pur hasard. Il y en aurait certainement d’autres intéressantes… Pour approfondir le sujet : Session de Christophe Thibaut : ni gladiateurs ni bisounours, une équipe remarquable au quotidien : à 17h dans cette même salle.
- On l’a vu, devenir PO, c’est beaucoup prendre de nouvelles habitudes. Prendre une habitude, n’est pas si simple : Comme le définit Stephen Covey dans son livre des 7 habitudes, une habitude, c’est le point de rencontre de la connaissance, du savoir-faire et du désir. Pour que quelque chose devienne une habitude, il faut réunir ces trois éléments. Je prendrai l’exemple de la dernière habitude vue ensemble : écouter les autres. Avoir conscience qu’il faut écouter l’autre c’est déjà très bien. Mais si je ne sais pas comment m’y prendre pour vraiment écouter l’autre, je ne le ferai pas. Enfin, si je sais qu’il faut écouter l’autre, que je sais comment le faire, tant que je ne veux pas écouter, que je n’en éprouve pas le désir, je n’intégrerai pas cette pratique à mes habitudes. A force de travailler sur l’acquisition de nouvelles habitudes, nous nous détachons de nos anciens paradigmes. Et on change de lunettes !! Pour finir, je parlais aujourd’hui du rôle de Product Owner, parce que c’est un changement que j’ai vécu. Mais il semble raisonnable de penser que le changement de paradigme peut s’appliquer aux autres rôles d’une équipe agile !