Aller au contenu | Aller au menu | Aller à la recherche


Keyword - Product owner

Fil des billets - Fil des commentaires

KISS me

kiss

Je vais encore avoir droit à quelques remarques sur mon titre, mais après "Perfectionne-moi", celui-ci s'imposait, pour rester dans le ton ;)

Pour beaucoup d'entre nous, le principe KISS, Keep It Simple Stupid, nous parle déjà, puisque la simplicité est l'une des valeurs de l'agilité.

Mais ça vaut le coup de la rappeler, car dans certaines situations on a vite fait de l'oublier. Et j'ai envie de préciser que cela n'est pas valable uniquement pour la partie développement. Il faut savoir rester simple dans l'organisation, dans les relations, dans l'expression.

Ainsi, le principe ne s'applique pas qu'aux développeurs, mais aussi aux product owners. Par la façon de procéder à l'expression du besoin, préconisée par les méthodes agiles (dans SCRUM notamment), au travers d'un backlog que l'on priorise, on réussit à ne faire que les fonctionnalités nécessaires aux utilisateurs. Et ainsi, on simplifie le produit. Alors que lorsque l'on doit tout spécifier dès le départ dans une expression de besoin "exhaustive", on a tendance à mettre absolument tout ce à quoi on pense, et de peur d'en oublier on s'efforce de penser à tous les cas de figure imaginables.

Mais c'est aussi dans la rédaction des user stories que le PO doit penser à faire simple. Ce qui ne veut pas dire simpliste. Je cite Einstein : Rendez les choses aussi simple que possible, mais pas plus simple. *. Il faut continuer à expliquer les règles de gestion, les règles de calcul (au travers de tests d'acceptation c'est encore mieux). Mais sans se noyer dans les explications. On pourrait d'ailleurs s'inspirer des développeurs lorsqu'ils se disent qu'une tâche estimée à plus d'une demi-journée de travail doit être redécoupée. On pourrait se dire que la description d'une user story doit tenir X lignes, ou X pages (selon votre projet), et si ce n'est pas le cas, c'est peut-être signe qu'elle peut être découpée en 2 user stories ? D'ailleurs on pourrait dire KISS = Keep It Simple and Small ! Si le coeur vous en dit, essayez !

Je ne peux pas finir sans citer Léonard, Antoine et Steve :

  • La simplicité est la sophistication suprême. Leonard de Vinci
  • La perfection est atteinte, non pas lorsqu'il n'y a plus rien à ajouter, mais lorsqu'il n'y a plus rien à retirer. Antoine de Saint-Exupéry
  • La simplicité peut être plus difficile à atteindre que la compexité : il faut travailler dur pour arriver à faire simple. Steve Jobs

* : Cette citation, lors de mon premier projet agile, je l'avais affichée au mur de notre bureau. Souvenirs, souvenirs...

Kiss, Dorothée


Devenir PO, c'est changer de paradigme - 5/5

Ce billet est la suite et fin de la série :

Rappel : Devenir PO (product owner) n'est pas anodin. C'est changer sa manière de voir les choses.
Il est intéressant de se pencher sur ce changement, au travers des difficultés éventuellement rencontrées, tout en envisageant quelques pistes d'aides et (pour les 2 dernières bulles du schéma ci-dessous) des propositions de bonnes habitudes à prendre ; le but n'est donc pas ici d'expliquer en détail les activités du product owner (comment réaliser un backlog, qu'est-ce qu'une user story, etc). Si ce sujet vous intéresse, je vous conseille le très bon livre de Claude Aubry : 'Scrum, Le guide pratique de la méthode agile la plus populaire'.

Et pour finir la série, regardons la bulle n°11.

PO_11bullesOrdonnees.JPG

Bulle n°11 : Le PO fait partie d'une équipe

equipe3.JPG 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 : « Dieu a créé le monde en 7 jours. Mais il a eu la chance de travailler seul… » Si l'on rapproche ceci du fait Kofi Annan a été secrétaire général des Nations Unies pendant 10 ans, on se dit qu'il a peut-être rencontré quelques difficultés.

Travailler en équipe ne s’apprend pas à l’école (peut-être un jour ?), mais il n’est jamais trop tard. C'est donc sur le "terrain" que l'on apprend, et alors, l'aide d'un coach d'équipe peut s'avérer précieuse.

Pour l'heure, je vous propose 5 bonnes habitudes qui aident énormément.

Habitude n°3 : Apporter et demander de l'aide

entraide.jpg Même si développeurs et PO n'ont pas le même métier, ils peuvent bien souvent s'entraider.
Un jour, PO sur un projet, je peinais à rédiger mes tests. Je voyais l'itération suivante approcher, et je sentais que les user stories n'allaient pas être prêtes. L'un des développeurs a rédigé avec moi quelques tests et on a réussi à être prêts pour l'itération suivante. On peut presque toujours trouver un moyen d'aider ou de se faire aider.

Habitude n°4 : Utiliser les qualités de chacun

differences.jpg Chacun a ses points forts ; utilisons-les au maximum. Sur l'un de mes projets, un des développeurs avait un goût particulier pour les "belles" ihm (intuitives, esthétiques). Je lui demandais régulièrement de me donner des idées, et son avis sur les écrans de l'application que nous développions. Un autre développeur de cette même équipe était un "clown", il avait toujours envie de glisser une blague dans la conversation. Il nous a été très utile pour "dégoupiller" certaines tensions.

Habitude n°5 : Chercher les solutions, pas les coupables

solution.jpg Ne serait-ce que parce que cela nous permet de gagner du temps : savoir qui a fait quoi, ça ne nous avance pas toujours. On peut faire un rapprochement avec l'idée évoquée dans un précédent billet : "Il vaut mieux enseigner les vertus que condamner les vices".



Habitude n°6 : Ne pas parler à la place des autres

boucheBarree.JPG D'une part parce que c'est toujours mieux de laisser chacun exprimer ses propres idées. D'autre part à cause du risque de l'effet "téléphone arabe".



Habitude n°7 : Écouter, écouter, écouter

ecouter.jpg Nous avons deux oreilles et une seule bouche...c'est sûrement qu'il faudrait écouter 2 fois plus qu'on ne parle !
"Je sais, ça n’a rien à voir, nous aurions pu aussi avoir, en tant qu'espèce animale, une seule oreille et deux bouches, ou six oreilles et pas de bouche, et avoir toujours cette irrépressible tendance à préférer parler qu'écouter..."
Christophe André

Devenir PO, c'est prendre de nouvelles habitudes

Finalement, devenir PO, c’est en grande partie prendre de nouvelles habitudes.
Et prendre une habitude, n’est pas si simple : comme le définit Stephen Covey dans son livre The 7 Habits of Effective People, 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. Il faut donc que je l'apprenne. Mais encore une fois ce n'est pas suffisant.En effet, 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 nous changeons de lunettes !!

Pour finir, je parle ici 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 !

Références :


Devenir PO, c'est changer de paradigme - 4/5

Ce billet est la suite des 3 précédents :

Rappel : Devenir PO (product owner) n'est pas anodin. C'est changer sa manière de voir les choses.
Il est intéressant de se pencher sur ce changement, au travers des difficultés éventuellement rencontrées, tout en envisageant quelques pistes d'aides et (pour les 2 dernières bulles du schéma ci-dessous) des propositions de bonnes habitudes à prendre ; le but n'est donc pas ici d'expliquer en détail les activités du product owner (comment réaliser un backlog, qu'est-ce qu'une user story, etc). Si ce sujet vous intéresse, je vous conseille le très bon livre de Claude Aubry : 'Scrum, Le guide pratique de la méthode agile la plus populaire'.

Aujourd'hui, intéressons-nous à la bulle n°10 !

PO_11bullesOrdonnees.JPG

Bulle n°10 : Le PO est responsable du succès du projet

Être chef d'orchestre

orchestre.jpg 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. Ne l'avez-vous pas observé ?

Pourquoi le PO est-il responsable du succès du produit (et donc de son échec) ?
Parce qu'il a la vision en tête, et donne donc la direction à suivre au reste de l'équipe. C'est en cela que je compare le PO à un chef d'orchestre. Et bien entendu, "chef d'orchestre" doit être compris ici comme "celui qui donne la direction" et non comme "celui qui commande". Seul le PO a la partition entière en tête. Et son rôle est d’emmener l’équipe de manière à ce que la musique sonne bien. C'est là que se situe la responsabilité du PO dans le résultat du projet.

L'équipe entière est bien entendue responsable du succès ou de l'échec du produit, puisqu'il est le fruit de son travail. La responsabilité du PO n'est pas plus grande, mais différente pour les raisons citées plus haut.

Ce qui peut aider : Assumer cette responsabilité peut être une difficulté en soit. C'est bien connu, il est nettement plus facile d'assumer le fruit de son travail lorsque l'on fait de son mieux, et que l'on se donne les moyens. Obtenir un produit répondant au mieux au besoin est un challenge. Pour moi, se donner les moyens de remporter le challenge, passe par l'acquisition des 2 bonnes habitudes suivantes.

Habitude n°1 : Accueillir favorablement le changement

Il nous rapproche un peu plus du BON produit.

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…
  • Je vous conseille d'essayer de garder ces premières réactions dans votre tête, ne pas les exprimer au reste de l’équipe, car cela pourrait les perturber, les démotiver…
  • Revenez ensuite avec recul et 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.
  • Dites-vous que c’est finalement une chance : un pas de plus vers le bon produit.
  • Normalement, une fois que l’habitude est acquise, on n’a plus les réactions négatives... Autant d'ondes négatives en moins !

Habitude n°2 : Ne pas avoir peur des problèmes

Leur résolution nous fait avancer un peu plus vers le BON produit.

C’est un peu la même idée que pour la peur des changements :

  • Il faut essayer de mettre de côté tout ce qui est "réactions négatives".
  • Je vous conseille ici de ne pas hésiter à échanger avec d’autres personnes, pour confronter les différents points de vue.
  • Veillez à garder un certain recul, de manière à distinguer les vrais problèmes des faux problèmes.
  • Décidez, avec le reste de l'équipe, d'une action ou d'un plan d'actions à mettre en œuvre (avec échéance, et suivi),
  • Essayez de rester pragmatique on ne peut pas traiter tous les problèmes à la fois.

Accepter les changements et résoudre les problèmes, dans une optique d'amélioration continue, fait que l'on travaille en donnant toutes les chances au projet d'atteindre son but. Le résultat obtenu est le fruit de nos efforts : c'est en cela que nous en sommes complètement responsable.
Bien entendu, ces 2 habitudes sont utiles à l'ensemble des intervenants sur le sujet !

Dans le dernier billet de la série, nous finirons par la bulle 11, et ce sera l'occasion pour moi de proposer 5 bonnes habitudes à prendre, qui me semblent fondamentales lorsque l'on tient le rôle de PO.
A bientôt !


Merci à Roman Pichler, dont le billet "The Product Owner on One Page" m'a inspirée pour le schéma du "PO en 11 bulles".


Devenir PO, c'est changer de paradigme - 3/5

Ce billet est la suite des 2 précédents :

Rappel : Devenir PO (product owner) n'est pas anodin. C'est changer sa manière de voir les choses.
Il est intéressant de se pencher sur ce changement, au travers des difficultés éventuellement rencontrées, tout en envisageant quelques pistes d'aides et (pour les 2 dernières bulles du schéma ci-dessous) des propositions de bonnes habitudes à prendre ; le but n'est donc pas ici d'expliquer en détail les activités du product owner (comment réaliser un backlog, qu'est-ce qu'une user story, etc). Si ce sujet vous intéresse, je vous conseille le très bon livre de Claude Aubry : 'Scrum, Le guide pratique de la méthode agile la plus populaire'.

Pour continuer la série, aujourd'hui nous regardons de plus près les bulles 5, 6 et 7.

PO_11bullesOrdonnees.JPG

Bulle n°5 : Le PO détient et partage la vision produit

Avoir la vision... produit

Antoine de Saint-Exupéry a parfaitement décrit la vision, lorsqu’il a écrit : "Si tu veux construire un bateau, ne rassemble pas tes hommes et femmes pour leur donner des ordres, pour expliquer chaque détail, pour leur dire où trouver chaque chose... Si tu veux construire un bateau, fais naître dans le cœur de tes hommes et femmes le désir de la mer."
vision3.jpg Lorsque l’on a un plan précis de l’endroit où l'on veut aller, il suffit d’une erreur dans le plan, ou d’une incompréhension de celui-ci pour se perdre. Alors qu’avec la notion de direction uniquement, on arrive au but. En effet, tant qu'on est dans la bonne direction, et qu'on avance vers l'objectif, on s'approche de plus en plus du but. Avoir la vision de ce que doit être le produit donne la direction à suivre. Et cette vision est un facteur de motivation très important pour l'équipe. Lorsque l'équipe a la vision en tête, elle sait quel est son objectif, son "challenge".
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, bien que, en tant que PO, l’on soit plongé avec l’équipe dans le quotidien.

Ce qui peut aider :

  • 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 proposerais de la formuler de différentes manières, et la rappeler à l'équipe dès que l’occasion se présente (aux bilans d’itération par exemple).
  • Quant à la difficulté de ne pas la perdre de vue, je vous proposerais de vous créer de petits rituels personnels. Comme par exemple, avant chaque préparation d’itération, se la rappeler. Et vérifier qu’elle est toujours bonne, en la confrontant régulièrement à d’autres acteurs.

Bulles n°6 et 7 : Le PO ne change rien durant l'itération, et accepte ou refuse le travail réalisé

Suivre les règles du jeu

regles1.jpg Le fonctionnement en mode agile (même s’il diffère d’une organisation à l’autre) demande de la rigueur de la part de tout le monde. Il existe notamment deux règles particulièrement importantes. La première est le fait de ne rien changer durant l’itération. Et cela malgré une grande tentation parfois. La seconde est la responsabilité d'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.

Ce qui peut aider :

  • Se faire une affiche avec les règles du jeu. Souvent, les développeurs ont les-leurs, pourquoi pas les PO ?
  • Le ScrumMaster !! En effet, son rôle est entre autres choses, de s'assurer que l'équipe respecte les principes de fonctionnement qu'elle s'est définis.

Bulles n°8 et 9 : Le PO collabore avec les parties prenantes et communique à l'extérieur, promeut le projet

Représenter, à l'extétieur

Que l'on soit en mode agile ou non, ces activités restent les mêmes.

La prochaine fois, nous aborderons la bulle 10, et ce sera l'occasion pour moi de proposer 2 bonnes habitudes à prendre, qui me semblent fondamentales lorsque l'on tient le rôle de PO.
A bientôt !


Merci à Roman Pichler, dont le billet "The Product Owner on One Page" m'a inspirée pour le schéma du "PO en 11 bulles".


Devenir PO, c'est changer de paradigme - 2/5

Ce billet est la suite de celui-ci.

Devenir PO (product owner) n'est pas anodin. C'est changer sa manière de voir les choses.
Il est intéressant de se pencher sur ce changement, au travers des difficultés éventuellement rencontrées, tout en envisageant quelques pistes d'aides et (pour les 2 dernières bulles du schéma ci-dessous) des propositions de bonnes habitudes à prendre ; le but n'est donc pas ici d'expliquer en détail les activités du product owner (comment réaliser un backlog, qu'est-ce qu'une user story, etc). Si ce sujet vous intéresse, je vous conseille le très bon livre de Claude Aubry : 'Scrum, Le guide pratique de la méthode agile la plus populaire'.

Aujourd'hui je vous propose de regarder de plus près les 4 premières bulles du "Product Owner en 11 bulles".

PO_11bullesOrdonnees.JPG

Bulles n°1, 2 et 3 : Le PO crée et maintient le backlog produit - planifie les releases et gère la roadmap - rédige les user stories et les tests d'acceptations

Changer de pratiques, d'outils

outil3.jpg L'agilité, c'est avant tout des valeurs, et des principes. Mais ceux-ci se traduisent par des pratiques - adaptées à chaque contexte - et l'utilisation d'outils.
Scrum préconise ainsi au PO de créer et gérer le backlog produit (bulle n°1), de planifier les releases (bulle n°2), de décrire les user stories (bulle n°3). Ce sont de nouvelles façons de décrire le besoin et de planifier le projet. Ce n’est pas "juste" de la mise en forme différente : ces pratiques et outils reflètent une façon d'aborder le besoin différemment. Et il ne faut pas négliger la difficulté que cela peut représenter d'appréhender ces nouvelles pratiques. Cela peut déstabiliser tout le monde de changer sa façon de travailler, et cela d’autant plus lorsque cela fait longtemps que l’on travaillait d'une manière différente.

Ce qui peut aider :
Ces nouvelles pratiques et outils méritent un apprentissage, que l'on pourra trouver dans :

  • Une formation initiale "spécifique PO",
  • Un accompagnement par un PO confirmé (et pédagogue, tant qu'à faire ;)) ou un coach agile (au moins pour l’initialisation et les premières itérations).

Bulle n°4 : Le PO priorise et re-priorise le backlog produit

Apprivoiser la valeur métier

valeur3.JPG En mode agile, on commence par réaliser ce qui a le plus de "valeur métier" : ce qui apporte le plus aux utilisateurs. Schématiquement, en méthode classique, on décrit l’ensemble du produit, et on essaie de le réaliser entièrement (dans l'illustration, le gros rocher sur le dos du bonhomme fatigué). En méthode agile, on « casse » le rocher, et on en recueille ce qui a le plus de valeur (les pépites d’or, dans l'illustration). Mais pour cela il faut réussir à les repérer ! C’est en cela qu'est utile la valeur métier. Pour savoir ce qui apporte le plus de valeur métier parmi tous les items du backlog, il faut attribuer une note à chaque item et ainsi "prioriser" le backlog.
Il s'agit encore une fois d'une nouvelle pratique, qui nécessite de bien appréhender ce qu'est la valeur métier, dans son propre contexte.

Ce qui peut aider :

  • Tout d'abord, commencer par prendre conscience de ce qu'est la notion de valeur métier, en faisant par exemple un Business Value Game,
  • Ensuite, dans la mesure où la valeur métier a un sens différent d'un contexte à l'autre (ce qui est important pour le client X ne l'est pas forcément pour le client Y), il est bon de définir le modèle de l’entreprise (grille et pondération = tamis), et s’assurer qu’elle est en cohérence avec la stratégie d’entreprise.
  • Il est important de revoir régulièrement la grille, d'autant plus dans un contexte "changeant".
  • Une fois que l'on a cette "grille" (qui peut parfois être très simple) il s'agit de noter les items du backlog ! Pour cela, il est beaucoup plus facile de travailler de manière relative, plutôt qu’absolue.
  • 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…). Il existe d'ailleurs un jeu, qui peut aider : le priority poker (je ne l'ai pas encore testé, mais j'y compte bien).


La prochaine fois, nous aborderons les bulles 5, 6 & 7.
A bientôt !


Merci à Roman Pichler, dont le billet "The Product Owner on One Page" m'a inspirée pour le schéma du "PO en 11 bulles".


Devenir PO, c'est changer de paradigme - 1/5

Devenir PO (Product Owner), c’est un changement « multi-facettes » : c’est changer d’outils, de pratiques, de méthodes… c’est aussi - et surtout - changer sa façon de voir les choses.
C'est en cela que s'opère chez la personne qui devient PO, me semble-t-il, un changement de paradigme. Et c'est cette idée que je souhaite développer dans les jours à venir au travers de 5 billets :

  • Aujourd'hui : qu'est ce qu'un paradigme,
  • Bulles 1 à 4 du dessin ci-dessous : difficultés et aides
  • Bulles 5 à 9 : difficultés et aides
  • Bulle 10 : difficultés et 2 bonnes habitudes à prendre
  • Bulle 11 : difficultés et 5 bonnes habitudes à prendre

PO_11bullesOrdonnees.JPG

Paradigme et Changement de paradigme

Qu'est-ce qu'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. lunettes.jpg Et il existe un nombre infini de façons de voir le monde. De paires de lunettes.

Mais alors, un changement de paradigme, c'est...

... Changer de lunettes, oui ! Changer de paradigme, c’est voir une même réalité différemment.
La réalité dont il est question ici, ce sont les projets de réalisation de produit logiciel. Et que l'on soit en méthode classique ou en mode agile, l'objectif d'un tel projet reste le même : réaliser le produit répondant au mieux au besoin (représenté dans l'illustration par le petit drapeau). Plaçons-nous dans l'hypothèse où le PO en devenir (le bonhomme souriant de l'illustration) est un utilisateur, le client, ou un assistant à maîtrise d'ouvrage (AMOA). Cette personne connaît le besoin, doit le décrire et sait effectuer ce travail de manière 'classique' (non agile).

realiteChangePas.jpg

Si l'objectif reste le même, c’est la façon de voir le chemin à parcourir pour atteindre celui-ci qui va changer. Le PO en devenir va probablement changer de lunettes. realite1.jpg Ce changement s'explique bien entendu par le fait que les spécifications ne s'effectuent plus tout à fait de la même manière, que le reporting n'est plus tout à fait le même.

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.

En épousant, comme le reste de l'équipe, les principes et les valeurs de l'agilité.

Le schéma du "Product Owner en 11 bulles" représente le rôle du PO. Je vous propose, dans les billets à venir, de parcourir ces bulles, d'aborder les difficultés auxquelles un PO en devenir sera confronté, et d'évoquer les aides sur lesquelles il est possible de s'appuyer. Ce sera l'occasion de comprendre en quoi devenir PO c'est changer de paradigme.

A venir, donc :
11 bulles, les difficultés auxquelles se préparer via des propositions d'aide et surtout 7 bonnes habitudes à prendre.

A bientôt !!


Merci à Roman Pichler, dont le billet "The Product Owner on One Page" m'a inspirée pour le schéma du "PO en 11 bulles".


Priority poker

Je suis une lectrice régulière du blog de Claude Aubry, 'Scrum, Agilité ... et Rock'n roll'

C'est ainsi que j'ai découvert le 'Priority poker'.

La priorisation des besoins est toujours difficile, et cela d'autant plus pour les "nouveaux" PO. Dans les ateliers de priorisation que j'organise, il m'arrive régulièrement de faire différentes propositions aux participants, avec les scénarios (planification de livraison des fonctionnalités) qui s'ensuivent. Cela a pour effet de leur faire prendre conscience de l'importance de cette tâche, et cela lance les échanges entre les intervenants.

Mais je me demande toujours dans quelle mesure mes propositions orientent les choix des clients.

Le priority poker est une manière de faire prioriser autrement.

J'ai donc prévu de le mettre en pratique à la prochaine occasion. Et bien sûr d'en tirer mes conclusions ici !

Pour lire le billet de Claude Aubry, c'est ici.