Les valeurs de l’Agilité prônent des produits et des équipes autonomes et indépendantes.
Dans la pratique ce n’est pas toujours possible, que ce soit pour des raisons d’adhérences techniques ou de complexité du Produit qui nécessite que plusieurs équipes travaillent dessus. Il faudra alors développer des mécanismes de synchronisation entre les équipes pour qu’elles puissent collaborer.
Plusieurs Frameworks Agiles se proposent d’aider les entreprises à répondre à cette problématique et nous allons en faire ici un comparatif.
SAFe
L’un des Frameworks Agile à l’échelle les plus connus est SAFe.
Il est très complet et présente de nombreuses similarités avec Scrum mais sur une échelle de temps plus longue.
Pour passer à l’échelle, on prend un groupe d’équipes qui vont travailler sur un même sujet et on les regroupe dans ce qu’on appelle un Train (Agile Release Train, ART). Cette configuration est adaptée jusqu’à 125 personnes.
Il existe des couches d’implémentation de SAFe au-dessus de l’ART (Solution Management, Portfolio Management) pour gérer des Produits plus complexes et des équipes plus nombreuses mais elles sont rarement utilisées.
Au bout d’un certain nombre de Sprints (en général 4 à 6 soit 2-3 mois) le Train va produire un Incrément intégré et publiable c’est à dire une nouvelle version des Produits avec de nouvelles fonctionnalités.
Dans SAFe, tous les Sprints ne sont pas identiques : il y a un dernier Sprint qui est un tampon pour absorber les retards, gérer de la dette technique, explorer et innover, que l’on appelle l’Innovation and Planning Iteration.
C’est aussi à ce moment que l’on planifie le prochain PI. On définit la cible de ce qui doit être réalisé au niveau du Train pour la période à venir. Pour cela, on utilise des OKR (Objectives and Key Results) qui serviront de boussole pour définir le Backlog de l’ART et celui-ci servira ensuite de base pour la construction du Backlog de chaque équipe.
SAFe introduit aussi de nouveaux rôles, de nouveaux artefacts et de nouveaux Évènements Agiles.
Au niveau des artefacts, il n’y a rien de notable, juste plus de niveau d’abstraction pour les stories/epics pour gérer l’échelle de scope et de temps.
Pour les nouveaux rôles :
- Le Product Manager et le Release Train Engineer ne sont que des rôles de Product Owner et Scrum Master à l’échelle. Toutefois, l’existence du Product Manager rend une partie du rôle traditionnel des Product Owners en dessous obsolète ou a minima l’atténue.
- Le Business Owner est un leader business qui agira comme facilitateur et arbitre de la stratégie métier. Il est aussi le responsable de l’adéquation entre ce qui est produit et la stratégie de l’entreprise.
- Le System Architect s’assure de la cohérence technique des solutions. C’est un rôle important mais qui, comme le Product Manager, retire un peu d’autonomie aux équipes, sur le plan technique cette fois.
Les Évènements SAFe sont alignés sur une temporalité plus longue que Scrum. Pour certains ils n’ont lieu qu’une fois par trimestre, pour d’autres la fréquence est déterminée selon les besoins.
Source : https://scaledagileframework.com/planning-interval/
Taille des équipes : 50-125 personnes (pour la couche ART)
Facilité d’accès à la documentation : ⭐⭐✩ la documentation SAFe (https://scaledagileframework.com/) est riche et bien documentée, mais peu accessible sans avoir suivi de formations payantes.
Facilité de mise en place : ⭐⭐✩ SAFe est un Framework très complet qui permet donc de le mettre en place en laissant assez peu de place au doute. Cette complétude le rend aussi assez lourd à mettre en place de A à Z. Il demande relativement peu de changements organisationnels et les équipes continuent de travailler en parallèle avec des mécanismes pour casser l’effet silo.
Gestion des dépendances : ⭐⭐⭐ ici, la complétude de SAFe est un avantage. Le System Architect et les parties du PI Planning explicitement conçues pour gérer les dépendances ainsi que les Scrum of Scrum qui peuvent servir à détecter et remonter ces problèmes en cours de PI couvrent assez bien ce sujet.
Souplesse : ⭐✩✩ L’échelle de temps de base est de 3 mois, c’est long. Une fois l’objectif du PI défini et le train lancé, il est sur des rails.
Couverture : ⭐⭐⭐ Framework très complet, il a des instances pour gérer la plupart des besoins et peut aussi servir de boite à outils.
LeSS
Le Large Scale Scrum ou LeSS est un autre Framework notable dans les approches d’agilité à l’échelle.
C’est un Framework léger qui “lutte contre lui-même”, son objectif est d’être le plus minimaliste possible (réduction de la taille des Produits et du nombre d’équipes). Il nécessitera donc d’adapter l’organisation, parfois en profondeur.
Il permet l’organisation de jusqu’à 8 équipes Scrum de 12 personnes maximum chacune (soit un maximum de 96 personnes ou jusqu’à 1000 personnes pour la version LeSS Huge).
LeSS vise vraiment à organiser une seule grosse équipe Scrum : il y a un seul Product Owner et un seul Backlog Produit dans lequel les différentes sous équipes vont choisir des stories qu’elles vont implémenter sous la même Definition of Done et selon la même cadence pour ce qui est considéré comme un unique Sprint.
A la fin de chaque Sprint, le résultat est un Incrément Produit livrable.
LeSS ajoute très peu d’Évènements :
- Un Sprint Planning à l’échelle du Produit qui définit quelle équipe va travailler sur quel item suivit d’un Sprint Planning par équipe (auquel le Product Owner ne participe pas) qui servira à chaque équipe à organiser son travail pour permettre la livraison des items prévus.
- Une Rétrospective globale pour gérer les problèmes entre les équipes, pour diffuser les bonnes pratiques et s’assurer de la bonne intégration de l’équipe et du Product Owner dans l’écosystème de l’entreprise.
Il permet aussi de gérer les Product Backlog Refinements avec une, plusieurs ou toutes les équipes.
Ce Framework propose un certain nombre de pistes pour aider à la communication entre les équipes mais n’impose rien dans son cadre. Cela laissera plus de latitude à l’organisation pour l’adapter à son contexte mais demandera une plus grande maturité.
Source : https://less.works/less/framework
Taille des équipes : 15-92 personnes, jusqu’à 1000 avec LeSS Huge
Facilité d’accès à la documentation : ⭐⭐⭐ tout est en accès libre sur http://less.works et les formations sont optionnelles
Facilité de mise en place : ⭐✩✩ LeSS requiert des équipes très matures et recommande de se faire accompagner par un ou des coaches pour faciliter l’adoption
- Il demande beaucoup d’autonomie et attend des équipes qu’elles communiquent spontanément.
- Il demande aussi des changements dans l’organisation, l’esprit LeSS est qu’il faut réduire la taille des Produits au maximum et LeSS est un pis-aller. L’organisation doit rester concentrée sur l’objectif de minimiser la taille des Produits et des équipes.
- Lors d’Évènements auxquels toute l’équipe ne peut pas assister, des membres de l’équipe (des développeurs donc) vont la représenter
- Le rôle de Product Owner unique centralise des responsabilités critiques sur une unique personne à une échelle encore plus grande que Scrum.
- Il encourage le contact direct entre utilisateurs et développeurs afin de libérer du temps pour que le Product Owner puisse remplir son rôle. Dans de nombreuses entreprises, cela requiert un gros changement de culture.
Gestion des dépendances : ⭐✩✩ La gestion des dépendances repose sur la maturité des équipes et leur capacité à communiquer efficacement. LeSS propose quelques mécanismes pour aider mais n’impose rien donc on ne peut pas dire que le Framework lui-même aide à gérer les dépendances.
Souplesse : ⭐⭐⭐ LeSS vise a minima un Incrément Produit livrable à chaque Sprint, il est donc fait pour une boucle de feedback rapide et donne de bonnes opportunités de s’adapter.
Couverture : ⭐⭐✩ En voulant limiter la complexité de son Framework, LeSS propose relativement peu de choses dans sa structure “by the book” mais propose de nombreuses options pour aider à son bon fonctionnement.
Scrum@Scale
Jeff Sutherland, l’un des deux fondateurs de Scrum et l’un des signataires originaux du Manifeste Agile a créé son propre Framework à l’échelle : Scrum @ Scale (S@S).
S@S est très agile tant qu’il n’inclut pas trop d’équipes mais sa Minimum Viable Bureaucracy devient vite lourde à mesure qu’on ajoute des niveaux.
Dans ce Framework, les équipes, composées idéalement de 5 Développeurs, un Product Owner et un Scrum Master chacune, sont regroupées en Scrum of Scrum de moins de 5 équipes.
Pour gérer le passage à l’échelle S@S utilise le concept de Minimum Viable Bureaucracy qui doit rester assez resserrée pour permettre des décisions rapides et efficace.
En haut de l’échelle, 2 groupes forment la Minimum Viable Bureaucracy :
- L’Executive MetaScrum forum (EMS), qui se concentre sur ce que produit le Scrum of Scrums
- L’Executive Action Team (EAT) qui se concentre sur comment produire mieux.
S’il y a besoin de plus d’un niveau de Scrum of Scrum, on peut créer des Scum of Scrum of Scrum composés de moins de 5 SoS, l’équivalent de l’EMS à l’échelle intermédiaire est alors le MetaScrum (MS) animé par un Chief Product Owner (CPO) et l’Action Team, animé par le Scrum of Scrums Master (SoSM)
En théorie, on peut créer autant de niveaux de Scrum of Scrums que nécessaire (SoSoS, SoSoSoS….)
Pour des équipes de moins de 7 personnes réunies en SoS de moins de 5 équipes, la configuration standard peut donc aller jusqu’à 35 personnes puis 175 si on ajoute un 3e niveau, 875 au 4e puis 4000 etc…
Source : https://www.scrumatscale.com/scrum-at-scale-guide-online/
Tous les Évènements Scrum sont repris à l’échelle et S@S produit un Incrément livrable par Sprint
Taille des équipes : 8 – ∞
Facilité d’accès à la documentation : ⭐⭐⭐ Tout est disponible sur le site www.scrumatscale.com/scrum-at-scale-guide-online/ et des formations sont proposées par Scrum Alliance, la documentation est aussi simple et lisible que l’est le Scrum Guide
Facilité de mise en place : ⭐✩✩ S@S suppose une implication directe du top management dans l’EAT avec une forte volonté de transformer l’entreprise vers plus d’agilité. De plus, la taille recommandée des équipes est plutôt petite ce qui peut rapidement représenter un challenge pour réussir un découpage qui a du sens.
Gestion des dépendances : ⭐⭐✩ S@S a des instances pour gérer les dépendances mais pas de mécanismes clairement explicités. De plus la structure moins horizontale (pour une taille équivalente à SAFe, S@S nécessite un niveau de plus) rend les échanges moins faciles dans le cadre du Framework et il faut compter sur la culture d’entreprise et les relations interpersonnelles entre les membres des équipes pour y remédier.
Souplesse : ⭐⭐✩ Avec un seul niveau S@S est simple et réactif, en théorie il doit le rester quand on ajoute des couches mais sa Minimum Viable Bureaucracy grossit plus vite que les autres.
Couverture : ⭐⭐⭐ S@S propose des instances pour gérer tout type de cas d’usage. Il est un peu moins explicite que SAFe sur le comment mais reste très complet.
Spotify
Le “modèle Spotify” attire ceux qui veulent reproduire la success story de l’entreprise Spotify.
Pourtant, Spotify ne propose rien car les auteurs originaux précisent dès l’article sur lequel se base ce “modèle” que c’est un retour d’expérience sur l’état de leur organisation à un instant T. Ils ne présentent pas vraiment un Framework, juste un modèle d’organisation matricielle utilisable comme point de départ pour construire sa propre structure.
Dans cette organisation les équipes sont appelées Squads et sont regroupées en Tribus qui peuvent cohabiter et pour lesquelles il n’y a pas de taille maximum clairement définie même s’il est difficile de faire efficacement travailler plus de 10 équipes de 10 personnes par tribu.
Les membres des Squads sont aussi membre d’un Chapitre (communauté de rôles au sein d’une Tribu comme par exemple le Chapitre Développement Backend ou le Chapitre Test) et peuvent rejoindre une Guilde (communauté de pratique à l’échelle de l’entreprise comme la Guilde des Agile ou la Guilde Technologie Web).
Source : https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf
Taille des équipes : Jusqu’à 100 personnes par Tribu
Facilité d’accès à la documentation : ⭐⭐⭐ Très facile d’accès, simple et rapide à lire et à comprendre. L’article original est ici : https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf
Facilité de mise en place : ⭐⭐⭐ c’est juste un découpage organisationnel et quelques mécanismes de synchronisation.
Gestion des dépendances : ⭐⭐✩ Un des principes de Spotify est que n’importe qui peut modifier n’importe quel composant, ce qui peut à la fois réduire les dépendances et améliorer l’autonomie des équipes mais aussi ajouter des risques. Le modèle propose quelque rôles et outils pour assurer l’efficacité de l’organisation, en particulier un document recense les dépendances remontées par les Squads et des System Owners supervisent les composants et peuvent détecter des adhérences. Les guildes et les Chapitres apportent aussi de la transversalité et peuvent amener des discussions qui permettront de voir certains problèmes en amont.
Souplesse : ⭐⭐✩ Ce modèle n’impose pas de mécanisme favorisant ou inhibant particulièrement les changements de cap mais le découpage en Squads indépendants permet de facilement réorienter l’effort à leur niveau.
Couverture : ✩✩✩ Le modèle ne présentant que très peu de choses hors de l’aspect organisationnel, il est nécessaire de le compléter avec un cycle de vie défini ailleurs.
Conclusion
Contrairement à ce que l’on pourrait penser, SAFe, qui est le Framework le plus lourd étudié ici, sera souvent celui qui est le plus implémenté, car il propose le moins de chamboulements dans une grande organisation. LeSS, qui est le plus léger, demandera le plus de préparation, de formations et d’acculturations en amont.
Spotify quant à lui est simplement un modèle d’organisation sans véritable workflow qui ne peut donc se suffire à lui-même. On peut l’associer à d’autres outils comme SAFe et créer un mix parfois appelé SpotiSAFe.
Il faut se rappeler que l’Agilité a pour valeur fondamentale de répondre aux changements et de s’adapter au contexte. Plutôt que d’appliquer un Framework à la lettre il est souvent bénéfique de l’utiliser comme une boite à outils.
