Note : billet publié préalablement sur LinkedIn
Le Product Owner technique, est généralement un ancien développeur ou chef de projet technique.
Dans ce cas là, il est possible que ce “PO-technique” définisse les histoires en y expliquant comment réaliser la fonctionnalité.
Après tout, en tant que technicien, son expertise technique est reconnue et attendue par l’entreprise. Par sa direction même, comme pour justifier son évolution.
Il est alors important pour le Scrum Master de révéler la situation au grand jour, avant que le problème ne fasse un effet « Scrum ça marche pas pour nous ». Comme je l’explique dans mon talk Être agile, plutôt que de faire de l’agile, je n’ai jamais vu une vraie équipe Scrum échouer un projet (une bonne équipe agile échoue souvent => culture de l’échec, mais là je parle de l’échec du projet).
En décrivant comment faire, le PO technique retire la possibilité pour l’équipe de développement d’inventer, de créer, de s’approprier le produit ou la fonctionnalité. Il déresponsabilise les développeurs. Après tout, si ça ne fonctionne pas, ce n’était pas leur choix. L’équipe doit alors s’engager à livrer quelque chose qu’ils ne maîtrisent pas forcément.
Il est donc important pour le Scrum Master d’accompagner ce PO technique à devenir un PO fonctionnel. Tout cela passe par l’apprentissage, pas si simple, de l’écriture d’histoires, de découpage, etc …
Et si cela ne fonctionne pas, car n’est pas PO qui veut, ou que ce PO technique est un … “Proxi-PO technique”, il est alors préférable de retirer cette personne de l’équipe, d’aller chercher le vrai PO, de lui inculquer les enjeux de son métier et pourquoi il doit abandonner son bureau et se mêler à l’équipe. “LE PRODUIT N’EN VAUT-IL PAS LA PEINE ?” est une question à poser à la moindre contestation (voir l’excellent Scrum Life #17 de JP Lambert pour apprendre à faire les yeux tristes du Scrum Master).
PS : Toute ressemblance avec des personnes ayant réellement existé ne serait pas trop fortuite.