Introduction
L’agilité à l’échelle est un sujet brûlant pour les entreprises cherchant à devenir plus flexibles. Environ la moitié d’entre elles envisagent d’utiliser des frameworks agiles pour gérer des projets plus importants. Pourquoi ? Parce que l’agilité, qui consiste à s’adapter rapidement, est essentielle à l’ère moderne.
Les frameworks agiles, comme SAFe et LeSS, aident à coordonner de nombreuses équipes travaillant sur de gros projets. Ils offrent une meilleure vision d’ensemble, plus de transparence et de qualité.
Un exemple marquant de l’adoption de l’agilité à l’échelle est Spotify. La société de streaming musical a mis en place un modèle d’organisation agile appelé “Spotify Model” qui a fait école.
Points Clés
Dans cet article, nous vous expliquerons pourquoi l’agilité à l’échelle est essentielle, comment les frameworks agiles fonctionnent, les avantages, les défis et des exemples concrets d’entreprises, y compris Spotify, qui ont réussi. Préparez-vous à découvrir comment les entreprises restent agiles, même à grande échelle.
D’après Gartner, SAFe , Scrum of Scrum et Spotify sont les frameworks qui ont réussi à répondre à plus de 25% des besoins des entreprises.
Il existe plusieurs cas possibles d’agilité à l’échelle
Plusieurs équipes 1 produit
Exemples : Nexus, LeSS
Plusieurs équipes Plusieurs produits liés
Exemples: SAFe, Spotify
Un département, une division ou une société
Point Clé
la nécessité de passer à l’échelle découle de la demande croissante de réactivité, de la complexité des projets, et de la quête d’une meilleure efficacité. Elle oblige les entreprises à adopter des cadres agiles pour rester compétitives sur le marché moderne.
Les Avantages et les Défis de l’Adoption de l’Agilité à une Grande Echelle
Avantages:
Meilleure coordination : L’agilité à l’échelle permet de coordonner efficacement les activités de multiples équipes, évitant les chevauchements et les conflits.
Vision globale : Les cadres agiles offrent une vue d’ensemble des projets, aidant les dirigeants à suivre la progression.
Transparence accrue : L’agilité favorise la transparence en partageant l’information sur l’avancement, les obstacles et les problèmes.
Livraison plus rapide : Les pratiques agiles à l’échelle accélèrent la livraison de produits ou services, améliorant la réactivité.
Qualité améliorée : Les processus agiles mettent l’accent sur la qualité du travail, grâce à la détection précoce des problèmes et aux tests continus.
Réduction des risques : En planifiant et en collaborant continuellement, les entreprises réduisent les risques de déviations et d’erreurs.
Satisfaction des clients : L’adaptabilité de l’agilité répond rapidement aux besoins changeants des clients, améliorant la satisfaction.
Culture de l’innovation : L’agilité encourage l’innovation et l’amélioration continue, stimulant la créativité.
Meilleure gestion du changement : Elle facilite la gestion des changements en favorisant l’adaptabilité et la réactivité au sein de l’organisation.
Défis
Résistance au changement : Les équipes ou les membres du personnel peuvent résister au changement de culture et de pratiques de travail induit par l’agilité à l’échelle.
Complexité de la coordination : Coordonner de multiples équipes travaillant sur de grands projets peut être complexe, nécessitant des mécanismes de communication efficaces.
Besoin de formation : L’adoption de l’agilité à l’échelle nécessite une formation substantielle pour que les équipes et les dirigeants comprennent les nouveaux cadres et pratiques.
Surcharge d’information : La multiplication des réunions et des interactions peut entraîner une surcharge d’information pour les équipes, ce qui peut être contre-productif s’il n’est pas géré correctement.
Défis de la communication : La communication efficace entre de nombreuses équipes est essentielle pour éviter les malentendus ou les lacunes dans la communication.
Changement de structure organisationnelle : L’adoption de l’agilité à l’échelle peut nécessiter des changements dans la structure organisationnelle, source de résistance et de défis.
Surdimensionnement de la planification : La planification excessive peut aller à l’encontre du principe d’agilité, nécessitant de trouver le bon équilibre entre la planification et l’adaptation.
Complexité technologique : Les projets de grande envergure peuvent impliquer des systèmes et des architectures complexes, rendant la mise en œuvre de l’agilité plus difficile sur le plan technique.
Important !
En surmontant ces défis, les entreprises peuvent exploiter les avantages de l’agilité à l’échelle, mais il est essentiel de reconnaître que cela nécessite un engagement et un effort continus.
Etude du Framework SAFe
Contexte
Le framework SAFe, dont les bases ont été établies par Dean Leffingwell en 2011, est spécialement conçu pour les organisations de projets composées de plusieurs équipes travaillant sur divers produits. Il est adapté aux organisations dont les équipes peuvent varier en taille, allant de 50 à 125 membres, voire plus, et qui opèrent à un niveau de maturité élevé, tel que le niveau 4.
Les niveaux SAFe
Il définit plusieurs niveaux pour organiser et gérer les activités agiles à différents niveaux de l’entreprise. Voici une description des trois principaux niveaux de SAFe : Portfolio, Program, et Team :
- Niveau du Portefeuille : Ce niveau se concentre sur la vision, la stratégie, et la gestion des investissements au niveau de l’entreprise.
- Niveau du Programme : Au niveau du programme, plusieurs équipes travaillent ensemble pour développer des solutions complexes, en planifiant, coordonnant et exécutant leurs travaux.
- Niveau de l’Équipe : Les équipes agiles réalisent le travail de développement concret, en planifiant des sprints, en livrant des fonctionnalités et en gérant leur propre travail.
Ces trois niveaux permettent à SAFe de s’adapter à la gestion de projets agiles à grande échelle au sein des organisations.
Organisation SAFe
Process SAFe
Le Scaled Agile Framework (SAFe) repose sur plusieurs processus clés pour coordonner et gérer le développement à l’échelle. Voici une description des processus SAFe :
PI Planning (Program Increment Planning) :
- Le PI Planning est un événement majeur dans SAFe qui se produit à intervalles réguliers, généralement tous les 8 à 12 semaines.
- L’objectif est de coordonner et de planifier le travail des différentes équipes au sein de l’Agile Release Train (ART) pour une période donnée, appelée “Program Increment” (PI).
- Au cours de cet événement, les équipes définissent les objectifs et les objectifs de PI, planifient les fonctionnalités à développer, identifient les dépendances et établissent un plan de livraison.
Program Increment (PI) :
- Un PI est une période de temps d’environ 8 à 12 semaines où les équipes travaillent ensemble pour développer des fonctionnalités ou des solutions.
- Chaque PI a un objectif clair, et à la fin de chaque PI, une partie de la solution est prête à être livrée.
Innovation and Planning Sprint :
- C’est un sprint particulier qui a lieu à la fin de chaque PI et qui est dédié à l’innovation, à l’identification des problèmes techniques et à la planification pour le prochain PI.
- Les équipes se concentrent sur l’amélioration, la rétrospective, et la préparation du backlog pour le PI suivant.
Sprints :
- Les sprints sont des itérations de travail courtes, généralement de 2 à 4 semaines, où les équipes développent et livrent des fonctionnalités.
- Les sprints permettent un développement itératif et incrémental, avec une planification de sprint, des revues et des rétrospectives à la fin de chaque itération.
Ces processus dans SAFe visent à créer un alignement stratégique et à coordonner efficacement le travail des équipes, tout en maintenant une flexibilité et une capacité d’adaptation pour répondre aux besoins changeants du marché. Cela permet aux grandes organisations d’adopter des pratiques agiles tout en gérant des projets complexes à grande échelle
Etude du Cas Spotify
Contexte
Spotify a adopté l’agilité à l’échelle en raison de sa croissance rapide et de la nécessité de gérer efficacement un grand nombre d’équipes travaillant sur des projets complexes. Vers 2012, l’entreprise avait plus de 30 équipes de développement et près de 600 ingénieurs travaillant sur son produit. Cette croissance rapide était accompagnée d’une augmentation significative du nombre d’utilisateurs et d’abonnés payants de Spotify, soulignant ainsi la nécessité de mettre en place une structure d’agilité à l’échelle pour gérer cette complexité tout en maintenant une culture d’innovation.
L’organisation chez Sportify
De l’Idée au Produit
Spotify a intégré le modèle “Think it, Build it, Ship it, Tweak it” pour développer et améliorer ses produits de manière agile et itérative, garantissant ainsi une réactivité constante aux besoins des utilisateurs et aux évolutions du marché. Cette approche a contribué au succès durable de Spotify.
Le modèle “Think it, Build it, Ship it, Tweak it” est un processus itératif de développement de produits ou de logiciels qui se déroule en quatre étapes :
- Think it (Pensez-y) : Cette phase implique la génération d’idées, la définition des objectifs du produit et la planification.
- Build it (Construisez-le) : Après la phase de réflexion, les équipes passent à la création effective du produit.
- Ship it (Lancez-le) : Une fois construit, le produit est mis à disposition des utilisateurs.
- Tweak it (Ajustez-le) : Après le lancement, des améliorations continues sont apportées en fonction des retours des utilisateurs et des besoins du marché.
Ce modèle favorise l’agilité, l’adaptabilité et l’innovation continue, permettant d’améliorer constamment le produit en réponse aux commentaires des utilisateurs et aux évolutions du marché
Choix d’un Framework d’Agilité à l’Echelle
CULTURE, PRATIQUES ET TRANSFORMATION AGILE
- Les frameworks Agile à l’échelle s’adresse autant aux équipes qu’à l’organisation
- Plus l’organisation est agile, moins la définition de process, rôles et de pratiques est importante
- Si il est important de changer l’organisation et sa culture, il y a différentes approches : Top Down et Bottom Up
- « Si la Révolution vient d’en bas,la Transformation vient d’en haut »
- Les managers ont le rôle central dans la transformation agile de leur organisation
- Devenir Agile c’est le juste équilibre entre le Chaos et la Bureaucratie
MANAGEMENT AGILE
Pour réussir une transformation agile :
- Il faut travailler avec les équipes pour les faire devenir plus agile : rituels, conception, tests, rythme, collaboration et surtout amélioration continue (approche bottom-up)
- Il faut changer l’organisation pour modifier la culture
Les managers ont le rôle central dans la transformation agile et particulièrement dans les domaines suivants :
- Culture : Inspirer un changement de culture sur la durée
- Organisation : Casser les silos
- Gestion du flux de travail : Sortir du « mode projet »
- Développement des équipes : « Leader as developper of people »
TRANSFORMATION AGILE ET CHOIX DU FRAMEWORK
Nous avons 2 opposés :
- SAFe : framework complet proposant une approche top-down
- Spotify : qui n’est pas un framework mais représente le changement de culture réussi
Plus l’organisation est historique et grosse, plus le changement de culture sera compliqué
- Une start-up aura moins de soucis à mettre en place une approche devops, une architecture micro-services qui vont soutenir une organisation et une culture agile
Le choix du framework doit se faire en fonction de nombreux critères : culture d’entreprise, silos de l’organisation, maturité des équipes, valeurs de l’entreprise, sponsoring, investissement, …
CHOIX POSSIBLES:
1-Investir dans un framework complet : Safe
Onéreux et choix top down fort
2-Miser sur la culture d’entreprise : Spotify
N’est pas adapté à la plupart des organisations
3-Choisir un Framework « intermédiaire » : Nexus, Less
Reste limité sur des organisations ou projets complexes
4-Adapter la démarche/ framework à l’organisation
Nécessite un support du management et une internalisation de la démarche (peut être partiel)
LES PRINCIPAUX ENSEIGNEMENTS
ORGANISATION GLOBALE ET TAILLE D’ÉQUIPE
La taille idéale des équipes se situe entre 5 à 8 personnes
La taille maximum de personnes travaillant ensemble est limité à 150 personnes colocalisés (règle de Dunbar)
Un Product Owner dédié par équipe
Un Scrum Master peut gérer jusqu’à 3 équipes auto-organisées
Les équipes sont autonomes avec peu ou pas de dépendances avec les autres équipes
Possibilité d’avoir une équipe transverse aidant les autres équipes à être autonomes
BACKLOG ET SYNCHRONISATION
Un Backlog par Product Owner
Possibilité d’avoir un Backlog de Features au niveau programme géré par un PO Global (ou par domaine)
Dissocier le niveau User Stories de Features.
La synchronisation
Se fait par des rituels supplémentaires principalement au niveau ProductOwner et Scrum Master.
Un PO Global et un Scrum Master Global peuvent organiser la synchronisation.
Les dépendances
doivent être gérés principalement par
Features.
RoadMap
Les Product Owners maintiennent ensemble une Roadmap ou un Plan de
Release.
Deux niveaux de planification possible au niveau de la Release (ou increment ) et au niveau des Sprints
CADENCE ET COORDINATION
Cadence
Toutes les équipes sont alignés sur la même cadence (Idéalement 2 semaines)
Release Management
Le cas échéant, le PO global gère les Releases et les Features associés
Les Product Owners de chaque équipe gère
les Sprints et les US associés.
DÉMARCHE DEVOPS OBLIGATOIRE
Le produit doit être incrémenté de façon globale tous les Sprints
Idéalement être capable de livrer par fonctionnalité ou par composant de façon
autonome
Inclure les OPS dans la démarche
Possibilité d’avoir une équipe transverse sur les problématiques d’intégration et d’architecture globale.
Entre 10 et 20% du temps des développeurs est consacré à l’innovation (hack time)
Possibilité d’avoir une équipe transverse sur les problématiques d’intégration et d’architecture globale.
CADENCE ET CULTURE
Smart Budget = gestion budgétaire Lean
Gérer un flux de travail et arrêter l’effet « start / stop » des projets
Définir un plan de transformation
Revoir régulièrement le modèle et l’améliorer
0 commentaires