mardi 12 mars 2013

PO stratégique / PO opérationnel

Je rebondis sur le très bon article d'Alexandre Boutin sur le rôle du Product Owner .

Pour qu'un projet agile réussisse, il faut que le Product Owner tienne son rôle.
Et pour que le Product Owner tienne son rôle il faut :
- qu'il soit suffisamment disponible pour l'équipe
- qu'il ait le mandat pour prioriser le backlog produit

C'est malheureusement une situation idéale que j'ai rarement trouvée sur les projets.

Le problème vient en général du fait que les personnes de l’organisation qui ont vraiment le mandat suffisant pour décider seul des priorités (sans demander à sa ligne hiérarchique) n’ont souvent pas le temps de s’impliquer plus que quelques heures par semaine. C’est vraiment insuffisant pour bien tenir son rôle de PO…

Dans ces cas-là, je conseille la mise en place d’un PO « stratégique » et d’un ou plusieurs PO « opérationnels ».
Les PO opérationnels sont dans l’équipe et sont en relation fréquente avec le PO stratégique. Le PO stratégique partage la vision produit avec les PO opérationnels, valide les propositions de macro user stories (epics) et de priorisation macro des PO opérationnels. Les PO opérationnels ont en charge le grooming du backlog, la rédaction des tests d’acceptance, la recette du produit, bref, les tâches quotidiennes dont le PO est responsable.

Certains parlent de proxy PO, mais je n’aime pas ce terme. Un proxy protège l'intérieur de l'extérieur, il agit comme une frontière, une barrière. Et l'équipe ne doit pas être protégée du PO stratégique, car, tout simplement, il fait partie de l'équipe !  Le PO stratégique et l’équipe doivent garder des occasions de se rencontrer et d’échanger, par exemple les démos.

 Qu’en pensez vous ?

mercredi 6 mars 2013

Entretenez la flemme !

En ce moment, je coache un PO dont c'est le premier projet agile, et même le premier projet informatique. On peut dire que c'est un dépucelage pour lui, et pour l'instant, il est ravi ;-) J'adore ça, parce qu'il amène beaucoup de fraîcheur dans mes réflexions sur l'agilité.
Il m'a récemment montré un avantage de la spécification par les tests que je n'avais pas encore perçu.

J'étais en train de relire une user story qu'il avait écrite. Il s'agissait de gérer un élément d'information simple, en texte libre. Je lui fais remarquer qu'il n'a prévu que les fonctions d'ajout et de suppression, mais pas de modification. Sa réponse m'a amusée et m'a fait réfléchir : "Ah oui, c'est vrai, tiens... Mais ça veut dire qu'il faut que j'écrive la règle de gestion et les tests qui vont avec ??? Franchement, on peut s'en passer, de la modification. Si on veut modifier, on supprimera puis on ajoutera !".
Il faut dire que mon PO sera un utilisateur de l'application que nous développons, donc il connaît parfaitement le fonctionnel et il est bien conscient que les autres utilisateurs se tourneront vers lui s'ils estiment que le logiciel n'est pas assez pratique. J'en déduis donc que cette fonctionnalité n'est réellement pas prioritaire. Hop, affaire réglée :-)

Conclusion : en faisant écrire les tests d'acceptance au PO, on lui donne un moyen très concret d'appréhender la complexité d'une user story, et du coup, il est bien plus aisé pour lui d'évaluer le ROI d'une user story. Il y a du lean là-dedans, il me semble...

Oups, I did it again !

Cette année, Agile Games France a eu lieu en février (oui, j'ai pris le temps pour écrire mon compte-rendu...). Pour éviter d'avoir trop froid, les participants ont migré en Avignon pour deux jours que beaucoup ont qualifiés de "magiques" :
Voici ce que j'ai particulièrement apprécié :
  • Avoir contribué à l'élaboration d'un jeu avec Émilie Franchomme et Caroline Damour-nobi (je vous en dirai plus quand on sera au point)
  • Avoir découvert Agile oops !, un jeu façon Taboo ou Time's up (au choix) pour faire deviner des termes liés à l'agilité. J'ai uniquement joué à la variante Time's up (mime), et j'ai A-DO-RÉ !!!
  • Être tombée dans la crevasse pour mieux comment comprendre comment la traverser, et vérifier que la confiance en soi, en l'équipe et en la technique permettent de dépasser ses limites
  • Avoir joué dans le train, à l'aller comme au retour, ainsi qu'à l'hôtel, le jeudi soir et le vendredi soir, à des jeux "pas sérieux" avec mention spéciale à Cédric, Jean-Pierre, Isabelle, Yann et Rémy pour avoir joué dans le TGV, dans des conditions pas faciles
  • Avoir une épiphanie quand Alex a dit "mais s'il vous a manqué quelque chose, pourquoi vous ne l'avez pas mis en place ???? On est auto-organisés, on a dit !!!". Ça a été ma révélation de l'année : chacun a le pouvoir, et même le devoir de proposer les améliorations possibles et de commencer à les mettre en œuvre dès le moment où il s'en rend compte. C'est quand même vachement plus efficace que d'en parler après en disant : "si seulement "on" (notez l'indéfini) avait fait ça...". Bref, merci beaucoup Alex pour ce cadeau !
Ce qui est sûr, c'est que j'y retourne l'année prochaine (mince, faut attendre 1 an !!!!)