Ayant rejoint Pyxis Suisse depuis quelques mois, j’ai eu l’occasion de participer aux formations données par mes collègues. Après quatre ans en tant que Scrum Master et possédant les certifications CSM, CSP et CSD, était-il vraiment utile pour moi de suivre la formation Professional Scrum Product Owner de Scrum.org ?

Quatre années d’expérience suffisent pour que tout soit bien compris et intégré, il n’y a pas de doute… Et pourtant, j’ai été très surprise de découvrir à quel point cela a été essentiel pour moi de revoir les bases, de tordre le cou à certaines fausses vérités et surtout de pouvoir aller plus loin dans mon questionnement grâce à mon expérience et mon vécu.

J’aimerais vous présenter ici quelques éléments qui m’ont surpris, que j’avais oubliés ou qui ont changé.

Le Product Owner

J’ai eu l’occasion de croiser des Product Owners aux personnalités bien différentes :

  • Le visionnaire : il avait toujours de nouvelles fonctionnalités à implémenter, n’était pas très intéressé par le présent et ce qui était implémenté. « J’ai une nouvelle super fonctionnalité à vous proposer… je n’ai pas le temps de valider ce qui vient d’être fait. »
  • Le chef de projet : il vérifiait si les développeurs passaient bien le temps planifié sur les fonctionnalités. « Pourquoi ça a pris plus de temps que prévu ? Il faudrait passer moins de temps en réunion, plus de temps à coder. »
  • Le technicien : ancien développeur, il était orienté solution et tout avait tendance à être simple. « Vous verrez, c’est très simple. Il faut seulement 1 jour de développement. »

Ma vision du Product Owner était au final assez partielle et je me basais principalement sur les expériences que j’avais eues pour définir les contours du rôle. Par contre, je concevais déjà, et je conçois toujours qu’il s’agit d’un rôle difficile et délicat.

Dans le guide Scrum, le rôle de Product Owner me semble celui qui reste le plus flou. On peut d’ailleurs y lire : « La façon de jouer ce rôle peut varier grandement selon les organisations, les équipes Scrum et les individus. »

Lors de la formation, j’ai pris conscience à quel point le rôle de Product Owner peut être large et ambitieux. Il peut être un entrepreneur au sein de l’entreprise. Dans l’idéal, il devrait avoir le pouvoir et le leadership pour cela : croire en son produit et mettre tout en œuvre pour le bien de celui-ci. On parle bien d’un Product Owner et non pas d’un Project Owner : il sera le garant du produit à long terme et ne l’abandonnera pas lorsqu’il partira en production.

La revue… cet événement qui avait perdu son sens

Après des années à essayer sans succès d’avoir la présence des parties prenantes lors de la revue, je me suis rendu compte que finalement j’en avais oublié le but initial.

La revue n’est pas qu’une démo. Ce n’est pas une séance de validation entre l’équipe de développement et le PO. La revue, c’est la manière prévue et officielle du guide Scrum pour recevoir du feedback des parties prenantes et pouvoir présenter le backlog à venir et l’ajuster si besoin.

Aujourd’hui, je suis heureuse de pouvoir retrouver un sens à cette réunion et d’en voir les bienfaits. Quel plaisir cela a été au retour de la formation de proposer à un Product Owner de partager le backlog à venir… pour découvrir, grâce aux parties prenantes présentes à la réunion, qu’une des story qu’il avait planifié comme prioritaire était en fait complètement obsolète.

Le nouvel écueil auquel je fais maintenant face depuis que les parties prenantes sont bien là est d’éviter que la revue ne devienne une réunion de « statut d’avancement » au sens classique où l’équipe de développement risque de se faire taper sur les doigts. L’esprit participatif et le feedback constructif doivent être rappelés à chaque instant. Peu à peu le changement s’effectue.

Ne me parlez plus d’engagement

Lors de la planification du sprint, je demandais à l’équipe : « Est-ce que vous êtes confiant ? Est-ce que vous vous engagez quant aux éléments du backlog prévus dans le sprint ? »

J’ai appris qu’on ne parlait plus d’engagement (commitment en anglais), mais de prévision, de forecast. Le terme « engagement » était trop plein d’exactitude et ne faisait plus sens avec des estimations. D’ailleurs, combien d’entre nous ont un jour été confrontés quant à la justesse de leurs estimations ?

— « Je ne comprends pas, tu m’avais pourtant dit que ça allait durer 10 jours… »

— « Non, non, j’avais dit que j’estimais cela à 10 jours… »

En modifiant le vocabulaire, d’engagement à prévision, le guide Scrum essaie de mettre l’accent sur la zone d’incertitude. À titre personnel, je ne sais pas si cela a l’effet désiré, mais il est vrai que changer de vocabulaire permet de remettre certaines idées préconçues en question.

Ce ne sont que trois exemples de ce que j’ai réappris durant la formation Professional Scrum Product Owner. J’y ai donc trouvé beaucoup de valeur. De là à dire que cette formation a été une révélation grâce aux qualités pédagogiques et à l’expérience de mon collègue Tremeur qui était le formateur, il n’y a qu’un pas…

Billet précédent

Tension dans les équipes Agiles : Parties prenantes et rétroaction

Billet suivant

Vas-y, lance-toi!

Sabrina Ferlisi

Pas de commentaire

Laissez un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *