16 octobre 2024
D’après une recommandation Scrum, la taille d’une équipe agile est comprise entre 5 et 9 membres.
Mais alors, comment faire pour les gros projets ?
Ceux qui nécessitent plusieurs dizaines d’intervenants (développeurs, testeurs, experts métier, …)
Un projet d’une certaine envergure oblige la mise en place d’une méthode d’agilité à l’échelle dont le premier objectif est de synchroniser plusieurs équipes qui travaillent dans un même but.
D’où la définition suivante : L’agilité à l’échelle (Agile@Scale en anglais) est une organisation au niveau de l’entreprise permettant à plusieurs équipes agiles de travailler à la réalisation d’un même produit ou service.
Il existe suffisamment de ressources sur internet pour lister les différentes méthodes d’agilité à l’échelle et décrire précisément leur fonctionnement.
Nous présentons ici très rapidement les quatre méthodes principales :
| Méthode | Description |
|---|---|
| Spotify | Porte le nom de l’entreprise suédoise qui l’a implémentée pour ses propres besoins |
| Scaled Agile Framework (SAFe) | Méthode très performante mais aussi très rigide demandant beaucoup de rigueur dans son implémentation |
| Scrum of Scrum (SoS) | Désigner des délégués, issus des équipes Scrum, pour partager l’information aux niveaux supérieurs et assurer ainsi la synchronisation |
| Large Scale Scrum (LeSS) | Application de Scrum à grande échelle sans pour autant imposer un cadre trop strict |
Dans la suite de l’article, nous utiliserons les termes Squad et Tribu issus du modèle Spotify.
SQUAD : équipe agile autonome (Scrum le plus souvent) réalisant des User Stories
TRIBU : constituée de plusieurs Squads pour implémenter une thématique de taille conséquente. La Tribu veille à la coordination étroite des Squads.
Par défaut dans un projet Azure DevOps, une équipe est toujours créée lors de la création du projet. Cette équipe porte le même nom que le projet.
Mais Azure DevOps permet de constituer et gérer plusieurs équipes pour un même projet. C’est cette fonctionnalité que nous allons utiliser pour reproduire un modèle Spotify avec une équipe Tribu et trois équipes Squads.
Pour créer et gérer plusieurs équipes dans un même projet Azure DevOps, il faut être administrateur du projet et avoir donc accès aux paramètres du projet (Project Settings) – Menu Général / Teams
Lors de la création d’une nouvelle équipe pour le projet, il existe la possibilité de créer une zone (Area) qui aura le même nom que l’équipe.
Une équipe peut utiliser plusieurs zones et une zone peut être partagée entre plusieurs équipes.
Le but est qu’une zone associée à une équipe permet de définir le backlog de l’équipe en filtrant les éléments de travail du backlog global du projet.
Une zone, comme une itération, agit comme un filtre sur les éléments de travail (Work Items).
En pratique, tous les éléments de travail affectés à une même zone constituent tout simplement le backlog de l’équipe associée à cette zone.
Pour chaque équipe, dans notre projet d’agilité à l’échelle, nous allons définir :
Nous sommes toujours dans une démarche de configuration.
Dans les paramètres du projet (Project Settings), nous allons dans le menu Boards / Team Configuration. Puis, nous choisissons dans le fil d’Ariane une équipe pour laquelle nous effectuons les configurations successives niveaux de backlog, itérations et zones.
Par défaut, dans un projet Azure DevOps, trois niveaux de backlog sont proposés :
Vous pouvez choisir de travailler sur votre projet avec un seul niveau ou deux ou trois ou même en ajouter un quatrième et un cinquième. Bien sûr, pour un projet multi-équipes d’agilité à l’échelle, il faut au minimum deux niveaux
L’équipe Tribu, souvent appelée Core Team, sera responsable de la bonne tenue des backlogs des niveaux supérieurs. Par exemple les Epics qui seront décomposées en Features.
Les équipes Squads, en revanche, seront responsables de l’implémentation technique des User Stories, qui constituent les Features et les Epics.
Poursuivons notre travail de configuration avec les itérations
Les itérations globales du projet seront définies dans le menu Boards / Project configuration. Et les équipes viendront piocher dans le menu Boards / Team configuration certaines des itérations proposées par le projet.
Pour un projet d’agilité à l’échelle, les itérations seront définies de façon hiérarchique et suivront habituellement les niveaux de backlog.
Ici, nous allons choisir des itérations trimestrielles pour notre équipe Tribu, responsable des Epics et des Features.
Et pour nos équipes Squads, responsables de l’implémentation des User Stories, nous choisirons des itérations de plus bas niveau.
Pour rappel, un Sprint est tout simplement le terme Scrum désignant une itération.
Enfin, nous terminons par la configuration des zones.
Techniquement, la configuration est tout à fait similaire à celle des itérations.
Usuellement, on choisit la zone globale du projet pour l’équipe Tribu et les sous-zones spécifiques propres à chaque Squad.
Bien ! Nous avons configuré notre projet Azure DevOps selon les principes d’agilité à l’échelle du modèle Spotify.
Chaque équipe, Tribu ou Squads, dispose maintenant de son niveau de navigation de backlog, de ses zones et itérations.
Cela met fin à la partie configuration du projet et des équipes.
Voyons maintenant comment suivre le travail des équipes, synchroniser les différentes réalisations et identifier les éventuelles dépendances…
Tout va se jouer avec les plans de livraison !
Les plans de livraison (Delivery Plans) de Azure Boards permettent de suivre finement le travail des équipes d’un projet selon leurs configurations Niveaux de backlog – Itérations – Zones
Lors de la création d’un nouveau plan, on précise quelles équipes et quels niveaux de backlog seront affichés.
Selon les options retenues à la création du plan de livraison, on pourra par exemple constituer un plan de livraison au niveau Core Team : les membres de l’équipe Tribu suivront particulièrement les éléments de travail de type Epic ou Feature sur une période importante.
Notez également la possibilité de faire apparaître des jalons sur votre plan. Comme par exemple, les dates d’un PI Planning ou la date d’une Mise en Production…
Un plan de livraison au niveau des Squads intéressera les membres de l’équipe Tribu en leur permettant de bien suivre l’avancée des User Stories dans les itérations de chaque équipe. Ce type de plan sera habituellement sur une période plus réduite et affichera les trois ou quatre Sprints qui constituent un Program Increment.
Typiquement dans un projet d’agilité à l’échelle, une Feature a été décomposée en plusieurs User Stories dont la réalisation est confiée à plusieurs Squads. Il faut donc suivre simultanément le travail de plusieurs Squads pour apprécier l’avancée de l’implémentation globale de la Feature. Et surtout être capable d’identifier rapidement les éventuelles dépendances entre les User Stories réparties chez des Squads différentes.
Logiquement, une User Story, indispensable à la réalisation d’une autre User Story par une autre Squad, sera planifiée dans les premiers Sprints du Program Increment.
A contrario, une User Story « finale » en bout de chaîne sera plutôt prévue dans les derniers Sprints du Program Increment.
Exemple ici avec l’US 1.1.5, planifiée dans le Sprint T1.4 se terminant le 22 mars, qui dépend de l’US 1.1.3, planifiée dans le Sprint T1.3 se terminant le 1er mars.
Le lien de dépendance est donc parfaitement géré !
Voilà !!
Sur un vrai projet Spotify d’agilité à l’échelle, il y a pas mal de configuration à effectuer.
Mais clairement, ça vaut le coup…
A vous de jouer 😊