Quelles conséquences si un product owner est pas disponible ?

Il nous est tous arrivé d’avoir des coups de bourre. Ces moments où tout arrive en même temps et où on ne sait plus où donner de la tête. Parfois c’est temporaire, et parfois cette quantité de travail à abattre ne diminue pas. Alors que se passe-t-il si le Product Owner n’est pas suffisamment disponible ?

Nous n’allons pas parler dans cet article de comment s’organiser, comment distinguer l’urgent, de l’important et de ce qui ne l’est pas. Nous allons plutôt nous pencher sur les conséquences. Quand le Product Owner n’est pas suffisamment disponible pour l’équipe.

Il y a plusieurs raisons à l’indisponibilité d’un Product Owner. Il y a le coup de bourre comme énoncé plus haut, mais il y a des situations moins épisodiques qui vont bouleverser le projet.

Un PO tout seul

Une des raisons est de n’avoir qu’un seul Product Owner gérant plusieurs produits. Un seul Product Owner travaillant avec plusieurs équipes. La situation devient difficile car il n’est pas possible de se dédoubler. Cette situation se produit souvent par manque de ressource. Il est aussi possible que l’on en soit là parce que le PO ou le management n’ont pas bien anticipé la charge de travail, pensant qu’elle n’était pas si importante. Et qu’un seul PO pourrait bien s’en sortir. Après tout il ne fait que rédiger quelques User Stories pour le sprint suivant.

Un autre cas que nous rencontrons fréquemment est une conséquence la réunionite aiguë. C’est un mal trop fréquent dans nos entreprises. Parfois même, ces réunions sont magiques, si si, vous pouvez lire cet article à ce sujet “Les réunions magiques”. Il est possible d’avoir plusieurs Product Owner. Mais s’ils sont toujours en réunions, et s’il n’y a qu’un seul PO pour plusieurs produits (en plus, le pauvre). Du coup le product owner est pas disponible.

« Dis donc Pierre, tu as un moment pour que l’on discute de cette Epic ? » / « Oui bien sur Romain, attends je regarde mon agenda …. Demain soir vers 19h30 après ma réunion de COPIL, si elle se termine à l’heure. Là je ne peux pas j’ai COTECH ! ». Le management ne sait souvent pas prendre de décision en dehors des réunions, et pour prendre des décisions faut-il encore comprendre. Et pour comprendre le produit ils ont besoin du PO. D’autant plus si le backlog n’est pas visible de tous. Encore plus si les indicateurs minimaux ne sont pas visibles de tous. Toujours plus si le management n’a pas compris ou pris l’habitude du nouveau fonctionnement en Scrum / Agile.

Il est aussi probable que le Product Owner soit sur une seule équipe. Mais sur un produit trop gros pour lui seul. Il est alors à la fois dans le 1er cas, débordé, et aussi, dans le deuxième cas, atteint de réunionite. Et pas seulement pour rendre compte au management.

La mission du PO n’est pas normalement uniquement de rendre compte de l’avancement du projet. Afin d’éviter la multiplication des réunions avec les différents intervenants, le PO doit s’appuyer sur les réunions de sprint review et la transparence des backlogs de produit et de sprint. Le PO a en effet pour mission de gérer son backlog. Mais pour le faire correctement et pour prioriser le backlog il va devoir être au plus près des parties prenantes (Stakeholders, Utilisateurs, UX, UI, Sponsor etc.). Tout en faisant régulièrement des points avec eux afin de dessiner le produit idéal, souhaité et apportant le plus de valeur à l’utilisateur final.

Mais, Docteur, comment je fais pour savoir si mon Product Owner est atteint de réunionite ?

Parce que mon PO trime dur mais ne se plaint pas.

Il n’a peut-être pas osé, le pauvre. Si le Product Owner est seul il sera très vite débordé, vous vous en doutez. Il n’aura peut-être plus de disponibilité pour vous également. Sa surcharge de travail le rend quasi inaccessible de tous.

Le plus probable est qu’il ne soit plus disponible pour la dev team. Idéalement, toutes les User Stories qui alimentent le Backlog de Sprint doivent être « Prêtes ». En suivant les règles qui ont été décrites dans la Definition of Ready (DoR). Logiquement, la dev team n’accepte alors pas de commencer à développer une US qui ne respecte pas la DoR. Mais comme la plupart des US ne sont pas prêtes, la dev team a peut-être convenu avec le PO de les prendre quand même. A condition de les rendre prêtes le plus rapidement possible pendant le sprint.

Seulement voilà. Le Product Owner n’avait déjà pas eu le temps de rédiger correctement les US, ou de les rédiger tout court du fait de sa surcharge de travail. Alors si en plus de cette surcharge, il s’en ajoute une supplémentaire en devant les rendre prêtes pendant le sprint, il est clair qu’il va dans le mur. La dev team aussi, ainsi que le produit. La Dev Team risque de très vite se retrouver bloquée, et attendre le PO. Le PO pendant le sprint n’aura alors pas le temps de rendre les US prêtes pour le sprint suivant. Et il ne pourra pas répondre aux questions de la Dev Team sur les US du sprint en cours. C’est le serpent qui se mord la queue. Les US ne sont pas prêtes et le PO doit continuer à travailler avec les parties prenantes pour les futures US.

Il est probable alors qu’il ne soit plus disponible pour personne, ou si peu qu’il ne pourra rien mener complètement. S’il se détache des parties prenantes, il est possible qu’il perde la vision du produit.

Sans cette vision il ne pourra plus prioriser correctement le backlog du produit. Sans vision et n’ayant plus le temps, le backlog produit n’est plus entretenu. C’est alors une découverte et priorisation live à chaque sprint planning. Avec comme risque d’amener le produit dans une direction qui ne convient à personne. Ne permettant pas à la Dev Team de s’engager sur un un objectif clair. Lors de la sprint Démo, le travail réalisé et démontré ne correspondra pas au besoin. La Dev Team risque de se désengager du produit. Et alors de ne livrer que ce qui apportera de la valeur selon sa propre vision.

Quelles solutions pouvons-nous mettre en place si le product owner est pas disponible ?

La première, la plus simple en apparence, est d’avoir un Product Owner par équipe, mais ce n’est peut-être pas possible. Et si finalement cela devenait possible sans augmenter la taille de l’équipe ? Il y a peut-être dans les équipes des personnes qui aimeraient elles aussi devenir PO. Ou simplement souhaitent assister le PO dans le recueil des besoins utilisateurs. Attention à ne pas créer des Proxy PO (voir cet article « Le Proxy Product Owner est-il légitime ?« ). Est-ce mieux d’avoir une équipe qui délivre peut-être moins mais apportant de la valeur ? Ou une équipe qui a la capacité apparente de délivrer plus mais au final sans apporter de valeur car elle délivre mal ?

La seconde est une règle que devrait se fixer le Product Owner. S’il veut avoir du temps pour rédiger correctement les prochaines US, il ne doit pas être perturbé pendant le sprint en cours par la Dev Team. Pour que la Dev Team soit autonome, le PO doit absolument rédiger des US prêtes, en respectant la DoR. Par ailleurs, s’il n’existe pas de DoR, la Scrum Team doit en rédiger une le plus rapidement possible. Le PO doit également transmettre à l’équipe une vision clair du produit, indiquant sans ambiguïté à la Scrum Team là où elle doit aller. La Dev Team doit aussi apprendre à être autonome et savoir où chercher une information si elle est bloquée. Par exemple, s’il manque un pictogramme pour l’interface, dans ce cas pourquoi ne pas demander directement au graphiste ?

Réunionite ?

Vous devez également vous poser la question « Le Product Owner est-il vraiment utile dans cette réunion ? Apporte-t-il quelque chose, y apprend-il quelque chose ? », s’il ne répond pas à une de ces questions, pourquoi l’inviter ? Certaines réunions ne sont que des comptes rendus ou des présentations qui peuvent très bien être remplacées par le support. Certaines personnes se sentent obligées d’inviter tout le monde à leur réunion. Juste dans le but de ne frustrer personne, sans se demander si ces personnes y ont un intérêt. Il n’est pas toujours facile de faire le tri et de limiter sa participation aux réunions essentielles.

Le Product Owner est souvent sollicité pour les différentes réunions afin de rendre compte. Normalement, si les bons outils Scrum sont utilisés, il ne devrait alors pas être nécessaire de réaliser des réunions spécifiques. Pendant la review, la Dev Team va réaliser une démo de ce qui a été réalisé. Et le PO faire un état du produit, via par exemple le burnup chart. Il va également présenter les éléments qui n’ont pu être réalisé et expliquer pourquoi.

Si les bonnes personnes sont présentes à ces sprints review, elles n’ont pas besoin d’une réunion supplémentaire. Également, le backlog de produit et le backlog de sprint doivent être visibles et à la disposition de tous. Si ce n’est pas le cas, en effet le PO va être submergé de questions des parties prenantes. Il est peut-être utile de communiquer sur ces artefacts, éduquer les parties prenantes et peut-être les former.

Le Product Owner a un rôle très important dans une Scrum Team et pour le produit. Son rôle et ses missions ne sont pas à minimiser. S’il ne peut pas les remplir complètement, le produit en pâtira indéniablement. Vous vous demanderez alors pourquoi il n’apporte pas la valeur attendue et ne respecte pas la vision partagée. Ben par ce que le product owner est pas disponible.