Qu’est-ce que Nexus ?

← L'équipe Scrum

Qu’est-ce que Nexus ?

L’agilité à léchelle

Nexus est un framework agile destiné à mettre en oeuvre l’agilité à l’échelle et à faire travailler plusieurs équipes Scrum ensemble de manière optimale. Il fait partie des framework agile@scale tel que leSS, SAFe, Scrum of Scrum, Scrum@scale…

Un framework qui étend Scrum de manière naturelle

Le framework Nexus fut créé en 2015 (mis à jour en 2018) par Ken Schwaber(co-créateur de Scrum), David Dame, Richard Hundhausen, Patricia Kong, Rob Maher, Steve Porter, Christina Schwaber, et Gunther Verheyen. Nexus a pour socle Scrum : il étend les événèments de Scrum et rajoute une équipe spécialement pour la gestion du bon déroulement du Nexus, l’Equipe d’Intégration du Nexus. Nexus est fait pour coordonner maximum environ 9 Scrum Team, tout comme Scrum est fait pour coordonner 9 personnes (la limite étant qu’au delà de 9 les interactions sont trop contraingnantes, ce n’est pas une interdiction absolue).

On peut voir avec les schémas ci-dessous la similitude évidente entre Scrum et Nexus.

Composition du Nexus

Chaque équipe Scrum du Nexus a son équipe de développement et son Scrum Master, ou SM, (éventuellement partagé entre deux ou trois équipes selon la maturité de celles-ci). Pour tout le Nexus, il y a un unique Product Owner(PO) et un unique Product Backlog. Chaque équipe a son Sprint Backlog. Il existe en plus un Nexus Sprint Backlog pour plus de transparence dans le Sprint.

Le nouveau rôle comparé à Scrum est l’Equipe d’Integration du Nexus. Elle se compose du PO, d’un SM et de membres d’équipe. Les membres d’équipe ou le SM peuvent très bien appartenir aux équipes de développement ou autres équipes du Nexus, mais le rôle de l’équipe d’intégration prévaudra toujours afin que les problèmes généraux impactant l’ensemble des équipes soient plus facilement résolus.

La mission de l’Equipe d’Integration du Nexus est de coordonner, coacher, and superviser l’ application du Nexus, de Scrum afin que les meilleurs résultats soient obtenus. Elle est responsable que l’Increment Integré du Nexus soit “Done” (réalisé) selon la Definition of Done (définition de fini) du Nexus (boite à outil - lire Defintion of Done), pas forcément livré en production à la fin de chaque Sprint. Toutes les équipes Scrum doivent adhérer à la même Definition of Done afin qu’un Increment Intégré puisse être construit. Mais chaque équipe peut ajouter des standards en plus, selon ses besoins/spécificités.

flux du Nexus

composition des équipes Les équipes appartenant au Nexus s’auto-organisent en tenant compte des interdépendances entre les équipes. Chacune doit s’arranger pour pouvoir être autonome afin de réaliser son travail. Il existe des techniques de facilitations afin d’aider les équipes à bien s’auto-organiser.
Raffinement du Backlog Produit (Product Backlog Refinement) Il faut que des représentants de l’ensemble des équipes soient présents lors du Raffinement afin d’éviter la perte d’information et de mieux pouvoir identifier les interdépendances entre équipes.
Nexus Sprint Planning Le PO et les équipes tentent de constuire une première idée du Nexus Sprint Goal. Ce Nexus Sprint Goal sera construit au long du Nexus Sprint Planning. Les représentants appropriés de chaque équipe Scrum discutent et parcourent le Product Backlog raffinnée puis sélectionnent les Product Backlog items pour chaque équipe. Chaque équipe Scrum planifie son propre Sprint, interragissant avec les autres équipes si opportun. Le résultat est une collection de Sprint Goals qui doivent s’ aligner avec le Nexus Sprint Goal, chaque équipe Scrum Sprint Backlog et le Nexus Sprint Backlog. Le Nexus Sprint Backlog rend transparent le travail de tous les items sélectionnés par les équipes Scrum, ainsi que les interdépendances.
travail de développement On est dans un Sprint Scrum classique pour chaque équipe Scrum.
Nexus Daily Scrum Les représentants de chaque équipe Scrum se rencontrent chaque jour afin d’identifier si il y a des problèmes d’intégration, si il y a eu des problèmes de construction de l’Incrément, si des informations doivent être relayées à travers tout le Nexus. Si il y en a, l’ information est relayée en entrée pour chaque Daily Scrum de chaque équipe Scrum. Les problèmes d’intégration sont à adresser en priorité pendant le Daily Scrum.
Nexus Sprint Review La Nexus Sprint Review est faite à chaque fin de Sprint et remplace les Sprint Review individuelles de chaque équipe Scrum. Cela permet d’avoir un feedback sur l’ Increment Intégré du Nexus construit pendant le Sprint. Toutes les équipes Scrum à travers leurs représentants rencontrent les stakeholders pour la revue de l’ Increment Intégré. Des techniques peuvent être utilisées afin d’obtenir un maximum d’informations des stakeholders. Des adaptations peuvent être faites au Product Backlog menant à un Product Backlog révisé.
Nexus Sprint Retrospective Les représentants de chaque équipe Scrum se rencontrent afin d’identifier les challenges en commun. Cette étape est importante afin de rendre bien transparents les défis/problèmes en commun. Puis, chaque équipe Scrum tient sa Sprint Retrospective individuelle. Puis les représentants de chaque équipe se rencontrent encore afin de profiter des remarques et suggestions bottom_up sur les défis à venir. Les équipes se mettent aussi d’accord sur les améliorations à faire en priorité ainsi que sur les moyens pour suivre ce qui a été décidé. En particulier (ceci n’est qu’un exemple) voici quelques questions récurrentes:

y a t il du travail non fait ? le Nexus génère-t-il de la dette technique ?
est-ce que tous les artefacts, en particulier le code, s’ intègre fréquemment avec succès ?
est-ce que le logiciel est construit, testé, deployé assez souvent de manière à prévenir l’accumulation d’interdépendances ?

En savoir plus sur le famework Nexus : Présentation Nexus

A lire sur le même thème :