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 sa spécificité – La NIT – la Nexus Integration Team.
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 dédié à la Nexus Integration Team, une particularité propre au Nexus. 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.
- Nexus : Nexus Integration Team – nouveauté, mais rien de surprenant. (cet article)
Spécificité de Nexus – nouvelle équipe transverse
Avec le framework Nexus, une nouvelle instance de coordination apparaît pour épauler l’aspect à l’échelle du Scrum dans ce framework. C’est une équipe transverse appelée l’« Équipe d’Intégration Nexus » et qui fonctionne aussi en Scrum. Comme n’importe quelle équipe Scrum, elle a aussi un Product Owner (et c’est celui de tout le Nexus) et un Scrum Master (qui peut être également le SM d’une ou plusieurs autres équipes) et les Nexus Integration Team Membres. Les membres de cette équipe peuvent être des membres des équipes Scrum individuelles. Si c’est le cas, leur participation à la Nexus Integration Team doit être prioritaire par rapport au travail dans leurs équipes individuelles. Ceci dans la logique de pouvoir résoudre des problèmes qui touchent plusieurs équipes d’abord, la participation dans leurs équipes individuelles après. Nexus assure ainsi la résolution prioritaire des problèmes transverses.
Elle a un double objectif :
- assurer et coordonner l’intégration de l’incrément qui est « Done » et de résoudre les problèmes systémiques transverses.
- mais également de superviser la bonne implémentation du framework agile Nexus dans toutes les équipes impliquées. Ce qui comprend le coaching agile, la coordination à l’échelle des équipes ainsi que la facilitation en identification et résolution des dépendances et des problèmes rencontrés.
Jusqu’à ici, rien de surprenant, on peut presque dire qu’elle agit comme une équipe « Scrum Master » au niveau des équipes. Mais attention, ceci ne serait pas juste car il est important de remarquer que cette équipe n’est pas uniquement une instance légitime pour coacher, débloquer et s’assurer de bonne implémentation de l’agilité, mais elle a est surtout la responsabilité et elle est redevable du succès d’intégration du travail de plusieurs équipes. Et comme vous vous en doutez déjà, Nexus lui donne ainsi le pouvoir délégué pour y parvenir.
Les activités mais également la composition des membres de l’équipe peuvent évoluer dans le temps afin de pouvoir adresser efficacement les problématiques du moment ou même pour travailler sur les items du Backlog du produit afin de résoudre les problèmes techniques ou non-techniques des équipes.
Deux fausses idées : démêlons le vrai du faux
L’équipe d’intégration – mais… elle n’intègre pas elle-même
Contrairement à son nom, cette équipe n’est pas là à attendre à la fin de la chaîne pour intégrer le travail des autres équipes. Au contraire, elle est là pour anticiper et assurer que les équipes sont capables d’intégrer le produit final elles-mêmes, aussi souvent que possible et au moins une fois par itération. Ceci suppose d’identifier et gérer, minimiser les dépendances techniques entre les équipes.
L’équipe est redevable – mais… ce n’est pas une équipe des managers
La Nexus Integration Team est une instance redevable, coordinatrice et pilote de l’effort. Ce qui est à remarquer, c’est que c’est le but de réussite commune qui prévaut à la composition – on ne veut pas créer un comité de pilotage composé des managers hiérarchiques ou un comité des Scrum-Masters de toutes les équipes. Au contraire. On veut avoir un modèle souple, un réseau de compétences, avec les membres potentiellement choisis ou renouvelés au fil de l’eau dont l’expertise technique ou organisationnelle est en concordance avec l’actualité et la problématique du moment à résoudre.
CoPil ou pas CoPil ?
…telle est la question. En effet, on n’a pas ici un modèle auto-géré et consensuel de N équipes autour de la table ronde qui sont à l’égalité et qui, dans le monde idéal, n’ont pas besoin de gouvernance hiérarchique pour bien s’entendre pour créer le produit à la fin de l’itération. Nexus nous instaure ici une hiérarchie, aussi minimaliste que possible et agile, mais bel et bien une hiérarchie des équipes, transposée dans la monde Scrum.
Faut-il des membres à temps plein ou des membres qui partagent leur temps avec leurs propres équipes ? Cela dépend, à vous de choisir selon circonstances. La Nexus Integration Team, travaille-t-elle sur ses propres items issus du Product Backlog ? Cela dépend – en effet, sur des sujets particuliers, one-shot et relevant de la transversalité et d’intégration commune – oui, cette équipe pourrait prendre la casquette d’une « System Team ». Une explication, formation, outillage sur un outil technique / TDD / BDD / ATDD etc. ? Une mise-en place d’un framework d’intégration / delivery / deploy en continu ? Tout cela peut être géré via cette équipe « task force » avec les membres potentiellement détachés pendant un moment pour le travail d’intérêt global.
Ici, un moyen structurel et légitime est mis en place pour répondre aux demandes de facilitation et de suppression des blocages. Surtout si vos équipes sont plutôt applicatives dans leur nature et n’ont pas d’appétence particulière pour prendre cela en charge. Si ça c’est un CoPil, c’est en tous cas un CoPil qui n’hésite pas à se retrousser les manches, former, montrer l’exemple et mettre les mains à la pâte s’il le faut…
Product Owner est dans la Nexus Integration Team
|
|
Nexus travaille avec un seul Product Backlog, commun pour toutes les équipes. Qui dit un Product Backlog dit aussi un seul Product Owner pour toutes les équipes. Il a le dernier mot sur le contenu du backlog et sur la priorisation de ses items. Ce Product Owner fait partie de la Nexus Integration Team. Il est redevable sur le management du backlog et il est responsable de maximiser la valeur du travail des équipes et du produit intégré dans Nexus. |
Scrum Master de la Nexus Integration Team
|
|
Chaque équipe Scrum a un Scrum Master. Celui de la Nexus Integration Team ne sera le plus probablement pas entièrement dédié, il pourra partager son temps avec sa propre équipe. De plus, c’est lui qui est responsable d’assurer que tout l’effort Nexus est bien compris et appliqué. On peut dire que c’est une sorte de « Capitan Scrum Master », même si le framework n’utilise pas cette appellation. |
Définition de « Fini »
Une notion intéressante de Définition de « Fini » (Definition of Done) potentiellement hiérarchisée est apportée : toutes les équipes doivent adhérer à une définition du travail accompli commune, celle d’un produit intégré commun.
C’est à l’Équipe d’Intégration Nexus d’assurer que le produit respecte le niveau établi de « Fini » (sans préciser comment exactement y arriver). En revanche, les équipes peuvent se définir une Définition de « Fini » individuelle de leur équipe, potentiellement plus stricte que la globale, dans l’esprit « qui peut le plus, peut le moins », où « le moins » est la définition commune. Qui veut customiser, peut le faire, mais en augmentant le niveau de qualité intrinsèque.
ReX et la réalité de l’implémentation ?
La théorie est bien jolie, mais qu’est-ce que ça donne en pratique ? Pour un témoignage sur un use-case réel et réussi, nous vous invitons à regarder la vidéo depuis le site Scrum.org sur l’implémentation du Nexus chez Capital One, le focus sur la Nexus Integration Team est dans le timestamp 17:08-20:45. À noter qu’une sensibilisation très rapide – une présentation pendant un déjeuner – a suffi pour expliquer à tous les coéquipiers le fonctionnement en Nexus. Dans ce ReX, la Nexus Integration Team a agi en tant que facilitateur et un coach technique qui fluidifiait l’effort et assurait de garder le cap vers la bonne direction. Les membres de l’équipe étaient, en plus du Product Owner et du Scrum Master des « Tech Solution Owners » et, comme on le précise dans la vidéo, pas les managers. On y ajoutait éventuellement aussi les représentants de chacune des équipes. Cette équipe assurait que l’exécution des Sprints se passe bien, elle gérait aussi un support externe nécessaire au-delà du dispositif Nexus et aidait à préparait en avance le contenu pour les prochains Sprints. On peut juste ajouter que cette composition donnait au Nexus chez Capital One une équipe capable de gérer les aspects « Build the Right Product / Build the Product Right » dans une instance standardisée et légitime.
Ce qu’il faut retenir de la Nexus Integration Team
Nexus, le framework à l’échelle pour 3-9 équipes travaillant en Scrum, ajoute une équipe transverse d’intégration – la Nexus Integration Team. Elle a la légitimité et le pouvoir de mener à bien l’effort global l’intégration des incréments de valeur de toutes les équipes, tout en s’assurant que les équipes sont autonomes sur l’intégration dans leur périmètre. Comme le framework est simple à comprendre car il reprend le fonctionnement de Scrum, il ne sera pas compliqué pour les équipes de comprendre la place et le rôle de la Nexus Integration Team – elles ne feront qu’un rapprochement à leur fonctionnement déjà existant de leur équipe en Scrum et le transposeront à un niveau supérieur des équipes, plaçant la Nexus Integration Team en tant que facilitateur de l’effort Nexus.