Quand une seule équipe Scrum ne suffit plus : introduction simple à Nexus
Une seule équipe Scrum fonctionne bien, jusqu'à un certain point. Dès qu'un produit dépasse ce que huit ou neuf personnes peuvent bâtir, les organisations ajoutent des équipes — et c'est là que les ennuis commencent. Trois équipes qui construisent en silence des morceaux du même produit produiront trois choses qui ne s'emboîtent pas. Nexus, le cadre de mise à l'échelle publié par Scrum.org, existe précisément pour résoudre ce problème d'intégration. Alors que de nombreuses équipes s'adaptaient encore au travail à distance et hybride au début de 2021, la discipline qu'apporte Nexus s'est révélée plus précieuse, pas moins.
Nexus est volontairement minimaliste. Si vous comprenez déjà Scrum, vous pouvez apprendre Nexus en un après-midi. Il ne remplace pas Scrum; il enveloppe une fine couche de coordination autour de trois à neuf équipes Scrum afin qu'ensemble, elles livrent un seul Incrément intégré à partir d'un unique Backlog de produit.
Ce qui change réellement par rapport au Scrum ordinaire
Les équipes conservent leurs événements, rôles et artéfacts Scrum habituels. Nexus ajoute peu de choses par-dessus, et l'ajout le plus important est l'accent mis sur l'intégration — s'assurer que le travail combiné de toutes les équipes converge réellement au moins une fois par Sprint.
L'équipe d'intégration Nexus. Un petit groupe responsable de garantir qu'un produit utilisable et intégré est produit à chaque Sprint. Elle comprend généralement l'unique Product Owner, un Scrum Master et des membres qui aident les équipes à régler les problèmes inter-équipes. Elle accompagne et soutient plutôt que de commander.
Un seul Product Owner, un seul Backlog de produit. Peu importe le nombre d'équipes, il y a un seul Product Owner et un seul Backlog ordonné. C'est ce qui empêche les équipes de partir dans des directions différentes.
Des événements Nexus qui encadrent le Sprint. Une planification de Sprint Nexus, un Daily Scrum Nexus axé sur les risques d'intégration, une revue de Sprint Nexus de l'Incrément entier, et une rétrospective de Sprint Nexus qui examine le système, pas une seule équipe.
Le raffinement inter-équipes. Les équipes raffinent ensemble le Backlog de produit suffisamment pour repérer tôt les dépendances et décider quelle équipe fait quel travail, avant que la dépendance ne devienne un blocage.
Pourquoi l'intégration est l'essentiel
La plupart des échecs de mise à l'échelle ne sont pas des manques d'effort — ce sont des problèmes d'intégration découverts trop tard. Une dépendance qui surgit le dernier jour du Sprint coûte cher; la même dépendance repérée pendant le raffinement inter-équipes coûte peu. Nexus pousse cette découverte le plus tôt possible et rend un groupe responsable du résultat. L'unique Incrément intégré, produit à chaque Sprint, est la mesure honnête qui dit si les équipes travaillent vraiment comme un seul effort produit.
Rendre les dépendances visibles durant le raffinement, pas au moment de l'intégration.
Conserver un seul Backlog de produit pour que les priorités ne se divisent pas entre équipes.
Intégrer fréquemment — une construction intégrée quotidienne vaut mieux qu'une surprise en fin de Sprint.
Laisser l'équipe d'intégration Nexus accompagner et non surveiller; la responsabilité reste aux équipes.
Une mise en garde pratique : Nexus s'impose quand vous avez réellement besoin de plusieurs équipes sur un même produit. Ajouter des équipes pour aller plus vite produit souvent l'effet inverse — le coût de coordination augmente avec chaque équipe. Mettez à l'échelle parce que le produit l'exige, gardez le nombre d'équipes aussi bas que possible, et traitez l'intégration comme une activité de premier plan plutôt qu'une réflexion après coup.
Si votre organisation passe d'une seule équipe de livraison à plusieurs et que les coutures commencent à se voir, le conseil de XNM en exécution de programmes et de projets peut vous aider à mettre en place la coordination et la discipline d'intégration avant que les fissures ne s'élargissent.