Nexus, c'est quoi ?

Carte d’identité

Nom : Nexus Créateur : Ken Schwaber Documentation de référence : https://www.scrum.org/resources/nexus-guide Cible : un produit de développement logiciel avec trois à neufs équipes Scrum impliquées

Avant d’aller plus loin

Il est fortement conseillé de connaître les bases Scrum avant de lire cet article. Par ici pour la documentation officielle et là pour une présentation succincte.

Tout pour l’intégration

Nexus se veut complémentaire à Scrum en ajoutant juste ce qu’il faut pour adresser les principaux problèmes qui apparaissent quand plusieurs équipes doivent travailler ensemble : la communication, les dépendances et la capacité à livrer un incrément intégré.

À quoi ça ressemble ?

À l’échelle du produit, c’est le Scrum classique : un PO unique qui donne la vision, un Backlog produit, un Sprint, un planning de Sprint, une revue de Sprint, une rétrospective, un incrément et une définition de “Fini”.

“L’équipe de développement” est constituée de trois à neuf équipes de développement chacune accompagnée d’un Scrum master.

La différence la plus visible avec Scrum est l’ajout d’une équipe d’intégration. Sont but est de coordonner, coacher et superviser l’application de Nexus. En ce sens elle est à Nexus ce que le Scrum master est à Scrum.

Scrum à l’échelle du Nexus

Nexus redéfinit les cérémonies et artéfacts de Scrum pour que, en plus de leurs objectifs définis dans le guide Scrum, ils gèrent les dépendances et assurent la livraison d’un incrément intégré et “Fini”.

Le **Backlog de Sprint **Nexus, en tant que Backlog de Sprint partagé par toutes les équipes sert à matérialiser les dépendances entre tous les items du Backlog produit traités lors du Sprint.

Le raffinement de Backlog Nexus sert à identifier les dépendances.

La planification de Sprint Nexus se divise en deux phases :

1. comme la planification Scrum, le PO discute avec toute l’équipe de réalisation (ie. tout le Nexus) ou ses représentants appropriés l’objectif du Sprint et la liste des items à embarquer ; 2. après la répartition des items entre les différentes équipes, chaque équipe finit sa planification dans son coin.

Le **Daily **Nexus se divise en deux phases :

1. entre les représentants appropriés des équipes pour inspecter l’état de l’incrément intégré et les dépendances ; 2. chaque équipe prend en compte les informations issues de la première phase dans son propre daily.

La revue de Sprint Nexus est la revue unique du produit. Elle implique donc tout le Nexus et remplace les revues individuelles.

La rétrospective de Sprint Nexus se divise en trois phases :

1. entre les représentants appropriés des équipes pour se focaliser sur les problèmes qui ont impactés plusieurs équipes ; 2. chaque équipe tient sa propre rétrospective telle que décrite dans le guide Scrum ; 3. à nouveau entre les représentants appropriés des équipes pour s’accorder sur le suivi des actions.

La botte secrète : l’équipe d’intégration

L’équipe d’intégration est une équipe dont l’objectif est d’assurer que les équipes de développement produisent un incrément intégré. Et pour cela, tous les moyens sont bons :

• mise en avant des dépendances ;
  • accompagner les équipes du Nexus pour la mise en œuvre des pratiques et des outils nécessaires pour détecter les dépendances ;
  • mise en avant des problèmes inter-équipes ;
  • résolution des contraintes techniques et non techniques inter-équipes ;
  • accompagner les équipes du Nexus pour la mise en œuvre des pratiques et des outils nécessaires pour intégrer fréquemment leur travail dans l’incrément ;
  • accompagner les équipes du Nexus sur l’application des standards de développement, d’infrastructure ou d’architecture requis par l’organisation.

Pas d’intégration ? Eh non, l’équipe ne réalise pas elle même l’intégration, mais elle travaille pour coordonner, encadrer, identifier les dépendances entre équipes et s’assurer que les meilleures pratiques sont suivies.

L’équipe d’intégration est composée du PO du Nexus, d’un Scrum master et des personnes adéquates pour réaliser sa mission. Ses membres sont souvent aussi membre d’un des équipes Scrum du Nexus mais leur travail au sein de l’équipe d’intégration est prioritaire sur tout autre engagement.

Conclusion

S’il faut résumer Nexus, ce serait Scrum avec plusieurs équipes de développement et une équipe d’intégration pour traiter les problèmes de mise à l’échelle.

Cela fait de Nexus un framework simple qui, en proposant une solution concrète pour la mise à l’échelle, peut rassurer ceux qui ont besoin d’un cadre un minimum directif.

Au cœur du dispositif, l’équipe d’intégration peut, de prime abord, être perçue comme un goulot d’étranglement ou un processus de plus mais en réalité, de par son rôle de servant leader, c’est un outil d’amélioration et d’adaptation pour le Nexus dans son ensemble.

S’il faut trouver à redire, on peut s’attaquer au fait que Nexus soit conçu pour le développement logiciel. Mais en restreignant son champ d’application, son auteur n’apporte-t’il pas une solution plus pertinente ?

On peut aussi regretter que les nombreux retours d’expérience et guides dont se targuent les promoteurs de Nexus ne soient pas disponibles (je n’en ai trouvé moins de 10).

Enfin, Nexus part du principe que les équipes Scrum font déjà du Scrum “professionnel”, c’est à dire qu’elles comprennent et travaillent déjà en accord avec les valeurs et principes de Scrum. Cela peut paraître contraignant mais, en définitive, ce prérequis est commun à tous les frameworks de mise à l’échelle de Scrum.