L’équipe du Product owner

L'équipe d'un product owner - leproductowner.com

L’équipe du product owner est la base qui définit le rôle du product owner.

Sans son équipe, le product owner n’a pas de raison d’être. 
Le contraire est possible.

Cependant, avec l’essor de l’agilité en entreprise,  il est de plus en plus difficile de confier le travail à une équipe de développeurs sans supervision du product owner.

  • Qui sont les membres de son équipe ?
  • Quel rôle joue le product owner dans son équipe ?
  • Comment est constituée une équipe ?

Dans ce post, j’aborde toutes les choses essentielles à savoir sur l’équipe du product owner.

L’équipe du PO : Les bases

Il n’y a pas vraiment d’équipe type mais en règle général le product owner gère une petite équipe de 5 ou 6 personnes (maximum 10), principalement composée de :

L’équipe du product owner est concentrée sur 1 seul produit ou parfois même juste d’une ou plusieurs fonctionnalités d’un produit.
Son unique but est de garantir la maintenance du produit (s’assurer que tout fonctionne correctement) et bien entendu de l’évolution de ce produit / fonctionnalité (nouveautés). 

Le product owner travaille généralement au plus près de son équipe.

Traduction: Il est assis parmi ses collaborateurs afin de privilégier le dialogue en continu.
Cette proximité lui assure de pouvoir répondre aux questions de chaque membre de son équipe le plus vite possible.

Au delà, de pouvoir aider son équipe, la proximité lui permet de prendre de l’information en temps réel et d’être alerté des urgences avant tout le monde.

Le product owner est il le manager de son équipe ?

Dans la méthodologie Scrum, le product owner n’a pas un rôle de manager.
Son rôle est avant tout de pouvoir faire la liaison entre les développeurs et les autres stakeholders.
En effet, avant l’introduction de la méthode agile en entreprise, les départements techniques avaient tendance à rester isoler des autres départements (Marketing, commercial…).

Cette structure favorisait le travail en silo et avait pour conséquence de fracturer la communication entre les départements.
Je ne parle même pas de la productivité.

Le rôle principal du product owner est de pouvoir servir de traducteur pour les stakeholders qui ne parlent pas le langage technique.

Son rôle permet de fluidifier les échanges entre les différents départements non technique et le département technique.

Cependant, malgré que ce ne soit pas son rôle premier, le product owner manage implicitement l’équipe de développeurs à laquelle il est rattaché.

En effet, en étant au contact des décideurs, des clients et du marché, il possède des informations cruciales que les développeurs n’ont pas.

Grâce à ces informations, il est en mesure de pouvoir orienter la vision d’un produit et de prioriser les tâches des développeurs.

Comment le product communique avec son équipe ?

Au delà des échanges quotidien en face à face, le product owner et son équipe sont soumis à plusieurs rituels appelés “Cérémonies”.

Quelles soient quotidiennes ou hebdomadaires, ces cérémonies sont en fait des réunions plus ou moins courtes pour faire le point entre collègues.  

Elles permettent avant tout d’informer le product Owner des avancements et des problèmes rencontrés. 

La cérémonie la plus populaire est sans aucun doute le “Stand-up daily” (encore du jargon).

En théorie, le product owner ne doit pas gérer cette cérémonie, c’est au Scrum master de la gérer.
En pratique, beaucoup de sociétés n’ont pas le luxe d’avoir un scrum master et c’est au product owner de l’organiser.

C’est quoi le “Daily” ?

En bref, c’est un très court meeting de 5 à 10 minutes qui à lieu tous les jours avant de commencer officiellement sa journée.

La particularité de cette réunion est que tous les membres de l’équipe doivent y participer. 

La raison pour laquelle on la définit plus comme une  “cérémonie” que comme une simple réunion est qu’il y a plein de petites règles et de codes à respecter:

  • Tous les participants doivent rester debout (pas de table ou de chaises).
  • Tous les participant doivent résumer le travail de leur journée précédente et expliquer sur quoi ils vont travailler dans la journée.
  • Le but du “Daily” est d’informer de l’avancement individuel de chacun afin d’identifier d’éventuels blocages ou ralentissements.

Véritable outil de la méthode agile, le “Daily” permet au product owner et de son équipe de tout connaître sur l’avancement du sprint en cours.

L’idée est de pouvoir réagir au moindre imprévu et de prendre des décisions avant qu’il ne soit trop tard.

Le daily sert à optimiser le déroulement du sprint voir même dans certains cas de modifier le planning de développement.

Au delà du “Daily”, l’équipe d’un product owner est soumis à plusieurs autres cérémonies.

Parmi elles, il y a le “Sprint planning”, le “Sprint retrospective”, le “Sprint grooming”….  Si vous voulez en savoir plus j’en parle dans ce post

La communication est centrale

En résumé, la communication est la valeur principale d’un product owner et de son équipe.

La règle de base est que chacun est autonome et décideur sur son expertise métier. 

Cette autonomie est mise en place grâce à un système de collaboration poussé à l’extrême.  Chaque membre est une roue d’un engrenage dont le lubrifiant est la communication. 

Comment est constitué l’équipe d’un product owner ?

Au début de cet article, j’ai brièvement évoqué une composition d’équipe classique, peu importe si elle est onsite ou remote :

  • Développeurs (60% de l’équipe au minimum)
  • Q/A (ingénieurs test) 
  • et parfois de UX designers, UX researchers et d’analystes.

En réalité, cette composition est une généralité à ne pas prendre au pied de la lettre.
Tout d’abord il existe 2 conditions: Soit l’équipe est fixe soit elle est changeante.

Équipe fixe:

L’équipe assignée au product owner est toujours la même, sprint après sprint.

Cette structure permet de faciliter la cohésion entre chaque membre qui se connaissent sur le bout des doigts.

Cela permet aussi au product owner de pouvoir avoir plus maîtrise dans le sprint planning.

En effet, en connaissant la force et les faiblesses de chaque membre de son équipe, le P.O peut assigner les tâches qui conviennent le mieux à chacun.

Cela lui permet aussi de pouvoir évaluer plus précisément la vélocité de travail de chaque membre.

Si vous êtes perdu face à ce jargon, je vous recommande de lire le post sur le sprint planning.

Dernière chose à propos de l’équipe fixe.

En général une équipe fixe se retrouve dans une entreprise qui fait appel une organisation agile appelé le modèle de “Spotify”. 

Dans ce modèle, les équipes sont appelées des “Squads” et sont organisées par mission.

Par exemple:

  • La squad 1 est assignée à la mission “Amélioration de l’expérience utilisateur”
  • La squad 2 est assignée à la mission “Optimisation du panier client”
  • Etc…

Chaque squad à une mission bien précise qui s’inscrit dans la durée.

Ainsi, l’équipe est formée en fonction de toutes les personnes qui sont le plus à même de pouvoir réaliser cette mission.

Équipe changeante:

A l’inverse de l’équipe fixe, cette structure demande beaucoup d’organisation dans la logistique de l’équipe technique.

En pratique, l’équipe du Product owner peut être amené à changer à chaque sprint en fonction des besoins du planning.

Par exemple:

  • Sprint 1: Le besoin estimé pour réaliser une fonctionnalité requiert 2 développeurs Backend et un développeur Android.
  • Sprint 2 : Le besoin estimé pour réaliser une fonctionnalité requiert 3 développeur frontend (1 intégrateur HTML, 2 développeurs javascript)
  • Etc…

Perso, je ne suis pas fan de cette organisation. Cela engendre beaucoup de stress et complique inutilement l’organisation.

Imaginez qu’à la fin d’un sprint toutes les user stories ne sont pas complétés.

Comment faire pour débuter un nouveau sprint si les nouveaux membres de votre équipe n’ont pas les skills pour finir le travail du sprint précédent ?

Ce modèle est souvent appliqué quand une entreprise décide d’organiser ses ressources en mini-agence.

  • Une Frontend agency constitué de tous les développeurs Frontend
  • Une Android agency constitué de tous les développeurs Android
  • Une iOS agency constitué de tous les développeurs iOS
  • etc…

Dans cette structure, il faut constamment réorganiser les équipes chaque sprint en allant piocher des membres dans chaque mini agence.

Il est très dur pour un P.O de garder le rythme car il faut constamment anticiper avec quel collègue vous allez travailler le prochain sprint.
Cela demande de discuter avec chaque membre des tâches à accomplir dans les sprints suivants alors que chacun est occupé à quelque chose de complètement différent.

Par expérience, je trouve aussi que ce genre de modèle ressemble plus à un modèle de web agency.  Chacun à des missions courtes avec une durée définie.

Cela affaiblit l’esprit d’équipe et la motivation des collaborateurs

En effet, personne ne s’attache à une mission ou un produit car ça change tout le temps.

Les règles implicites :

Enfin pour terminer, voici quelques règles non écrites mais qui en pratique doivent être appliquées pour assurer le bon fonctionnement d’une équipe.

Pas plus de 10 membres par équipe (10 c’est déjà trop)

Un des rôles majeurs P.O est de distribuer des tâches et de s’assurer du suivi.

Ces tâches ou user stories prennent un temps considérable à être définies.

Prenons l’exemple où le P.O à 8 développeurs dans son équipe.

  • Chaque développeur réalise en moyenne 3 tâches par sprint.
  • Cela veut dire qu’il faut qu’à chaque sprint le P.O prépare 24 users stories en avance.
  • Sans compter les 24 tâches en cours qu’il doit suivre.

Au total. cela fait près de 50 tâches à gérer en même temps. Sans compter les à côtés (Réunions, bug qui interviennent n’importe quand…).

La taille de l’équipe doit rester humainement gérable sinon gare au burnout.

1 seule équipe par product owner. 

J’ai déjà rencontré des cas où le P.O devait gérer 2 équipes en parallèle mais comme dit dans le point précédent, cela ajoute plus de membres à gérer.

Si vous êtes product owner et que vous avez 2 équipes sous vos responsabilités, votre organisation à tout faux.

1 QA engineer par équipe au minimum

Si vous êtes PO et que vous n’avez pas de QA engineer dans votre squad, vous allez au casse pipe.

Encore une fois, si vous êtes dans ce cas, c’est la faute de votre organisation mais sans QA engineer :

  • Qui se charge des tests fonctionnalités (parfois appelé recette) ?
  • Vous ?

Je l’ai lu parfois et je l’entends quelques fois “Le  PO doit être responsable des tests”.
Faux et complètement faux.

Oui, le product owner doit s’assurer que la fonctionnalité implémentée lors d’un sprint est conforme aux critères d’acceptation.

Mais ce n’est à lui de mettre en place les tests d’automatisation ou de faire du testing manuel.

Cette mission est beaucoup trop chronophage et ne rentre pas dans l’agenda d’un P.O.

Avant de valider une fonctionnalité à mettre en production, le P.O doit exiger un démo.

A ce moment, il peut évidemment détecter des oublis ou des bugs non identifiés par l’équipe QA.

Mais jamais au grand jamais, vous devez réaliser la phase de recette.

J’y reviendrai plus tard dans un autre post, car je pense que ce sujet mérite d’être traité en profondeur.

Que retenir ?

Mis à part quelques caractéristiques liées à la méthode scrum, il n’y a pas de grosses révélations à connaître sur l’équipe du product owner.

Les deux choses importantes à retenir sont:

  • Comprenez la place du product owner au sein de son équipe.
    Il  n’est pas défini comme le manager mais comme un membre à part entière. Malgré tout, sa qualité de responsable du produit lui donne une autorité légitime à manager certains membres.
  • Une équipe peut avoir plusieurs formes différentes. Retenez que le nombre de collaborateurs doit pouvoir rester gérable.

Laisser un commentaire

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