Vue détaillée sur les événements Nexus
Nexus est un framework (cadre) d’agilité à petite / moyenne échelle venant de Scrum.org. Selon le dernier State of Agile Report (14ème report en 2020), 3 % seulement des implémentations agiles passées à l’échelle utilisent Nexus (l’année précédente il représentait 2 % et encore moins l’année d’avant – 1 %). Cet article se focalise sur ses événements (« cérémonies »).
Un article d’une mini-série – ajustez votre niveau de lecture
Nous vous présentons ce framework au travers de quelques articles. Celui-ci explique en quoi exactement les cérémonies spécifiques à Nexus sont différentes par rapport à un Scrum standard. Si vous cherchez plutôt une vue générale et brève ou, au contraire, d’autre détails, n’hésitez pas à consulter nos autres articles de la mini-série :
- Nexus : Je me présente, je m’appelle Nexus… – la vue générale sur le framework.
- Nexus : Cérémonies à l’échelle – dis-moi, qu’est ce qui change et pourquoi ? (cet article)
- Nexus : Rôle du Product Owner à l’échelle du Nexus.
- Nexus : Nexus Integration Team – nouveauté, mais rien de surprenant.
Cérémonies Événements à l’échelle et la cadence unifiée
Tout d’abord, il faut ajuster le vocabulaire. On le dit haut et fort – on entend souvent parler des « Cérémonies agiles » en tant que réunions régulières timeboxées aux objectifs particuliers dans le Scrum. En effet, ni Scrum Guide, ni Nexus Guide n’utilise ce terme « Cérémonie » de façon formelle, le terme « Événements » (« Events » en anglais) est privilégié. À l’échelle, parler des « événements » prend tout son sens – on ne sacralise pas le déroulement d’un « cérémonial », on veut que certains événements prescrits se produisent pour la bonne planification et du déroulement du travail, de la collaboration et de la satisfaction de tous.
Parler de Nexus, c’est surtout parler de la cadence unifiée. Une seule durée de Sprint – celle du Nexus – donne le rythme à toutes les équipes. Si on aligne la cadence, le passage à l’échelle est plus simple car, si on fait un parallèle avec la musique, tout le monde joue avec son propre instrument, mais en se servant du même métronome commun. Mais démultiplier l’effort, ce n’est pas seulement l’histoire de mettre des équipes au travail en parallèle, il nous faut aussi des instances de synchronisation transverses et des objectifs communs. Pour y arriver, Nexus modifie chaque événement Scrum standard. Dans la plupart des cas, il les enrichit par des suppléments « Nexus » qui assurent l’échange d’information, la prise de décision, la levée des risques et la fixation des objectifs.
Concernant les participants aux événements à l’échelle, Nexus raisonne par défaut avec des représentants des équipes. En revanche, certains événements sont recommandés en mode plénière – comme le Nexus Sprint Planning ou la Nexus Sprint Review – car ils permettent de donner la même information globale à tous et en même temps. Les autres sont prescrits avec les représentants des équipes. La représentation est une notion cruciale ici car elle permet de retrouver l’efficacité quotidienne à l’échelle. Elle permet également de construire indirectement la confiance entre les coéquipiers, car un ou plusieurs représentants doivent se positionner dans le rôle de porte-paroles (et potentiellement décisionnaires) de toute l’équipe.
Pour respecter la cadence unifiée, les événements des différentes équipes devraient pouvoir se tenir idéalement en même temps. Dans la pratique, on retrouvera toujours des difficultés organisationnelles ordinaires pour tenir le tout « en même temps ». Vous les avez peut-être déjà rencontrées – comment trouver des salles de réunion sur un même créneau (trivial si on passe entièrement au numérique) ou comment rendre l’agenda d’un seul Product Owner unique disponible à toutes les équipes en un seul instant. Notamment si on veut qu’il assiste à la Rétrospective de chacune des équipes ou à leurs Daily Stand-up Meetings (sans rentrer dans le débat si oui et de quelle façon un PO assiste au Daily de l’équipe).
Ici, Nexus ne donne pas des prescriptions fortes et il faudra ajuster selon votre contexte. À l’échelle, on ne peut qu’affirmer la vision de construction des équipes autonomes où le besoin de solliciter le Product Owner sera principalement canalisé aux réunions produit (Backlog Refinement) et aux événements Nexus à l’échelle, le rendant donc dispensable des Dailies et des Rétrospectives ordinaires des équipes. Tout en laissant l’auto-organisation de l’équipe à elle-même, mais avec la possibilité d’inclure le Product Owner aux discussions et aux décisions d’équipe si besoin.
Product Backlog Refinement
En parcourant le schéma global ci-dessus de gauche à droite, on voit le principe de construction de produit par incréments intégrés (et potentiellement livrables), comme dans un Scrum standard. Toute la demande est centralisée dans un seul Product Backlog global, affiné dans un « Product Backlog Refinement » :
Nexus n’impose pas la forme et vous laisse le choix du nombre, de fréquence, de durée et de la bonne audience tout en ayant à l’esprit que l’affinage devrait s’effectuer idéalement en continu. L’objectif, en revanche, est bien défini et est dual, dans l’esprit de transparence :
- comprendre et décomposer la demande afin d’identifier et minimiser (voire écarter) les risques et les dépendances entre les équipes,
- prévoir quelle équipe va délivrer quel Product Backlog Item – on voit ici la préparation fine de la demande qui passe par la préparation de petits morceaux de fonctionnalités, potentiellement déjà pré-assignés à des équipes particulières. On voit émerger, en collaboration avec les équipiers Nexus, une sorte de « coloration par équipe » du Product Backlog ou une « coloration par domaine d’expertise » des équipes capables de gérer un type de demande.
Cette préparation se fait à partir des demandes grandes et vagues, potentiellement multi-équipe, vers les morceaux petits et actionnables par une seule équipe et en un seul Sprint. L’affinage peut continuer à l’échelle d’une équipe, comme dans un Scrum classique. La bonne granularité des items et leur indépendance peut largement accélérer à la fois la planification mais surtout la construction incrémentale globale.
Nexus Sprint Planning
A partir d’un Product Backlog global déjà affiné pour toutes les équipes, on prépare le contenu du Backlog d’une itération Nexus lors d’un « Nexus Sprint Planning ». L’objectif de cet événement est de coordonner l’effort de toutes les équipes pour le prochain Sprint, par défaut en sollicitant les représentants des équipes et le Product Owner.
Le Nexus Sprint Planning est présenté comme composition de deux parties distinctes :
- la première partie de planification macroscopique et transverse,
- la deuxième partie qui correspond aux Sprint Plannings standard Scrum de chacune des équipes.
C’est lors de la première partie « Nexus » du Sprint Planning que les représentants choisissent les éléments à travailler (les PBIs – Product Backlog Items) du Backlog global pour leurs équipes respectives, tout en prenant en compte les dépendances et les risques. Le pré-requis pour la réussite de cette partie Nexus est un Backlog déjà correctement affiné et priorisé, avec les dépendances déjà pré-identifiées voire minimisées. Le product Owner est positionné ici dans le rôle de fournisseur de connaissances sur le domaine fonctionnel et en tant que guide pour les décisions de priorisation. Ce sont les représentants des équipes qui valident et modifient l’ordonnancement du travail des équipes. Pour faciliter la communication globale unifiée, le framework recommande la participation de tous les coéquipiers. Ceci reste une recommandation que vous pouvez adapter à votre contexte. Les raisons sont à discuter, tout en en gardant en tête les principes du Manifeste Agile.
Les participants de la première partie « Nexus » discutent avec le Product Owner et s’accordent également sur un objectif commun – « Objectif du Sprint Nexus ». En effet, l’Objectif du Sprint, en tant qu’outil d’alignement et de communication du besoin utilisateur vers les collaborateurs, prend tout son sens quand vous passez à l’échelle. À l’échelle, il faudra s’aligner sur l’objectif commun de plusieurs dizaines de personnes pour pouvoir tirer ensemble vers la même direction. On voit pourquoi il serait important d’organiser cette événement avec tout le monde – l’alignement sur l’objectif devrait être décidé et proclamé par la grande équipe Nexus entière pour que l’adhésion à l’effort commun soit la meilleure.
Une fois que le travail pour chacune des équipes est compris du côté macroscopique, chaque équipe procède à la deuxième partie – le Sprint Planning standard Scrum. Elles planifient et configurent leur propres vues sur le Backlog global, en concordance, bien sûr, avec les autres équipes et en prenant en compte les dépendances identifiées. Elles définissent les objectifs des Sprints pour chacune des équipes, tout en s’accordant avec l’objectif global. A l’instar des OKR (méthode de management d’entreprise Objectif Key Result, mais dont l’explication dépasse cet article), on voit les objectifs déclinés de façon hiérarchisée dans le périmètre Nexus de l’entreprise. C’est clairement du top-down piloté par objectifs et affiné par les équipes.
De cette façon, à la fois commune et distribuée, Nexus fait ressortir toutes les dépendances, permettant de planifier le travail facilement, tout en synchronisant l’effort autour des objectifs communs. Le résultat du Nexus Sprint Planning est le Backlog de l’Itération qui est à la fois global (Nexus) mais qui permet aussi de visualiser les dépendances locales, propres à chacune des équipes. Le même raisonnement peut être apporté aux Objectifs des Sprints des équipes qui sont ainsi alignés avec l’Objectif du Sprint Nexus.
Nexus Daily Scrum
Pour assurer l’exécution transverse du Sprint, au quotidien, les représentants de chaque équipe se réunissent et identifient les problèmes transverses d’intégration pendant une réunion dédiée « Nexus Daily Scrum ». Puis, ils rapportent les informations collectées vers leurs équipes respectives afin de les prendre en compte dans leurs planifications des tâches quotidiennes. Dans ce Nexus Daily Scrum, on se focalise sur l’intégration et la synchronisation transverse et on se pose donc ces 3 questions :
- Qu’est ce qui a été correctement intégré la veille ? Si non, pourquoi ce n’a pas été intégré ?
- Quelles nouvelles dépendances ont été identifiées ?
- Quelle information devrait être partagée aux équipes de façon transverse ?
Cette réunion est utilisée comme un point d’inspection de la progression des équipes vers l’Objectif du Sprint Nexus et d’ajustement selon l’information la plus récente.
La causalité « Nexus Daily d’abord » puis « Daily des équipes » fait beaucoup de polémique – pourquoi la partie transverse en premier si les équipes n’ont pas encore remonté de problèmes ? Faire « Nexus avant », puis « Daily équipe » et à la fin « Nexus après », ne serait-ce plus logique ? À vrai dire, ça serait excessif, surtout que le « Nexus après » ne peut plus changer grande chose pour l’équipe qui a déjà fait sa synchronisation journalière.
Au quotidien, si les équipiers travaillent ensemble, ils connaissent les douleurs et les points de blocages extra-équipe car ils les découvrent au fil de l’eau. Il est donc naturel qu’un représentant de l’équipe les remonte au plus tard le lendemain à l’instance prévue à cet effet. Un éventuel ajustement ou une repriorisation pour la grande équipe Nexus peuvent donc être effectués. Vu que Nexus coordonne les équipes via l’Objectif du Sprint Nexus commun, il ne devrait pas être difficile de transposer les ajustements transverses, souvent liés à l’intégration de l’ensemble, vers le travail du quotidien des équipes.
Nexus Sprint Review
À la fin de chaque Sprint, toutes les équipes participent à la « Nexus Sprint Review » commune impliquant le Product Owner et les diverses parties prenantes. La présentation des incréments et le recueil d’un retour sur le produit est effectué. Les ajustements sur les tâches ou sur les priorités du Backlog commun sont opérés par le Product Owner.
Il faut bien le noter – cette grande réunion Nexus Sprint Review à laquelle participent toutes les équipes remplace les Sprint Reviews individuelles d’un Scrum classique. En effet, c’est cette intégration de l’ensemble que l’on cherche à revoir et à démontrer aux parties prenantes afin de collecter leur retour et d’ajuster le Backlog pour la prochaine itération. On se focalise donc sur les travaux d’ensemble et sur l’intégration de l’ensemble.
Dans les dispositifs qui comptent beaucoup de collaborateurs, démontrer tout le travail accompli individuellement par les équipes peut s’avérer compliqué et chronophage. L’exercice d’organisation de cette réunion peut donc être non-trivial, surtout si on a beaucoup de parties prenantes et beaucoup d’équipes. Une sélection des sujets à présenter par ordre d’importance et des techniques particulières de récolte des retours, de prise de parole et de communication seront peut-être nécessaires.
Nexus Rétrospective
La Rétrospective standard d’une équipe Scrum s’enrichit à l’échelle d’une « Nexus Rétrospective » dont le déroulé est particulier. Pour que l’information globale puisse redescendre vers les équipes, puis être travaillée par chacune d’elles afin d’être consolidée de façon transverse et en prenant en compte tous les retours locaux, on suit 3 étapes :
- Dans la première étape, les représentants des équipes se réunissent et discutent l’exécution transverse et les problèmes rencontrés, puis, rapportent ces informations vers les équipes respectives.
- Dans une deuxième étape, les équipes tiennent une rétrospective classique d’équipe Scrum. Cet ordre permet d’aborder des problèmes transverses identifiés dans la première étape.
- Dans une troisième étape, les mêmes représentants se réunissent à nouveau pour trouver des actions aux problèmes transverses remontés depuis les équipes.
Chacune de ces parties de rétrospective devrait se focaliser, à son niveau, sur l’identification et la résolution des dysfonctionnements à l’échelle :
- Est-ce que Nexus a laissé un travail non-terminé ? Nexus a-t-il généré une dette technique ?
- Est-ce que tous les artéfacts, notamment le code, ont été fréquemment intégrés avec succès ? L’intégration se fait-elle de façon journalière ?
- Le produit (ou logiciel) a-t-il été construit, testé et déployé aussi souvent que nécessaire pour prévenir l’accumulation des dépendances non-résolues ?
Puis, pour les questions ci-dessus, adresser si nécessaire :
- Pourquoi est-ce arrivé ?
- Comment la dette technique peut-elle être éliminée ?
- Comment la récurrence des problèmes peut-elle être empêchée ?
Ces questions que Nexus pose « par défaut » sont très orientées intégration / produit / processus. Alors n’oublions pas dans tout cela la partie « humain », « équipe », « collaboration », « communication » et « partage » qui ont aussi leur place dans les Rétrospectives. Car dans un dispositif à l’échelle, cette partie de cohésion de groupe entre coéquipiers est primordiale et n’est pas à négliger. Une équipe soudée qui est à l’aise dans ses interactions peut largement accélérer la résolution des dépendances, des problèmes d’intégration ou de création/résorption de la dette technique. Pour la dernière, on voit bien l’importance du Craftsmanship appliqué à l’échelle.
Ce qu’il faut en retenir…
Nexus se présente comme un ticket d’entrée facile pour l’agilité à l’échelle : pas besoin de rajouter de nouvelles notions, nouveaux rôles avec des descriptions complexes. En même temps, il faut bien s’approprier les événements « Nexus » car c’est grâce à leur bonne compréhension et leur bonne exécution que l’on atteint un niveau de synchronisation optimal et un pilotage rapide et efficace. Certains événements, comme le Nexus Sprint Planning ou la Nexus Sprint Review ne sont pas triviaux à organiser. N’hésitez pas à modifier ou ajuster la forme et d’itérer sur l’organisation détaillée pour trouver votre vitesse de croisière. Tout en gardant en vue « le pourquoi » de ces événements à l’échelle et pourquoi ils sont indispensables.
Si vous doutez de leur utilité ou de leur efficacité, essayez de penser à ce que vous perdriez si vous les supprimiez mais surtout – ne le faites pas en vrai ! Car le Nexus Guide est effectivement un guide, mais nous dit aussi clairement ce qu’il faut respecter. Comme avec le framework Scrum, Nexus est un ensemble minimal de structure prescrite pour la réussite : les rôles, les artéfacts, les événements et les règles dans Nexus sont immuables. Si vous n’implémentez qu’une partie, vous aurez sûrement quelque chose d’implémenté, mais ça ne sera pas le Nexus.