Nexus Framework for Scaling Scrum, The

1. Nexus étend Scrum pour coordonner plusieurs équipes travaillant sur un même produit

« Le Scrum à l’échelle reste du Scrum. »

Principes fondamentaux de Nexus : Nexus est un cadre qui permet à 3 à 9 équipes Scrum de collaborer sur un produit unique. Il conserve les principes essentiels de Scrum tout en ajoutant une structure minimale pour gérer les dépendances inter-équipes et l’intégration.

Éléments clés :

• Backlog de Sprint Nexus : coordonne le travail entre les équipes
• Équipe d’Intégration Nexus (EIN) : garantit l’intégration du produit
• Événements Nexus : affinement, planification de Sprint, Daily Scrum, revue de Sprint et rétrospective de Sprint

Nexus vise à préserver la simplicité de Scrum tout en répondant aux complexités du développement produit multi-équipes. Il met l’accent sur la réduction des dépendances entre équipes et l’amélioration de la communication pour livrer un incrément intégré à chaque Sprint.

2. L’Équipe d’Intégration Nexus (EIN) est responsable de l’intégration du produit

« L’EIN est responsable de s’assurer que Nexus produit un incrément intégré au moins une fois par Sprint. »

Composition de l’EIN : L’EIN comprend généralement le Product Owner, un Scrum Master et des représentants de chaque équipe Scrum. Ses membres sont souvent à temps partiel, conciliant leurs responsabilités dans l’EIN avec leurs tâches habituelles.

Responsabilités de l’EIN :

• Faciliter la collaboration inter-équipes
• Identifier et résoudre les problèmes d’intégration
• Accompagner les équipes dans les pratiques à l’échelle
• Garantir la livraison d’un incrément produit intégré

L’EIN ne réalise pas elle-même l’intégration, mais en assume la responsabilité. En cas de crise, elle peut adopter un rôle plus actif pour lever les obstacles et remettre Nexus sur la bonne voie.

3. Les dépendances entre équipes sont gérées par l’affinement et la planification

« L’affinement est essentiel ; il aide les équipes Scrum à collaborer pour déterminer quelle équipe livrera quels éléments du backlog et à identifier les dépendances inter-équipes. »

Affinement continu : Nexus insiste sur un affinement permanent du Product Backlog afin de minimiser les dépendances et de créer des éléments prêts à être réalisés par une seule équipe.

Techniques de visualisation :

• Impact Mapping : relie les objectifs aux livrables
• Story Mapping : visualise les parcours utilisateurs et la planification des versions
• Tableau d’affinement inter-équipes : identifie les dépendances entre équipes et sprints

La planification de Sprint Nexus s’appuie sur ces éléments affinés pour élaborer un plan coordonné entre toutes les équipes. Le Backlog de Sprint Nexus visualise les dépendances inter-équipes et aide à ordonnancer efficacement le travail.

4. Le Daily Scrum Nexus renforce la transparence et la collaboration

« Le Daily Scrum Nexus rend les problèmes d’intégration visibles, afin que les équipes sachent qui est responsable de leur résolution. »

Déroulement de l’événement : Le Daily Scrum Nexus a lieu avant les Daily Scrums des équipes individuelles, permettant à chacune d’ajuster son plan quotidien en fonction des besoins d’intégration inter-équipes.

Points clés :

• Identifier les défis d’intégration
• Coordonner les efforts entre équipes
• Partager les informations critiques

La participation est flexible, avec les personnes concernées présentes selon les problèmes d’intégration en cours. Cet événement favorise la détection précoce des problèmes et encourage la collaboration au sein du Nexus.

5. L’intégration et la livraison continues sont essentielles pour faire évoluer Scrum

« L’intégration continue sans tests automatisés n’est que de la compilation. »

Pratiques CI/CD :

• Développement basé sur la branche principale
• Tests automatisés (unitaires, d’intégration, de régression)
• Builds et déploiements fréquents
• Feature toggles pour des livraisons contrôlées

Mettre en œuvre des pratiques robustes de CI/CD aide les équipes Nexus à détecter tôt les problèmes d’intégration, réduire la dette technique et maintenir un incrément produit prêt à être livré. L’automatisation est la clé pour gérer la complexité du développement multi-équipes.

6. L’auto-organisation et les équipes fonctionnelles améliorent productivité et flexibilité

« Les équipes fonctionnelles sont des équipes pluridisciplinaires responsables de la livraison complète des fonctionnalités ou capacités produit, sous la direction du Product Owner. »

Avantages des équipes fonctionnelles :

• Réduction des transferts et dépendances
• Amélioration du time-to-market
• Meilleure orientation client
• Qualité de code renforcée
• Développeurs plus polyvalents et engagés

Passer d’équipes par composants à des équipes fonctionnelles peut être un défi, mais cela conduit à plus de flexibilité et de productivité. Cela nécessite une base de code ouverte, une forte automatisation et un engagement à la formation croisée des membres.

7. Gérer la dette technique est indispensable pour réussir sur le long terme

« Gérer la dette technique, c’est comme faire du sport : tout le monde sait qu’il faut le faire, mais on est souvent trop occupé pour en faire une habitude quotidienne. »

Stratégies pour gérer la dette technique :

• Intégrer le refactoring dans la définition de « Terminé »
• Allouer un pourcentage de capacité à la réduction de la dette
• Rendre la dette technique visible dans le Product Backlog
• Sensibiliser le Product Owner à l’importance de traiter la dette

Trouver l’équilibre entre développement de nouvelles fonctionnalités et réduction de la dette est crucial pour maintenir un produit sain et durable. Négliger la dette technique peut entraîner une baisse de productivité et un risque accru avec le temps.

8. Faire évoluer le rôle de Product Owner nécessite délégation et communication claire

« Le Product Owner peut s’entourer d’aides ou de suppléants, à condition de conserver l’autorité finale sur les décisions. »

Stratégies d’évolution :

• Désigner des représentants Product Owner dans les équipes
• Communiquer clairement la vision et les priorités produit
• Établir des points de contact réguliers avec les équipes
• Utiliser des outils pour la communication asynchrone

À mesure que Nexus grandit, le Product Owner doit trouver des moyens d’orienter et de décider efficacement à travers plusieurs équipes. La délégation aide, mais il est essentiel de maintenir une source unique de direction produit.

9. Le Scrumbling aide les équipes à se remettre des échecs d’intégration

« Un Scrumble survient lorsqu’un Nexus ne peut pas livrer un incrément pleinement intégré, terminé et prêt à l’usage. »

Processus de Scrumbling :

1. Arrêter le travail normal du Sprint
2. Réduire la taille des équipes pour se concentrer sur les problèmes clés
3. Traiter les causes profondes des échecs d’intégration
4. Améliorer les pratiques et environnements de développement
5. Créer un incrément stable et intégré avant de reprendre le travail normal

Le Scrumbling est un dernier recours lorsque les problèmes d’intégration deviennent insurmontables. Il permet au Nexus de faire une pause, corriger les problèmes fondamentaux et établir une base solide pour la suite.

10. Transparence, confiance et valeurs Scrum sont fondamentales pour réussir Nexus

« La culture est malheureusement la chose la plus difficile à changer, et cela peut compromettre toute transformation. »

Valeurs Scrum :

• Engagement
• Concentration
• Ouverture
• Respect
• Courage

Construire une culture de transparence et de confiance est essentiel pour le succès de Nexus. Cela demande une application constante des valeurs Scrum, non seulement au sein des équipes, mais dans toute l’organisation.

Favoriser transparence et confiance :

• Encourager la communication ouverte sur les difficultés
• Célébrer les exemples incarnant les valeurs Scrum
• Utiliser des bilans de santé pour mesurer le ressenti des équipes
• Créer des communautés de pratique pour partager les savoirs

Le succès durable de Nexus repose sur la création d’un environnement où les équipes se sentent en sécurité pour expérimenter, échouer et apprendre ensemble.