Product NOwner: Je dis non donc je suis…

 In Entreprise agile, Project Management

Mr No est product Owner. Il a sa propre vision du produit et essaye de la transmettre à l’équipe dév.
Il n’a pas toujours toutes les réponses mais il sait déjà pourquoi on construit le produit, quels problèmes il va résoudre et surtout pour qui.
Chaque question a une réponse différente dépendamment du produit mais pour lui l’objectif reste le même : développer un produit que les utilisateurs vont aimer.
D’ailleurs il ne jure que par les vertus du « customer centric mindset » et ne croit qu’un seul KPI à savoir le CLI* : Customer Love Index.

 Le principal facteur clé de succès du rôle Product Owner, à mon sens, est la combinaison de la profonde connaissance et compréhension du client d’une part et de l’approche technologique et méthodologique d’autre part qui forme un atout solide permettant à l’équipe d’être plus performante et de livrer le meilleur des produits. »


Khalil Bannour– Banking Lab Manager- PO Bankerise-Proxym Group

Des obsessions ? Il en a plusieurs…

Penser aux utilisateurs :

Pour lui la meilleure façon de penser aux utilisateurs est de penser comme eux. C’est pour cette raison qu’il n’hésite pas à mener son enquête en amont, « s’infiltrer » dans leurs univers, leur parler et se mettre dans leur peau de temps en temps.
Il  croit à la démocratie en politique et à l’idiosyncrasie au travail car, pour lui, chaque utilisateur est unique et chacun doit “trouver chaussures à son pied” en utilisant ses produits.

Écrire des Scenarii :

Jusque-là Mr No n’a pas encore révélé tous ses talents. Il est très doué pour traduire les différentes possibilités ou façons d’utiliser le produit en histoires avec un langage digeste par l’équipe technique. Contrairement à Tarantino ou Coppola, le talent de Mr No ne réside pas dans ses capacités d’imagination mais dans sa rigueur et son aptitude à rester fidèle à la réalité.

Prioriser :

D’ailleurs, c’est à cause de –ou grâce à- cette obsession qu’on l’appelle Mr. NO
Il dit non à qui à quoi ?
Il dit non aux fausses bonnes idées qui ont bien l’air d’être innovantes mais qui n’ont pas leur place dans le produit et aux bonnes idées qui quant – à elles- risquent de retarder le projet.
Donc dans le « NO basket » il peut y avoir plus d’idées que celles réalisées au niveau du produit.
Cet arbitrage se fait sur la base de la valeur et la taille de chaque scénario, deadlines, et bien évidemment le fameux leitmotiv « customer centricity ». L’idée est de ne pas perdre un temps considérable à développer des fonctionnalités totalement inutiles pour les utilisateurs.

 

Je dis ça je dis rien 😉

Great Products come from saying No 🙂
Les idées et demandes de nouvelles fonctionnalités il y en a et en aura toujours plein ! Le bon Product Owner doit savoir dire « non » quand c’est nécessaire pour garantir un produit centré sur les besoins des utilisateurs et le ROI.
« Non, nous ne pourrons pas tout livrer d’un coup »
« Non, toutes ces demandes ne tiendront pas dans un seul sprint »
« Non, nous ne pouvons pas modifier le périmètre du sprint en cours »
« Non, cette fonctionnalité n’est pas prioritaire, du moins pour ce pour ce sprint / cette release »
« Non, cette fonctionnalité ne pourra être déployée en production telle quelle »

Khalil Bannour – Banking Lab Manager-PO Bankerise-Proxym Group

 

Communiquer :

Selon les approches traditionnelles du développement, les IT leaders collectent les exigences métier auprès des business-units (par exemple, quelles sont les nouvelles fonctionnalités requises dans les nouveaux logiciels ou applications créés et sur quelles plates-formes les nouvelles applications doivent-elles fonctionner ?) Les responsables informatiques saisissent ces exigences dans des documents remplis de jargon, et c’est avec un prototype presque terminé qu’ils doivent prendre contact avec le business unit la fois prochaine.
Avec la méthode agile, cette approche a changé. Il s’agit désormais de moins en moins de recevoir des ordres et de plus en plus de partager l’information.
Cet arbitrage se fait d’une façon collective comme notre PO connait la valeur des scénarios et l’équipe technique connait leur éventuelle taille.
Ces sessions de travail se déroulent régulièrement et Mr NO se base sur un backlog bien rempli d’idées de toutes sortes (des plus basiques aux plus fantaisistes). Le travail de Mr No ne se réduit pas à remplir ce backlog de nouvelles idées et histoires et s’amuser à renvoyer quelques-unes à « l’usine » et d’autres au purgatoire (NO-basket), mais il veille aussi à ce que toute l’équipe ait une vision commune du projet et qu’elle soit assez réactive en terme de livraisons. Ces réflexes acquis au fur et à mesure permettent à l’équipe IT d’être autonome au niveau de la prise de décision quotidienne et à notre PO de se concentrer sur une vision globale.

Quand Mr No se trouve prisonnier de ses dilemmes…

Au-delà du choix des « stories » et fonctionnalités, Mr.NO se trouve confronté à plusieurs dilemmes au quotidien et il n’est pas toujours évident pour lui de se prononcer devant ces situations :

Développer “les bonnes idées” vs “bien développer” les idées :

L’idéal serait certes de faire les deux, mais parfois, et même souvent, on se trouve devant la nécessité de faire un choix au détriment d’un autre.
Construire le produit parfait avec l’architecture parfaite c’est accepter le risque de dépasser le temps et le budget.
Dans l’autre coté, chercher à remporter le défi contre la montre augmente la dette technique sur le long terme.
De manière générale, Mr No préfère développer les bonnes fonctionnalités, l’équipe technique optent pour l’option de bien développer les fonctionnalités et les experts agiles, quant à eux préfèrent construire rapidement pour accélérer l’apprentissage.
La clé est de tester et discuter afin de trouver le juste équilibre selon le projet et les contraintes qui lui sont inhérentes.

Vision projet ou vision produit

Il faut préciser que Mr No ne travaille pas sur un seul produit. Il travaille sur plusieurs chantiers qui se chevauchent. Et lorsqu’on parle de projet, cela sous-entend que le développement à une fin. Or au niveau du produit il y aura toujours des améliorations à faire.
Et quand un nouveau produit est introduit dans le backlog, il serait dangereux de léguer les améliorations à une autre équipe qui n’était pas là dès le début. Donc notre PO doit, en concertation avec l’équipe, adopter la meilleure vision pour tenir le cap, et là encore c’est une question d’arbitrage.

Mr No et les prévisions Météo ?

A côté de tous ces challenges au quotidien notre PO agile doit être capable de gérer la relation avec le client. Ce dernier demandera de temps en temps au cours du développement du produit des informations sur l’avancement et surtout sur les prévisions.

Alors comment s’y prendre ?

Mr NO suit deux principes : OUI à la transparence et NON à l’espérance.
Alors ce n’est pas difficile de faire de prévisions et répondre à des questions ouvertes ou semi ouvertes telles que : « qu’est-ce qu’on aura de prêt avant l’été ? » « Quand est ce qu’on aura un produit fini ? » , etc.
Connaissant la vélocité des collaborateurs et le nombre de sprints à réaliser, il est possible de donner des réponses sous forme d’intervalles.
En revanche, répondre à une question du type, “Est ce qu’on aura cette fonctionnalité d’ici la fin de l’année?”, n’est pas aussi simple. Mr No est assez transparent quand il s’agit de gestion des prévisions et se base sur des plans pessimistes versus optimistes. Et si une fonctionnalité a peu de chance d’être prête à ce délai il n’hésite pas à le faire savoir au client et ce en se basant sur le calcul empirique et non pas ce qu’il aurait souhaité être prêt. Il faut dire que les clients apprécient souvent cette transparence chez Mr No.
D’ailleurs, si l’équipe accumule les dettes techniques, et n’améliore pas en continu l’architecture, et si les tests ne sont pas bien menés, cela ralentit le développement et ce type de prévision devient juste impossible même avec une boule magique.

Plus de complexité, même modèle

Mr No a travaillé également dans des structures plus étendues et complexes avec des équipes multiples et plusieurs PO. Le modèle est quasiment le même. Il s’est trouvé avec des No baskets, des backlog à nettoyer, des infos à partager et des personnes qui n’hésitent pas à dire non. Mais dans ce cas, il fallait plus de coordination et de synchronisation pour bien se partager les ressources et minimiser les dépendances.
Dans ce schéma Mr NO était rattaché à Mme Niet, CPO (chief Product Owner) qui loin des clichés, doit sa rigueur à ses origines germaniques et qui est aussi catégorique que Mr No.

Alors qui a dit qu’être PO en mode agile était facile ?

 

*CLI: bien évidemment cet index n’existe pas car difficile à mesurer, mais puisque on a commencé déjà à parler du Quantified Self, on ne va pas tarder à avoir les “Quantified Emotions”.