S’il y a un rôle déterminant dans la méthodologie Agile, c’est celui de Product Owner. Il doit être présent et à disposition de l’Equipe, prioriser, spécifier et valider les stories. Tout ceci dans un laps de temps d’une itération. Son implication et sa capacité à alimenter l’Equipe sont les facteurs majeurs de réussite du projet.

Dans ces conditions, doit-il se consacrer à 100 % à son projet ou peut-il être multi projets? Et dans ce cas, comment être multi taches ?

Au cours d’une précédente expérience professionnelle, j’ai appris à pratiquer la méthodologie Agile. Pour débuter, j’étais Product Owner d’une application à développer « from scratch ». Je me suis consacré à ce projet à 100 % pendant une durée de 9 mois environ avant de devoir prendre dans mon escarcelle d’autres projets en cours, orphelins de PO.

Cette phase d’apprentissage a fait ressortir quelques points :

  • le PO a au moins une itération d’avance de spécification sur l’Equipe ;
  • il doit toujours avoir à l’esprit la vision et la version de son produit à livrer et le partager avec l’Equipe ;
  • plus il teste l’application tôt (si possible dès la livraison de la fonctionnalité), moins il a à gérer les retours.

Learning

L’augmentation du volume de mon portefeuille projets m’a amené à travailler de la façon suivante :

  • constituer une équipe de « Product Owners »
  • de ce fait, déléguer un certains nombres de taches (par exemple écriture des cas de test)
  • au fil de l’eau, se désengager des projets « qui roulent »

Pour se faire, j’ai recruté un analyste, pour qui le métier était inconnu, mais avec un esprit clair, ouvert et vif. Je l’ai formé sur le « projet qui roule » en méthode Agile :

  • Au début de chaque itération, je spécifie les règles de gestion métier, les cas de test à la marge. Il se charge alors d’établir les cas de test ;
  • Nous itérons également sur un passage de connaissance métier lié au différentes stories à traiter.
  • Il participe aux ateliers de travail utilisateurs afin de s’imprégner de leur vision, de leurs besoins et d’un langage métier.
  • Petit à petit, il prend en charge la recette des fonctionnalités livrées par l’Equipe.

A ce stade, je reste encore le PO, mais nous entrons dans une phase où nous pouvons être considérés comme backup l’un de l’autre. Les seules différences entre nous deux sont :

  • Une connaissance métier plus approfondie due à mon passif (difficile à changer…) ;
  • Je suis interne et il est externe. Mais est-ce une condition nécessaire pour être PO ? A priori non dès l’instant où il peut s’appuyer sur une MOA interne à forte disponibilité.

remise_diplome.jpg

Etant donné cet état de fait, je me positionne désormais en backup et le nomme PO du projet. Il le prend dorénavant en charge de bout en bout, et sait qu’il peut compter sur moi en cas de besoin.

Ce cycle de formation à la méthode, passage de connaissances métier et endossement de la cape de PO a pris environ 3 mois.

Il est évident qu’il s’agit d’une charge de travail supplémentaire, mais étant donné qu’il a pu monter en compétence rapidement sur la rédaction des cas de test (Fitnesse) et recetter les stories, c’était aussi une charge de travail en moins. La constitution d’une équipe PO s’est avérée comme étant une stratégie payante. Il faut cependant être très claire en termes de communication vis-à-vis de l’Equipe (qui est le PO référent ?) et savoir se coordonner précisément sur les fonctionnalités à embarquer.

26/05/2010 - Thierry TREPIED Directeur de projets – Coach Agile SFEIR Groupe