Nexus est un framework (cadre) d’agilité à petite / moyenne échelle venant de Scrum.org. Selon le dernier State of Agile Report, (14ème report en 2020), 3 % seulement des implémentations agiles passées à l’échelle utilisent Nexus (l’année précédente il représentait 2 % et encore moins l’année d’avant – 1 %). Cet article se focalise sur le rôle du Product Owner dans le Nexus.
Un article d’une mini-série – ajustez votre niveau de lecture
Nous vous présentons ce framework à travers d’une série d’articles. Celui-ci est expliquera plus en détail la gestion du produit et le rôle du Product Owner à l’échelle. Si vous cherchez plutôt une vue générale et brève ou, au contraire, d’autre détails, n’hésitez pas à consulter nos autres posts de la mini-série :
- Nexus : Je me présente, je m’appelle Nexus… – la vue générale sur le framework.
- Nexus : Cérémonies à l’échelle – dis-moi, qu’est ce qui change et pourquoi ?
- Nexus : Rôle du Product Owner à l’échelle du Nexus. (cet article)
- Nexus : Nexus Integration Team – nouveauté, mais rien de surprenant. (sera publié le 28/12/2020)
Vous êtes un CPO (Chief Product Owner) ou vous en avez un dans votre dispositif Agile à l’échelle ? Lisez la suite pour voir comment Nexus s’en sort sans la notion d’un CPO explicite…
Scaled Scrum is Still Scrum – Un produit, un Backlog, un Product Owner
Dans le Scrum classique, une équipe a un Product Owner. Avec Nexus, à l’échelle de plusieurs équipes, c’est toujours le cas, sauf que ce PO est partagé par tous ! Ainsi, on est à la fois compatible avec les principes de fonctionnement d’une équipe Scrum et on passe à l’échelle de façon la plus simple – la grande équipe Nexus composée a, elle aussi, un seul Product Owner.
Comme dans le Scrum avec une seule équipe, la notion d’un seul Product Backlog est cruciale aussi à l’échelle multi-équipe dans le Nexus. Comment faire plus simple ? Avez-vous un seul produit ? Un seul Backlog global doit donc vous suffire – c’est aussi simple que cela. Toutes les équipes impliquées sont dédiées à ce produit et travaillent à partir du même backlog. Ainsi, pas de conflits d’intérêt entre les équipes car elles travaillent sur la même vision globale, sur le même « Nexus Backlog », sur le même « Objectif du Sprint Nexus » global, décliné aux Objectifs du Sprint de chacune des équipes. Seules les dépendances entre les équipes en vue d’intégration d’une même fonctionnalité commune sont à résoudre et à prioriser.
Une seule personne – un seul Product Owner (PO) – gère le Backlog. Il/elle est responsable et redevable de son contenu et de sa priorisation. Ce fait résout par définition l’alignement sur la valeur entre les équipes car nous avons une seule personne, un seul point de contact qui peut rapidement décider et arbitrer sur les questions de priorité versus valeur.
Comment le PO fait-il avec le Backlog unifié ?
Le Nexus unit l’effort de vision produit, de préparation du travail (maturation des Stories), l’implémentation dans un seul grand Backlog. La vue spécifique à une équipe n’est rien d’autre qu’une sous-vue filtrée du Backlog global. Découper, raffiner, identifier les dépendances entre les équipes est autant plus facile si un seul Product Owner est à l’oeuvre de construction et si la demande est exprimée via un seul Backlog Nexus.
Côté outils digitaux, cette unification apporte une vraie transparence, une souplesse de travail et une visualisation transverse facilitée. Pourquoi avoir des Backlogs spécialisés pour chacune des équipes et séparés les uns des autres (voire des outils différents selon l’équipe – Jira / Trello / YouTrack / VersionOne / Monday.com…). Pas simple de s’y retrouver avec des visualisations différentes, champs différents, UX différentes… Un backlog global et un seul outil pour le saisir et pour l’exprimer est la réponse structurelle à un travail commun. L’implémentation exacte et le choix de l’outil est, bien sûr, à votre convenance.
Si vous construisez Nexus à partir des équipes existantes qui ont déjà leurs propres méthodes et leurs outils et qui sont différents, prévoir le passage à un Backlog unifié est une étape obligatoire sans laquelle vous ne pourrez pas correctement démarrer.
Product Owner et la Nexus Integration Team
Outre son travail classique « PO » avec le Backlog global et, par hiérarchie de la demande, avec les Backlogs des équipes, le PO fait partie de la Nexus Integration Team (NIT). Il y tient, sans surprise, également le rôle du Product Owner, en plus de ses collègues – un Scrum Master NIT et des équipiers qui sont choisis selon les besoins spécifiques du moment pour assurer l’intégration fluide du produit.
Cette équipe transverse, fonctionnant également en Scrum, est une nouvelle notion qui apparaît dans le Nexus avec la montée à l’échelle comme conséquence du besoin de synchronisation. Elle est au centre de l’organisation car elle assure la coordination et est redevable de l’intégration du travail des équipes dans un produit unique. Elle est chargée de résoudre des problèmes transverses éventuels. Par extension, c’est cette équipe qui facilite l’atteinte des objectifs et est garante de la bonne implémentation du framework agile Nexus.
La place du PO dans une telle équipe est plus que convenable : le PO peut directement coordonner Nexus sur les questions produit, effectuer les arbitrages au jour le jour (si nécessaire) ou agir très rapidement sur la composition du Backlog en cas de blocage ou en cas de découverte des dépendances imprévues. La Nexus Integration Team est donc une instance privilégiée où le Product Owner peut participer directement et de façon collaborative avec les autres collègues de la NIT sur le pilotage centralisé d’intégration de l’effort de toutes les équipes.
ReX et la réalité de l’implémentation – le PO est-il vraiment tout seul ?
Toutes ces équipes, tout ce grand Backlog pour une seule personne ? On se demande si c’est humainement possible de tout faire tout seul. La réalité terrain peut être un peu plus pigmentée que la théorie noire et blanche « by the book ».
Dans le REx sur l’implémentation du Nexus chez Capital One, (temps 09′ 20″) – cette implémentation du Nexus parle de la cellule « Product Management Team » composée de Product Manager, de Product Owner et d’Assistant Product Owner, avec une sorte de hiérarchie établie entre eux. Le Product Manager est placé dans la position du « Guide du PO ». En même temps, la responsabilité des décisions est toujours restée à la main d’une seule personne désignée – et c’est bien celle du Product Owner. Pour palier le goulot d’étranglement qu’il peut causer dans la cas de nombreuses équipes, il est épaulé (dans l’implémentation Nexus chez Capital One) par un « Assistant Product Owner ». Celui-ci aide le PO dans la rédaction des Stories.
Notre avis : à prendre avec des pincettes car si on ne fait pas attention, on pourrait vite se retrouver dans des triumvirats « Chef de projet métier / Chef de projet informatique / Business Analyste » (MOA, MOE, AMOA/AMOE). Avec le silotage et des chefferies que cela peut induire et dont on voulait tellement s’abstraire en adoptant Nexus. Attention à ce que vous ne retombiez pas de nouveau à la case de départ !
Réponse au manque du temps : délégation ! Et quelles qualités on veut chercher chez un PO Nexus par rapport à un PO Scrum ?
Le Product Owner Nexus gère un effort de plusieurs équipes et de plusieurs dizaines de personnes impliquées dans la construction du produit. Il adresse un périmètre d’action largement agrandi par rapport à un Product Owner Scrum focalisé sur une seule équipe. Le Nexus Guide ne nous dit rien sur le profil ou les qualités d’une telle personne.
On peut donc prendre les devants et recommander une personne déjà expérimentée avec un Scrum classique. Quelqu’un qui a déjà acquis des bases solides dans un autre projet Scrum, voire plusieurs autres projets. Par ce volet, c’est déjà quelqu’un (elle ou il) qui sait décider et trancher quand il le faut et qui sait également dire « non » quand le bien du produit ou des personnes le nécessite. En plus, il doit avoir d’excellentes qualités humaines et relationnelles. Pourquoi ? Car le travail de coordination à plusieurs dizaines de personnes est essentiellement un travail de communication, de récolte de retours, d’animation des parties prenantes, d’établissement des règles communes et de leurs explications.
Il devrait également maîtriser la délégation de la responsabilité par objectifs et de leur co-élaboration avec les équipes. C’est via ce volet qu’il pourra se dégager du temps et prendre de la hauteur, tout en s’appuyant sur l’autonomie des équipes. Pas n’importe quelle autonomie – c’est bien une autonomie pilotée par objectifs et par la délégation de décision locale. Scrum et Nexus facilitent cela par la notion des Objectifs du Sprint et par l’Objectif du Sprint Nexus. C’est de cette façon qu’il pourra maîtriser son rôle de PO de chacune des équipes et rester disponible à leur sollicitations. À une ou deux équipes, il pourrait potentiellement encore assister à toutes les cérémonies de chacune des équipes, mais avec le nombre d’équipes et de personnes qui augmentent, la délégation de la responsabilité et le pilotage par objectifs deviennent inévitables.
À ne pas oublier, même si cela va de soi, il doit être un convaincu de l’approche agile et être un bon avocat de l’explication du fonctionnement du Nexus si nécessaire. Comme il fait partie de la Nexus Integration Team dont la mission et la bonne implémentation du cadre agile et même si des Scrum Masters sont là pour veiller à cet aspect, il n’y a rien de plus encourageant qu’un Product Owner exemplaire qui comprend les avantages d’agilité et qui est capable de le démontrer par ses actions et par la valorisation du travail de l’équipe entière.
Est-il possible de prendre un novice d’agilité pour ce rôle ? Si vous n’avez pas d’autre choix, épaulez-le par un bon accompagnateur (Scrum Master, Coach dédié) et dégagez lui le plus de temps possible pour qu’il puisse prendre et apprendre ce rôle dans la durée avec sérénité.
Take away…
Nexus apporte de la structure pour le travail à plusieurs équipes à petite échelle. Le rôle du Product Owner est crucial car c’est sur lui que repose la responsabilité « métier » d’emmener le produit en production. Ceci se passe via la collaboration avec les équipiers et les différentes parties prenantes, préparation de la demande dans un Backlog commun et sa responsabilité partagée d’intégration via sa participation dans la Nexus Integration Team. Tout en apportant les éléments nécessaires, en identifiant les risques pour qu’ensemble avec l’équipe on établisse un plan par incréments de Sprint et via un objectif commun alignant tous – l’Objectif du Sprint Nexus.