Nexus™ : Je me présente, je m’appelle Nexus…

Nexus™ est un framework (cadre) d’agilité à petite / moyenne échelle venant de Scrum.org. Pourquoi devrait-il nous intéresser ? Sa force réside dans sa simplicité intuitive qui vient du parallèle à Scrum. Avec Nexus, pas besoin de grandes préparations durant des jours ou des semaines pour son lancement – l’introduction officielle tient sur 4 pages et un briefing des équipes d’une heure suffit, cf. REx Capital One.

En même temps, selon le dernier State of Agile Report (14ème report en 2020), 3 % seulement des implémentations agiles passées à l’échelle utilisent Nexus™. On remarque une légère progression car l’année précédente il représentait 2 % et encore moins l’année d’avant – 1 %.

 

Intéressons-nous donc au Petit Poucet de la discipline qui vit aujourd’hui relativement inaperçu et caché dans l’ombre des autres frameworks. En effet, il est petit, mais bien taillé – uniquement le strict nécessaire pour la cadence et la synchronisation est ajouté afin que votre passage à l’échelle soit une réussite. Si vous recherchez un moyen de synchroniser une quarantaine de personnes autour d’un produit qu’il faut délivrer rapidement, ce framework est peut-être celui qu’il vous faut !

Premier article d’une mini-série – ajuster votre niveau de lecture

Nous aimerions vous présenter ce framework à travers de quelques posts. En effet, une vue générale et brève de ce premier article suffira à certains tandis que d’autres voudront comprendre des détails plus en profondeur. Traiter les deux niveaux de lecture nous paraissait approprié. Nous vous avons donc préparé la mini-série suivante :

• Nexus™ : Je me présente, je m’appelle Nexus… (cet article) – 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. (sera publié le 28/12/2020)

Motivation – le « pourquoi » ?

Vous êtes dans une entreprise de taille moyenne ou dans un département d’une grande société, vous vous reconnaissez peut-être dans cette situation :

Nous nous sommes lancés dans l’agilité, nous avons un petit nombre d’équipes qui travaillent sur le même produit. Nous avons adopté Scrum. Au niveau des équipes, on a des résultats, on tient le cadre.

En même temps, les équipes sont relativement silotées, chacune garde son périmètre, borné par la technologie ou la division de l’entreprise. Sans surprise, le rythme n’est pas synchronisé, délivrer un ensemble fonctionnel unique en fin des sprints est problématique voire impossible. Nous découvrons beaucoup d’anomalies qu’au moment de l’intégration complète et donc trop tard. Se lancer dans des sujets de fond inter-équipes vous paraît difficile et douloureux.

L’enthousiasme premier de la démarche agile commence à se dissiper, les premières voix qui disent « c’était mieux avant » commencent à apparaître.

Alors vous vous posez la question : comment régler le problème ? Est-ce le moment de passer à l’échelle ? Mais mon entreprise n’est pas une multinationale, ne peut-on pas faire juste quelque chose de petit, à taille humaine, simple à faire adopter à mes équipes ? On a peut-être une des réponses pour vous !

Vous avez dit Scrum ? Nexus est l’exosquelette de Scrum !

Le Framework Nexus™ va rassurer ceux qui sont convaincus par le fonctionnement de Scrum et par ses bénéfices « humain » et « produit ». En effet, Nexus a été imaginé par (entre autres) Ken Schwaber, un des co-fondateurs de Scrum qui le décrit lui-même comme « l’exosquelette de Scrum ». Ce framework porte les principes Scrum à un niveau plus élevé et se dit adapté pour (plus ou moins) 3 à 9 équipes Scrum qui travaillent sur le même Backlog. Le chiffre de la limite haute – 9 – est approximatif et vient sûrement du fait de pouvoir réunir les représentants de toutes les équipes autour d’une table « à deux pizzas ». C’est-à-dire la taille d’un groupe qui agit encore comme une seule équipe à l’échelle transverse et qui peut encore assurer les discussions rapides et productives.

Avec Nexus, on reste sur une petite échelle (a priori) qui peut commencer à une quinzaine, vingtaine de coéquipiers au total mais qui peut monter également à des dispositifs plus conséquents avoisinants plusieurs dizaines de personnes. Que rajoute-t-on par rapport à un Scrum classique ? La réponse est cachée dans le nom « nexus »:

Un « nexus » est une connexion, généralement là où de multiples éléments se rencontrent.
(source : Wikipédia)

On apporte la connexion entre les équipes ! L’image suivante résume le principe du fonctionnement du Nexus.

On reconnaît le schéma classique d’un Scrum – le Backlog qui est consommé à travers des itérations, les cérémonies, un incrément de valeur intégré au moins une fois par Sprint et une boucle de rétroaction pour l’amélioration continue. Pour passer à l’échelle, le framework va nous ajouter les instances et les mécanismes de synchronisation entre les équipes. Cela de façon simple et presque intuitive car chaque cérémonie est modifiée afin d’assurer la collaboration face-à-face de façon structurelle. Ainsi, les informations transverses circulent et les remontés des problèmes se produisent comme dans une équipe, sauf qu’ici, on raisonne à un niveau supérieur – celui d’équipe des équipes. Et c’est exactement ce que nous cherchions !

• Le Sprint Planning est enrichi par la phase amont Nexus qui planifie, avec les représentants de chaque équipe, les objectifs transverses du Sprint et qui les transmettent de façon descendante dans chacune des équipes.
• Le Daily Scrum à sa cadence quotidienne est aussi enrichi de la phase amont transverse : les représentants appropriés des équipes se réunissent et identifient les problèmes transverses. Puis, ils rapportent les informations nécessaires pour la bonne intégration globale vers leurs équipes respectives pour un Daily Scrum classique.
• La Sprint Review Nexus est une cérémonie commune globale de toutes les équipes qui remplace celles des équipes. Ceci est un point à relever car cette cérémonie remplace bel et bien les reviews locales au profit de l’ensemble. Elle fait à la fois le point sur l’incrément du produit intégré et livrée mais elle sert également pour aligner l’information globale sur le produit. En effet, c’est la seule cérémonie ou toute la grande équipe Nexus est présente au même moment. Bien sûr, elle peut être délicate à organiser si plusieurs dizaines de personnes sont impliquées.
• La Rétrospective standard d’une équipe Scrum s’enrichit de deux étapes supplémentaires : une étape transverse en amont (qui identifie les problèmes transverses) qui nourrit par la suite les rétrospectives classiques des équipes. Leurs résultats sont consolidés dans une autre étape transverse en aval : ceci pour pouvoir consolider les actions transverses, mais en incluant le retour local des équipes. On a donc bien 3 phases dans la rétrospective en Nexus.

Spécificité de Nexus – Équipe d’Intégration Nexus

Une nouvelle instance apparaît avec Nexus – une équipe Scrum transverse appelée l’« Équipe d’Intégration Nexus ». Nous pourrions être tentés de l’assimiler à un rôle de Scrum Master des équipes, mais ce ne serait pas tout-à-fait exact, sa responsabilité est plus grande et élargie, elle a un triple objectif :

• résoudre les problèmes systémiques transverses,
  
• assurer la bonne implémentation du framework agile Nexus au niveau d’organisation
  
• mais également d’assurer l’intégration du produit à la fin de chaque sprint – en effet, elle en est redevable.

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 Scrum Master d’une ou plusieurs autres équipes).

De ce fait, elle a la vocation de coordonner, de coacher et de superviser l’effort de toutes les équipes impliquées, mais aussi d’implémenter (coder), si nécessaire, les parties transverses du produit. Un autre article de cette mini-série décrit cette équipe plus en détail.

Anti-thèse

Y a-t-il des inconvénients ou des cas pour lesquels Nexus ne serait pas le bon choix ? Ou les zones d’ombre où tout n’est pas entièrement noir ou blanc mais plutôt gris ? Certainement.

• Ce framework suppose a priori que toutes les équipes travaillent en Scrum. Et si une ou plusieurs d’elles sont plutôt orientées Kanban à cause de la nature du travail (e.g. arrivée régulière d’une demande imprévisible) ? Peut-on se permettre de faire une adaptation et d’intégrer également les équipes Kanban à côté des équipes Scrum ? Leur proposer la même cadence et les mêmes cérémonies? C’est peut-être une occasion d’implémenter le Scrumban. En même temps, si les équipes ne sont pas Scrum, ce n’est plus du Nexus…
• Les puristes des équipes dédiées peuvent également critiquer les personnes potentiellement partagées entre l’équipe d’intégration et leur propre équipe. Les coéquipiers qui sont sur plusieurs sujets à la fois peuvent perdre le focus à cause du changement du contexte et peuvent ne pas être efficaces dans leurs propres équipes. Mais comme toutes les équipes ont un objectif commun ceci ne devrait pas poser de problème.
• Également, si vous avez 2 (ou plus) produits distincts avec 2 POs (ou plus) dédiés – c’est-à-dire plusieurs flux de valeur entrants qui se partagent les mêmes équipes et il ne vous est pas possible d’unifier ces plusieurs Product Owners en un seul décideur, vous rencontrerez sûrement des difficultés à l’adoption de ce cadre.
• À noter que dans certains témoignages, on suggère l’utilisation de Nexus en tant qu’une possible étape intermédiaire pour le passage au framework LeSS. En effet, dans des situations particulières, Nexus faciliterait l’adoption de l’agilité à l’échelle, e.g. difficultés dans la conduite de changement vers l’agilité ou l’impossibilité de composer les feature-teams optimales en immédiat.
• Peut-on prendre qu’une sous-partie des concepts du Nexus ? Le guide officiel mentionne cela explicitement : vous pouvez implémenter Nexus partiellement, mais le résultat ne sera pas un Nexus.

À emporter…

Ce cadre est peut-être la solution convenable pour la plupart des petites et moyennes structures où un produit peut être encore géré par un Product Owner unique, mais qui nécessite plusieurs équipes (3 à 9) à sa réalisation. Il :

• est (aussi) Scrum.
• est facile à expliquer, rapide à amorcer et à faire adopter – pas besoin de longues formations ou une longue période de « cadrage » préliminaire. En même temps – il s’adresse à des équipes qui connaissent déjà Scrum et pour lesquels le changement de mindset est déjà acquis. Si vous commencer de zéro, ne sous-estimer pas la phase explicative et accompagnez les équipes dans la durée.
• apporte la solution à la synchronisation du travail entre les équipes.
• adresse la problématique des réunions et cérémonies communes, déjà connues du Scrum, mais ici portées à l’échelle via une collaboration transverse.
• identifie une instance collective de pilotage, légitime pour prendre des décisions globales et redevable sur l’intégration du produit – la Nexus Integration Team.

Sans surprise, on retrouve les concepts similaires aussi dans d’autres frameworks à l’échelle. Dans le cas du Nexus, il est intéressant d’étudier comment et lesquelles nous ont été prescrits par Scrum.org dans le Nexus Guide.

Pour la suite…

La suite de notre mini-série va aller plus en détails du framework et va aborder :

• Nexus™ : Cérémonies à l’échelle – dis-moi, qu’est ce qui change et pourquoi ?