Trois équipes, un produit : ce que Nexus a appris à un programme en convalescence
Lorsqu'une organisation de services régionaux a relancé au début de 2021 un programme logiciel à l'arrêt, elle comptait trois équipes Scrum qui se débrouillaient bien chacune de leur côté. Le problème, c'est qu'elles construisaient un seul produit, et que « chacune de leur côté » était devenu, en douce, la difficulté même. Des livraisons qui prenaient deux semaines en prenaient désormais six. Chaque Sprint se terminait par une semaine frénétique de fusion de code, de tests et de reproches. Les équipes n'étaient pas mauvaises en Scrum; elles y excellaient en vase clos, ce qui est tout autre chose.
La direction a lu le cadre Nexus de Scrum.org et a choisi de l'essayer plutôt que d'inventer une énième couche de coordination maison. Nexus est volontairement léger : il prend de trois à neuf équipes Scrum travaillant sur un même produit, ajoute une nouvelle responsabilité — l'équipe d'intégration Nexus — et un nouveau point de mire événementiel, et demande à tous de traiter l'intégration comme une préoccupation de premier plan plutôt que comme une surprise de fin de Sprint. Voici ce qui a réellement changé, raconté simplement, car le cadre sur papier et le cadre dans un atelier hybride, en partie à distance, ne sont pas la même expérience.
Première leçon difficile : l'intégration est l'affaire de tous, mais quelqu'un doit en répondre
L'équipe d'intégration Nexus n'est pas une équipe distincte de spécialistes qui retire du travail aux autres. C'est une responsabilité de coordination, généralement assurée par des personnes qui siègent aussi dans les équipes Scrum régulières, dont le Product Owner et souvent les ingénieurs les plus chevronnés. Leur rôle est de veiller à ce que l'incrément combiné se rejoigne vraiment. Dans le programme en convalescence, l'erreur initiale a été de traiter cela comme une tâche secondaire à temps partiel. Le travail d'intégration perdait toujours face au travail de fonctionnalités, car ce dernier avait un responsable visible et pas l'intégration. Une fois que l'organisation a nommé des personnes précises, leur a accordé du temps protégé et a fait de l'incrément intégré la seule chose qui comptait comme « terminée », les livraisons de six semaines ont recommencé à raccourcir.
Il a été utile de remettre l'époque en contexte. Au sortir des perturbations de l'année précédente, avec des gens encore partagés entre la maison et le bureau et des délais d'approvisionnement peu fiables, la tentation était de laisser chaque équipe optimiser son petit monde. Nexus s'oppose volontairement à cet instinct.
Les dépendances entre équipes apparaissent à la planification, ou elles vous tendent une embuscade plus tard
Nexus avance la découverte des dépendances. Avant que les équipes ne planifient leurs Sprints individuels, des représentants se réunissent pour examiner ensemble le Product Backlog et repérer où le travail d'une équipe dépend de celui d'une autre. Ce n'est pas une cérémonie lourde; c'est une séance de travail qui produit une vision partagée de ce qui doit s'intégrer, et dans quel ordre.
Rendez les dépendances visibles tôt. Affinez et décomposez les éléments du backlog suffisamment pour que les liens entre équipes soient évidents avant la planification de Sprint, et non découverts en cours de Sprint.
Séquencez d'abord les intégrations risquées. Si deux équipes doivent relier un service partagé, planifiez ce raccordement tôt dans le Sprint pour qu'un échec laisse le temps de se reprendre.
Intégrez souvent, pas à la fin. Visez un incrément intégré au moins une fois par jour; le Daily Scrum Nexus existe pour repérer les problèmes d'intégration, pas seulement pour suivre les progrès individuels.
Gardez l'incrément livrable en permanence. Une Definition of Done unique pour toutes les équipes maintient une qualité constante et empêche les raccourcis d'une équipe de casser l'ensemble.
Ce que les chiffres et la salle ont montré
En quelques Sprints, les signes visibles ont changé. Le Daily Scrum Nexus — où les représentants se concentrent sur les problèmes d'intégration avant que les équipes ne tiennent leurs propres Daily Scrums — détectait les problèmes tant qu'ils étaient encore peu coûteux à corriger. La revue de Sprint Nexus présentait aux parties prenantes un produit intégré au lieu de trois démonstrations qui ne s'emboîtaient pas tout à fait. La rétrospective a cessé d'être une liste de griefs entre équipes pour devenir une conversation sur le système qu'elles partageaient.
Mettre à l'échelle ne signifiait pas ajouter du processus; cela signifiait éliminer les angles morts entre les équipes.
L'incrément intégré, et non la production de chaque équipe, est la seule mesure honnête du progrès.
Le travail hybride a fait de la surcommunication un atout, pas un coût — des dépendances partagées et visibles valent mieux qu'une coordination de couloir qui n'existait plus.
L'organisation n'est pas devenue un modèle de Nexus du jour au lendemain, et elle n'en avait pas besoin. L'intérêt du cadre est modeste et utile : préserver l'esprit léger de Scrum tout en donnant à plusieurs équipes une façon disciplinée de livrer une seule chose ensemble. La discipline réside dans l'intégration, et l'intégration, c'est le travail.
Si votre programme compte de bonnes équipes qui peinent à livrer comme une seule, le conseil en réalisation de programmes et de projets de XNM peut vous aider à mettre en place la bonne coordination — et la bonne responsabilité.