Qu’est ce qui se passe ? Tu as un Product Owner tout puissant, il n’est pas à sa place !
Pas à sa place ? Pourtant je l’ai vu ce matin dans son bureau ! Que veux-tu dire ? Comment ça mon j’ai un product owner tout puissant ??
Oui oui je l’ai vu moi aussi. Ce que je veux dire c’est que ton Product Owner parasite la Dev Team au lieu de l’aider. Je comprends que c’est un ancien chef de projet et il aime maîtriser les choses. Il a l’habitude de piloter les équipes et du coup jusqu’à présent il n’est pas à sa place. Je pense que c’est parce que le Scrum Master n’est pas assez présent. Il n’est peut-être pas assez à sa place lui aussi, il ne remplit pas ses fonctions. Le Product Owner n’a pas l’appui nécessaire du Scrum Master, ne le voyant pas il a fini par prendre son rôle.
Le PO fait partie de la Scrum Team
L’autre hypothèse est que ton Product Owner tout puissant ne s’est pas intégré à l’équipe, peut-être ne le veut-il pas, peut-être n’a-t-il pas l’impression d’en faire partie. Il est probable que cela soit dû à son ancien rôle, à son statut hiérarchique. Le Product Owner pense que son rôle n’a rien à voir avec les autres rôles de l’équipe.
Si on reprend les bases de SCRUM, la Scrum Team est composée du Product Owner, du Scrum Master et de la Development Team. La Scrum team ne peut pas fonctionner si chacun travaille dans son coin. Ce n’est plus alors une Team et il sera difficile d’appliquer les 3 piliers de SCRUM : la Transparence, l’Inspection et l’Adaptation.
Un Product Owner en dehors de l’équipe, pas impliqué, ne sera pas assez disponible pour elle et ne pourra pas travailler de concert dans la construction du produit. Un Product Owner qui n’est pas assez disponible ne pourra pas construire la vision, la partager avec la scrum team, rédiger des user stories “ready” avec les bons critères d’acceptations. Pour aller plus loin, ces problématiques ont été abordées dans un article précédent : “Que se passe-t-il si le Product Owner n’est pas suffisamment disponible ?”
Le PO ne peut pas aussi être Scrum Master.
Si le Scrum Master n’est pas assez présent ou que le Product Owner tout puissant s’impose plus naturellement sans laisser de place au Scrum Master, alors le Product Owner va petit à petit finir par prendre la place du Scrum Master. Ce qui va provoquer quelques conflits internes au Product Owner. Même s’il en a conscience, et externe (à la Scrum Team) quoi qu’il en soit. D’un côté il est un Scrum Master qui est censé protéger l’équipe et de l’autre il est un Product Owner qui cherche à tout prix à faire avancer son produit. Si le Product Owner n’écoute pas sa petite voix de Scrum Master, il va pousser l’équipe à prendre plus de travail qu’elle ne peut pour le sprint. Le Product Owner va finalement prendre un rôle très actif au sein de l’équipe. Il va être tenté de la contrôler, voire de la manipuler.
Il pourra aller jusqu’à vérifier qui fait quoi pendant le sprint, en s’aidant du sprint backlog et contrôlant qui est associé à quelle tâche.
Le Product Owner ne s’est peut-être pas rendu compte qu’il était en train de prendre le rôle de Scrum Master. Il ne sait peut-être plus ce qu’il est, il ne sait plus distinguer ce qui est du rôle du Product Owner et du rôle du Scrum Master.
Product owner tout puissant pas intégré dans l’équipe
Quant au Product Owner qui ne s’intègre pas à l’équipe, il s’est peut-être désintégré par ce qu’il n’est ni Product Owner ni Scrum Master. Peut-être aussi parce qu’il est les 2 du fait de l’historique de sa position hiérarchique. Les conséquences au niveau de l’équipe sont très importantes et vont casser la coopération, qui manquera à coup sûr, voir n’existera pas du tout.
Le Scrum Master et le Product Owner doivent bien comprendre leur rôle. Si cela ne se passe pas bien, il est peut-être nécessaire de les former. Si le Scrum Master n’est pas suffisamment présent, peut-être suit-il plusieurs équipes, refaisons alors le point avec lui. Il est peut-être plus réaliste de se concentrer sur 1 équipe dans un 1er temps. Surtout si le produit est gros. Peut-être est-ce aussi un développeur à qui on a donné le rôle de Scrum Master. Alors qu’il ne le souhaitait pas vraiment. Peut-être que par-dessus tout, ce qu’il préfère c’est coder ! Alors laissons le coder, laissons au gens la possibilité de faire ce qu’ils aiment, ne leur imposons pas des rôles dont ils ne veulent pas et qui ne les motivent pas.
Et si le Scrum Master et le PO travaillaient ensemble ?
Pour éviter ce genre d’écueil, le Product Owner et le Scrum Master peuvent se mentorer, relire le scrum guide et faire le point sur leurs pratiques.
Le Scrum Master doit être disponible. Il doit protéger l’équipe et aider le Product Owner à adopter son rôle. Le Scrum Master est le garant de SCRUM. Le Product Owner est responsable de la vision. Le PO travaille sur le QUOI et le Scrum Master avec la Dev Team sur le COMMENT.
Il est nécessaire de rappeler au Product Owner qu’il fait partie de l’équipe. Que sans lui, il n’y a pas de scrum team, pas de vision, pas de coopération. Sans tous ces éléments, la dev team et plus largement la Scrum Team ne sera pas capable de livrer de la valeur. Et ne livrera peut-être rien du tout. L’historique des positions hiérarchique peut poser problème si elles continuent à être vue comme tel. En effet la posture du Product Owner et l’assertivité de l’équipe par rapport à cet historique peut-être un frein. L’équipe comme le Product Owner doivent changer leurs croyances.
Il y a peu de rôle dans SCRUM, respectons-les, n’essayons pas de les mélanger. Malheureusement remplir le rôle de Scrum Master et de Product Owner en même temps est un mauvais mélange. Encore plus si l’un et l’autre ne savent pas ce qu’ils font. Pour éviter de faire les mêmes erreurs que d’autres, commençons par comprendre SCRUM. Appliquons-le tel qu’il est avant de le triturer.
