Product-Owner : super héros des méthodes agiles ?

Les méthodes agiles sont ‘peuplées’ de rôles qui permettent de les faire fonctionner. Sans ces rôles, correctement assignés et tenus, les méthodes agiles n’ont pas lieu d’être et conduisent souvent à un échec organisationnel qui jette le doute sur leur efficacité et leur pertinence. Le problème ici n’est pas la méthode en elle-même, mais plutôt sa mise en oeuvre.

Pour citer SCRUM, nous avons deux rôles qui sont spécifiques à la méthode :

• le Scrum-master : c’est le gardien de la méthode, il anime/impulse les différentes cérémonies (Sprint review, daily meeting, poker planning, backlog refinement, Démos …) et s’assure que les fondamentaux de la méthode sont compris et appliqués. Ce rôle est souvent tenu par un membre de l’équipe en plus de sa tâche “opérationnelle” de développeur ou de designer (UX/UI). Il est peu recommandé de cumuler ce rôle avec celui de product-owner, par contre on peut avoir un Scrum-master hors de l’équipe qui partagerait son temps entre plusieurs équipes agiles. (un coach agile par exemple, avec pour objectif d’identifier et de former les futurs scrum master à l’intérieur des équipes)
• le Product Owner (souvent identifié sous l’abréviation ‘PO’) dont nous allons parler plus spécifiquement dans cet article.

Dans la méthode SAFE (Scaled Agile Framework), d’autres rôles apparaissent dont celui de RTE (Release Train Engineer) dont la vocation est  de piloter la synchronisation des équipes agiles qui contribuent au même projet global. (c’est une sorte de Scrum of scrum pour ceux qui connaissent …) Les dépendances qui peuvent exister entre les User stories développées par les différentes équipes d’un même “train” (ou Agile Release Train pour les intimes) , sont pointées lors de la séance trimestrielle de PI Planning, animée par le RTE. Mais ceci est un autre sujet …

1 – Accompagner l’émergence du besoin

Pour en revenir à notre ‘PO’, il incarne la vision fonctionnelle du projet. Il fait la liaison entre les Business-owners et l’équipe de développement. Il est en charge de rédiger et de présenter les user-stories (sous-ensembles issus du découpage de fonctionnalités majeures) qui vont être estimées et développées par l’équipe.

Ces ‘US’ (et oui, il faut s’habituer à utiliser les abréviations :)) doivent refléter le besoin exprimé par les Business Owners et surtout être porteuses de valeur pour l’utilisateur final. Elle sont rédigées selon un formalisme pré-défini et largement partagé dans la communauté Scrum, on peut parler ici de template de rédaction. (le fameux As a < type of user >, I want < some goal > so that < some reason >.)

Le PO a aussi la responsabilité d’écrire les tests associés aux besoins fonctionnels exprimés. Ces tests permettent de valider l’atteinte des objectifs et font partie de la “Definition Of Done” qui permet à l’équipe de cadrer les critères de finalisation des développements. Les tâches de testing, (partiellement ou totalement automatisées) sont primordiales mais relativement complexes à appréhender pour les non-spécialistes. Je vous invite néanmoins à vous familiariser avec les concepts de Gerkhin, TDD (Test Driven Development) ou BDD (Behaviour Driven Development), car ils peuvent jouer un grand rôle dans l’organisation de vos équipes et dans la qualité du code livré.

Enfin, le Product Owner est l’interlocuteur privilégié des parti-prenantes marketing ou commerciales voir technico-commerciales pour les secteurs les plus techniques. (l’énergie par exemple) Il n’a pas vocation à faire des recommandations sur les choix techniques liés au projet par contre il est responsable ou en tout cas très largement acteur de la stratégie de delivery qui transparait dans sa gestion du backlog et qui doit coller à la stratégie d’accès au marché définie par l’entreprise. (promesse de valeur, time to market, innovation, mvp, …)

2 – Alimenter le backlog projet

Le backlog n’est ni plus ni moins qu’une liste de User Stories, dont le PO est en charge. Si on rentre dans le détail on peut même distinguer deux types de Backlog : le backlog projet et le sprint backlog. (J’en parle plus largement dans l’article accessible ici.)

Vous le verrez, la gestion de ces backlogs peut être la source de débats tant il impacte le rythme (et l’ordre) d’arrivée des fonctionnalités dont certaines peuvent revêtir une dimension stratégique ou politique. Dans un monde idéal, inspiré par les méthodes user centric (lean, ux design, Behavior Driven Development, …) c’est l’utilisateur final qui par ses feedbacks réguliers permet au Product Owner de définir la priorité des US en fonction de la valeur créée et des attentes du marché.

Un PO qui passe à côté des enjeux du backlog ou qui se voit court-circuité sur ses prérogatives, est potentiellement un point de vigilance à surveiller.

3 – Nourrir l’équipe de développement

Le remplissage du backlog est consécutif à un travail de découpage du périmètre fonctionnel du projet, et à la qualification des user-stories. En effet, le processus d’estimation des user-stories permettant de passer du “project backlog” au “sprint backlog” ne peut se faire correctement que si les user-stories sont correctement qualifiées, c’est à dire qu’elles ne comportent pas de “zone d’ombre” et que leur faisabilité pourra bien être estimée lors de la séance commune avec les développeurs et les éventuels profils designers.

Pour qualifier les user-stories, le product owner peut s’appuyer sur les principes I.N.V.E.S.T :

• Independant (peut fonctionner seul, indépendamment des autres user stories) ;
• Negociable (éviter d’arriver avec une solution ‘toute faite’. C’est un des gains de la séance d’estimation que de permettre à l’équipe de co-construire la solution, sur la base d’un besoin correctement décrit ) ;
• Valuable (porteur de valeur en soi) ;
• Estimable (sa faisabilité peut être estimée) ;
• Small (de la plus petite taille possible) ;
• Testable (son fonctionnement devra être testable et testé de manière effective) ;

Un PO souhaitant préparer solidement sa séance de présentation/estimation pourra s’appuyer sur ces critères et en faire une sorte de checklist de conformité pour chacune des US à estimer. Ainsi il s’assure de la robustesse de sa démarche et maximise ses chances de réussir sa séance et donc de remplir le prochain sprint.

A noter que le travail de qualification des US s’accompagne souvent d’ateliers d’échanges pluri-disciplinaires en amont des séances d’estimation afin de définir les scénarii de développements et de s’assurer de l’exhaustivité des règles de gestion.

La méthodologie Scrum n’interdit pas les interactions complémentaires (hors rituels agiles) qui se justifient pleinement par la complexité des problématiques auxquelles nous devons faire face. Il faut simplement veiller à ne pas trop amputer le temps de travail opérationnel des développeurs qui doivent répondre à des exigences de planning et dont les performances impactent directement la vélocité de l’équipe.

L’ensemble de ces démarches, faites en amont de la séance d’estimation participent à ce qu’on appelle la “Definition Of Ready”. (en référence à la “Definition of Done”, qui liste les critères validant la finalisation d’une user story au cours d’un sprint) Le Scrum-master peut également être mis à profit sur cette phase, afin d’aider l’équipe à atteindre le bon niveau de fluidité et de régularité dans le remplissage du “sprint backlog”.

Conclusion : Pas de Product Owner, pas d’Agile !

Vous l’aurez compris, pour moi le Product Owner est un rôle clé si ce n’est LE rôle clé de l’agilité.

Les écarts de compétences ou de savoir-être sur ce rôle font des différences énormes sur les projets car la personne en charge de ce rôle se trouve sur un axe de médiation interne à l’entreprise en plus d’être un référent fonctionnel. Je parle bien ici d’une configuration type “grand compte” avec un grand nombre de parti-prenantes souvent non co-localisées. Le cas de figure du Product Owner en Start-Up est bien différent car il endosse alors une posture de véritable Product Manager avec une latitude significative sur ses prises de décisions vis à vis du produit/service à développer.

…

Si vous souhaitez créer, renforcer ou optimiser vos équipes dans un contexte agile, (Scrum, Lean ou Safe) je peux vous y aider en adressant les points suivants :

• Audit de fonctionnement de vos équipes agiles ;
• Formation / renforcement des compétences du PO ou Scrum master ;
• Travail sur le mindset et le positionnement vis à vis des différents interlocuteurs projet ;
• Sourcing de profils en vue d’une embauche ;
• Conduite des entretiens d’embauche avec test des compétences ;