Le Cadre Nexus pour la mise à l’échelle de Scrum dans le Développement Logiciel

Scrum, étant le moyen agile le plus courant que les équipes de développement logiciel travaillent, conduit à la question de: “Comment pouvons-nous faire évoluer Scrum au-delà d’une seule équipe?”Si vous rencontrez des problèmes avec les dépendances inter-équipes, les risques qui affectent plusieurs équipes, la planification des livraisons, vous aurez peut-être besoin d’un framework de mise à l’échelle.

Vous pouvez organiser plusieurs équipes Scrum de différentes manières. Dans cet article, nous allons approfondir le framework Nexus pour la mise à l’échelle d’Agile et de Scrum, basé sur l’expérience de DevCom. Il existe d’autres frameworks pour la mise à l’échelle Agile tels que LeSS, SAFe, DAD (Disciplined Agile Delivery) et, mais ils ne sont pas couverts dans cet article.

Qu’est-ce que Nexus Framework ?

Nexus framework a été fondé par le co-créateur de Scrum Ken Schwaber et le Scrum.org team en 2015 comme guide pour la mise à l’échelle de Scrum dans des projets agiles de grande envergure.
Comme Scrum est devenu une partie intégrante de nombreuses organisations, leurs projets doivent aller au-delà des sessions de réunion quotidiennes, de Planification, de Révision et Rétro utilisées dans Scrum pour être efficaces. Scrum seul ne suffit pas lorsque plusieurs équipes travaillent sur un produit. La productivité s’érode en raison des dépendances entre les équipes.
Nexus framework utilise Scrum comme bloc de construction et l’étend pour une meilleure gestion de plusieurs équipes Scrum qui travaillent sur un seul produit. Nexus est appliqué à 3-9 groupes scrum et les guide sur la façon dont ils doivent coopérer et partager le travail pour fournir un logiciel dans chaque Sprint avec un minimum de dépendances.

Comment Nexus Framework fait évoluer Scrum ?

Scrum est un framework à partir duquel évolue le processus. Il est axé sur la façon dont une seule équipe Scrum travaille sur un seul produit et fournit des logiciels par petits incréments. La principale différence entre le framework Nexus et Scrum est l’ajout d’une équipe d’intégration qui se concentre sur la facilitation des dépendances entre les équipes.

 Cadre Scrum

( Source)

 Nexus pour la mise à l'échelle agile

( Source)

Flux de processus Nexus:

  1. Affinez le carnet de commandes du produit.
  2. Planification de sprint Nexus.
  3. Travaux de développement.
  4. Mêlée quotidienne Nexus.
  5. Examen du Sprint Nexus.
  6. Rétrospective Nexus Sprint.

Au moment où vous implémentez le Nexus, il n’y a pas de changements significatifs dans les fondamentaux de Scrum lui-même. Nexus revient à ajouter de nouvelles pratiques à Scrum, des rôles, des événements et des artefacts supplémentaires uniquement lorsque cela est nécessaire pour permettre des initiatives de développement logiciel réussies. Nexus augmente Scrum pour permettre à Scrum de s’adapter efficacement. Ceci est accompli en améliorant la simplicité et la transparence en travaillant à partir d’un seul carnet de commandes de produits. Ce qui compte, c’est qu’une plus grande attention soit accordée aux dépendances entre les équipes Scrum, qui sont responsables de fournir des incréments “Terminés” à chaque Sprint.

Une définition de “Terminé” est un critère rigoureux qui peut être appliqué à l’Incrément Intégré développé à chaque Sprint, et qui est suivi par toutes les Équipes Scrum d’un Nexus.

 DevCom Comment Nexus étend Scrum

Implémentation du framework Nexus

Le framework Nexus suppose une expérience Scrum. Les organisations qui travaillent déjà avec Scrum pourront facilement implémenter Nexus. Pour démarrer un Nexus, les organisations doivent d’abord identifier les équipes de leur Nexus, une Équipe d’intégration Nexus initiale, un Carnet de commandes Produit unique, une définition de ” Terminé”, une cadence de Sprint.

Stratégie de mise en œuvre de Nexus

Définissez les équipes Scrum (concentrez-vous sur les fonctionnalités plutôt que sur les composants). 1.1. Tenir une réunion et définir comment former des équipes;
1.2. Assigner des membres d’équipe (idéalement des équipes créées par soi-même);
1.3. Définissez le(s) joueur(s)/représentant(s) clé(s) de chaque équipe.
Définir les Environnements et les dépôts pour le développement (en fonction du nombre de Clients (locataires) et du niveau d’accès). 2.1. Faire une liste des dépôts actuels;
2.2. Réorganiser les environnements de repos et de révision pour raccourcir le délai d’exécution des tâches ;
2.3. Créer une base de code commune (si possible);
Définir l’équipe d’intégration Nexus (Membres des équipes Scrum. Peut varier en fonction des informations à diffuser et à résoudre à la suite de Nexus Daily Scrum). 3.1. Définir les personnes responsables des intégrations principalement et de la résolution des dépendances ;
3.2. Attribuez le rôle d’un Scrum master au sein de chaque équipe.
Enseigner et expliquer le framework Nexus Scrum &. 4.1. Organiser une réunion pour toutes les équipes Scrum et passer en revue les bases ;
4.2. Faciliter les réunions si nécessaire.
Définir des outils pour travailler avec et à l’intérieur. 5.1. Définir des outils de productivité et de gestion de projet pour travailler avec et au sein et intégrer (mettre en place).
Définissez la “Définition de done”. 6.1. D’accord avec le NIT sur le terme;
6.2. Créez un document officiel.
Définir le backlog produit / affiner le backlog produit avec le Product Owner (PO) ou / et les représentants. 7.1. Enregistrer les exigences fonctionnelles à l’aide de l’un des outils ci-dessus ;
7.2. Créez un modèle avec des champs obligatoires à remplir (par exemple, nom, description, critères d’acceptation, contraintes).
Obtenez l’approbation du propriétaire du produit & laissez-la prioriser le carnet de commandes. 8.1. Impliquer le PO pour combler et affiner l’arriéré;
8.2. Collaboration continue avec PO pour travailler sur le backlog Produit (écrire des histoires, des tâches à l’aide d’un modèle 7.2).
Organisez la NIT pour estimer l’arriéré en utilisant des points relatifs. 9.1. Tenir la première partie de la réunion pour acquérir une technique d’estimation.
9.2. Tenir une deuxième partie de la réunion pour faire des estimations approximatives des éléments de l’arriéré de produits (IEP).
Implémentez la planification de Sprint Nexus. 10.1. Définir la cadence de sprint;
10.2. Définir les dépendances, les problèmes d’intégration qui peuvent apparaître;
10.3. Portée à définir : environ au moins 2 Sprints devant et en cours;
10.4. Organisez une réunion pour aider les membres du NIT à planifier les sprints en équipes.
Implémentez la planification des Sprints au sein de chaque équipe Scrum. 11.1. Utiliser des estimations absolues pour les tâches et les sous-tâches lors de la planification des sprints ;
11.2. Faciliter la planification des sprints pour chaque équipe;
11.3. Créez un modèle de document.
Implémentez Nexus Daily Scrum et Daily Scrum pour chaque équipe. 12.1. Définissez l’heure, facilitez les réunions Scrum quotidiennes Nexus (essayez de les garder dans l’heure);
12.2. Définissez l’heure, facilitez les réunions Scrum quotidiennes (gardez-les timeboxées).
Implémentez la revue Nexus Sprint (max 4h). 13.1. Organisez un examen Nexus Sprint (y compris un enregistrement de démonstration si nécessaire) avec les membres de l’équipe Scrum, les PO et d’autres parties prenantes.
Implémenter la Rétrospective Nexus Sprint et la réunion rétrospective pour chaque équipe Scrum (créer un document de modèles) (max 1h et 3h). 14.1. Tenir une réunion rétrospective pour le NIT;
14.2. Créer un modèle de document;
14.3. Faciliter les réunions rétrospectives dans les équipes Scrum.
14.4. Créez un modèle de document.
Mettre en œuvre l’événement de raffinement Nexus sur la base régulière de l’arriéré de produits. 15.1. Définissez la fréquence (aussi souvent que nécessaire; par exemple 2t/semaine).
Mettre en œuvre l’estimation en points d’histoire (en fonction de l’initiative du PO et de la volonté de prévoir). 16.1. Commencer à suivre la vitesse des équipes de mêlée (après 3 Sprints);
16.2. Suivez les progrès à l’aide du graphique de burndown Sprint.
Implémentez les dépendances visuelles et leurs prévisions parmi les tâches. 17.1. Visualisez les dépendances entre les histoires d’utilisateurs, les tâches (par exemple, drapeau et lien);
17.2. Définissez les dépendances pour le Sprint actuel et deux Sprints à venir.
Lancer des activités de gestion de projet pour soutenir le projet. 18.1. Créer des documents qui pourraient être utiles (par exemple, Charte de projet, Matrice de gestion des risques, Gestion des parties prenantes, Gestion d’équipe (incl. Informations sur les membres de l’équipe, test de DISQUE, test de motivation, bilan de santé de l’équipe));
18.2. Définissez des KPI de projet et créez un modèle pour les suivre. Habituellement, ils incluent la vitesse, le burndown de sprint, le CSAT. D’autres peuvent inclure des calculs budgétaires;
18,3. Définir des rapports pour les bilans de santé du projet avec le PO et les principales parties prenantes;
18.4. Passez en revue la stratégie de test dans les tâches et le flux (tests manuels, unitaires, automatisation) s’ils ne font pas partie du flux par défaut.
Stratégie visant à offrir plus de valeur et à maximiser les résultats après la mise en œuvre des étapes ci-dessus (à DÉTERMINER). 19.1. Tenir une réunion avec les principales parties prenantes (PO, PDG, autres);
19.2. Collectez et discutez des exigences qui s’alignent sur la stratégie commerciale.

Équipes Nexus

Un Nexus se compose d’environ 3 à 9 Équipes Scrum, et d’une Équipe d’intégration Nexus constituée de 1 à 2 membres de chaque équipe scrum qui sont chargés de planifier la vision du produit global et de coordonner les équipes.

Il est recommandé de former des équipes en fonction de la faisabilité. Les équipes de fonctionnalités ont le plus de sens car elles peuvent travailler sur n’importe quel élément de backlog de produit.

Cependant, le flux de travail actuel s’oriente vers les équipes de composants, ce qui peut entraîner de plus grandes dépendances entre elles. Pour réduire le risque, il est valable de déléguer aux équipes les tâches qui appartiennent à d’autres tâches que leur composant. Le processus de partage des connaissances sera essentiel dans ce cas et réduira le manque d’informations lors de l’intégration.

L’équipe d’intégration Nexus (NIT) est composée de membres de:

  • ⇒ Propriétaire de produit – responsable de maximiser la valeur du Produit et de s’assurer que le travail combiné effectué par un Nexus est produit au moins une fois par Sprint.
  • ⇒ Scrum Master – responsable des équipes Scrum qui font correctement Scrum et Nexus et maximisent la valeur fournie par l’équipe de développement. Responsable de la livraison des incréments “Terminés” de produits potentiellement libérables.
  • ⇒ Équipe de développement – responsable de la création d’incréments intégrés qui sont “Terminés”. Assurez-vous que les équipes Scrum du Nexus comprennent et mettent en œuvre les pratiques nécessaires pour détecter les dépendances et intègrent fréquemment tous les artefacts à la définition de ” Terminé “.”

Rôle de l’Équipe d’intégration Nexus:

  • ⇒ L’équipe d’intégration de Nexus est responsable d’assurer la définition de ” Terminé “.
  • ⇒ L’Incrément intégré (le travail combiné effectué par un Nexus) est produit au moins une fois par Sprint.
  • ⇒ Les équipes Scrum sont chargées de livrer “Terminé “.
  • ⇒ Le NIT fournit un point focal d’intégration pour le Nexus. L’intégration comprend la résolution de toutes les contraintes techniques et non techniques entre équipes qui peuvent entraver la capacité d’un Nexus à fournir un Incrément constamment intégré.
  • ⇒ L’adhésion peut varier au fil du temps en fonction des obstacles rencontrés par le Nexus.

Les membres de l’équipe doivent produire le résultat maximum pour chaque Sprint. Un bilan de santé régulier pour les équipes est recommandé ainsi que pour les logiciels. Une fois par mois, on peut tenir un questionnaire rapide pour surveiller la productivité des équipes au sein de chaque équipe Scrum.

Questions pour les membres de l’équipe:

  • ⇒ Apportent-ils de la valeur?
  • ⇒ Le produit est-il facile à libérer?
  • ⇒ Les membres de l’équipe s’amusent-ils ?
  • ⇒ Le produit est-il sain ?
  • ⇒ Est-ce durable et supportable ?
  • ⇒ Les membres de l’équipe apprennent-ils ?
  • ⇒ Comprennent-ils les objectifs du produit ?
  • ⇒ Se sentent-ils comme des pions ou des joueurs ?
  • ⇒ Se sentent-ils propriétaires ?
  • ⇒ Leur vitesse est-elle adéquate ?
  • ⇒ Estiment-ils avoir un processus approprié ?
  • ⇒ Se sentent-ils soutenus ?
  • ⇒ Fonctionnent-ils bien en équipe ?
  • ⇒ L’entreprise contribue-t-elle au développement des employés ?

 Bilan de santé de l'équipe Nexus de DevCom

Événements Nexus

1.Raffinement

Le raffinement se traduit par un Backlog de produits suffisamment granulaire pour que les équipes Scrum puissent travailler sans créer de dépendances ingérables. Lors du raffinement, les équipes Scrum doivent se concentrer sur ces questions:

  • ⇒ Quel travail chaque équipe tirera-t-elle?
  • ⇒ Dans quel ordre ce travail doit-il être effectué pour offrir la plus grande valeur commerciale au plus tôt, tout en minimisant les risques et la complexité?

Planification de sprint Nexus

La planification de sprint Nexus se compose de:

  • ⇒ Validation du Carnet de commandes des produits. Les équipes Scrum examinent les PBIs et procèdent aux ajustements nécessaires au travail à partir de l’événement de raffinement. Toutes les équipes Scrum doivent participer et contribuer à minimiser les problèmes de communication; cependant, seuls les représentants appropriés (ceux qui estiment pouvoir apporter une contribution à l’amélioration des PBIs) de chacune des équipes Scrum doivent y assister.
  • ⇒ Formulation de l’objectif Nexus. L’objectif Nexus est un objectif de Sprint qui est atteint grâce à la mise en œuvre de PBIS par plusieurs équipes.
  • ⇒ Planification du sprint par équipe Mêlée. Une fois l’objectif Nexus du Sprint compris, chaque équipe Scrum organisera ses événements de Planification de Sprint individuels dans lesquels les membres créeront leurs propres Backlogs de Sprint. Lorsqu’ils identifient les dépendances avec d’autres équipes, ils travaillent avec ces équipes pour minimiser ou éliminer les dépendances. La planification de la plupart des sprints devrait prendre 8 heures.

Dans certains cas, cela signifie que la séquence de travail entre les équipes peut devoir être ajustée pour permettre à une équipe de terminer son travail avant qu’une autre ne commence.

Nexus Daily Scrum

La réunion Nexus Daily Scrum comprend les principales questions:

  • ⇒ Le travail de la veille a-t-il été intégré avec succès, et sinon, pourquoi?
  • ⇒ De nouvelles dépendances ont-elles été identifiées ?
  • ⇒ Quelles informations doivent être partagées entre les équipes du Nexus ?

Généralement, il se tient au même moment et au même endroit.

Examen Sprint Nexus

L’Examen Sprint comprend les éléments suivants:

  • ⇒ Les participants incluent les équipes Scrum et les parties prenantes clés invitées par le Product Owner ;
  • ⇒ Le Product Owner explique quels éléments du Backlog de produits ont été ” Faits ” et ce qui n’a pas été ” Fait “;
  • ⇒ Les Équipes de développement discutent de ce qui s’est bien passé pendant le Sprint, des problèmes rencontrés et de la manière dont ces problèmes ont été résolus ;
  • ⇒ Les Équipes de développement démontrent le travail qu’il a “Fait ” et répondent aux questions sur l’Incrément ;
  • ⇒ Le Product Owner discute du Backlog Produit tel qu’il est. Il ou elle projette des dates cibles et de livraison probables en fonction des progrès réalisés à ce jour (si nécessaire);
  • ⇒ L’ensemble du groupe collabore sur ce qu’il faut faire ensuite afin que l’examen du Sprint fournisse une contribution précieuse à la planification ultérieure du Sprint;
  • ⇒ Examen de la façon dont le marché ou l’utilisation potentielle du produit pourrait avoir changé ce qui est la chose la plus précieuse à faire ensuite;
  • ⇒ Examen du calendrier, du budget, des capacités potentielles et du marché pour les prochaines versions prévues de fonctionnalités ou de capacités du produit.

Le résultat de l’Examen Sprint est un Backlog Produit révisé qui définit les éléments de Backlog produits probables pour le prochain Sprint. L’arriéré de produits peut également être ajusté globalement pour répondre aux nouvelles opportunités.

Cette activité ne devrait pas prendre plus de 3 heures.

Réunion rétrospective Nexus

5.1. Rétrospective NIT

Comme il existe des dysfonctionnements courants de mise à l’échelle, chaque Rétrospective doit répondre aux questions suivantes.

  • ⇒ Ont-ils atteint l’objectif du Nexus ? Sinon, pourquoi pas ?
  • ⇒ Des travaux ont-ils été annulés ? Le Nexus a-t-il généré de la dette technique?
  • ⇒ Tous les artefacts, en particulier le code, ont-ils été fréquemment (idéalement, en continu) et ont-ils été intégrés avec succès ?
  • ⇒ Le logiciel a-t-il été construit, testé et déployé suffisamment souvent pour éviter l’accumulation écrasante de dépendances non résolues ?

Lorsque des problèmes sont découverts, les représentants doivent demander:

  • ⇒ Pourquoi est-ce arrivé?
  • ⇒ Comment résoudre le problème ?
  • ⇒ Comment prévenir la récidive ?

Après la réunion rétrospective Nexus, il est important de définir les actions sur lesquelles travailler au sein de toutes les équipes Scrum. Le NIT doit garder une trace de ces éléments et peut utiliser un tableau ci-dessous.

 Éléments d'action DevCom Nexus

5.2. Rétrospective des équipes Scrum

Chaque équipe Scrum peut utiliser un tableau pour visualiser les éléments sur lesquels il faut travailler. En outre, il est recommandé de garder une trace formelle de ces enregistrements de manière structurée. Tout au plus, il faut 4 heures pour discuter avec l’équipe du déroulement d’un Sprint.

 Rétrospective Scrum teams

Product Owner

Le Product Owner est responsable de maximiser la valeur du produit.

Le Propriétaire du Produit est la seule personne responsable de la gestion du Carnet de commandes du Produit. La gestion de l’arriéré de produits comprend:

  • ⇒ Exprimer clairement les éléments du Carnet de commandes Produit ;
  • ⇒ Ordonner les éléments du Carnet de commandes Produit pour atteindre au mieux les objectifs et les missions ;
  • ⇒ Optimiser la valeur du travail effectué par l’équipe Nexus ;
  • ⇒ S’assurer que le Carnet de commandes Produit est visible, transparent et clair pour tous, et montre sur quoi les équipes Scrum travailleront ensuite;
  • ⇒ S’assurer que les équipes Scrum comprennent les éléments du Backlog Produit au niveau requis ;
  • ⇒ Définir l’objectif Nexus pour chaque Sprint (similaire à milestone).

Le propriétaire du produit peut effectuer le travail ci-dessus ou demander à l’équipe Nexus de le faire. Cependant, le Propriétaire du produit reste responsable.

Principaux points à retenir

  1. Les travaux agiles mis à l’échelle et l’utilisation d’un framework de mise à l’échelle vous aident à démarrer rapidement.
  2. La mise à l’échelle de la mêlée est juste une mêlée. Vous ne modifiez pas la façon dont vous travaillez en tant qu’équipe Scrum, ni le travail fourni.
  3. En ajoutant le framework Nexus au-dessus de Scrum, il fournit aux équipes un moyen de gérer les dépendances entre équipes et de s’assurer qu’elles travaillent toutes ensemble vers un objectif et un incrément de produit communs.
  4. Si vous connaissez très bien Scrum, le framework Nexus est le framework “évident” pour faire évoluer les équipes de développement logiciel, et vous n’aurez peut-être jamais besoin de rien d’autre.
  5. Nexus est un cadre de discussion utile pour ceux qui ont déjà plusieurs équipes Scrum en place qui fonctionnent ensemble.
  6. Alternativement, si vous souhaitez décrire votre processus, le cadre Nexus est un bon point de départ pour ne manquer aucune perspective.
  7. Comme toujours, quand il s’agit de mettre à l’échelle agile, rappelez-vous ces trois choses importantes:
  • ⇒ Adaptez la méthode à votre organisation.
  • ⇒ Réfléchissez constamment à la situation.
  • ⇒ Améliorez votre façon de travailler ensemble.

Avez-vous d’autres suggestions pour les techniques “au-delà de l’équipe”? Vous voulez de l’aide pour mettre en œuvre ces idées?

Depuis 2000, DevCom a adapté des méthodologies Agiles standard de l’industrie conçues pour créer des solutions rapides, efficaces et efficientes pour atteindre les objectifs de nos clients. Ces méthodologies représentent un modèle de développement itératif dans lequel l’effort global est divisé en plusieurs versions afin d’atteindre les objectifs définis pour une phase particulière. Nous mettons beaucoup l’accent sur trois éléments du cycle de vie du développement: L’Évaluation et la Planification initiales du Projet, la Gestion de Projet de Qualité, l’Assurance de la Qualité.

Notre approche de développement réduit les risques liés aux projets et permet de contrôler les délais de mise sur le marché et le budget. Nous partageons cette expérience et ces connaissances avec nos nouveaux clients afin que tout le monde puisse réussir lors de la mise à l’échelle.

Obtenez de meilleurs résultats grâce au travail d’équipe : Contactez-nous chez DevCom dès aujourd’hui!

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.