Contrairement à ce que beaucoup de gens pensent l’agilité à l’échelle n’est pas une lubie récente, pas plus qu’elle n’a été inventée par la Scaled Agile Corp. Que nenni.
Petit rappel des faits en quelques dates.
- 1986 – „The New New Product Development Game“ Hirotaka Takeuchi et Ikujiro Nonaka publient un article dans la Harvard Business Review qui est considéré comme fondateur.
- 1996 – SCRUM Jeff Sutherland et Ken Schwaber
- 1999 – Extreme Programming Explained de Kent Beck.
- 2001 – Le Manifeste pour le développement agile de logiciels => the “agile manifesto”
Si au commencement l’agilité ne se concentrait que sur une équipe, travaillant de façon autonome et en responsabilité, sur un problème complexe donné pour concevoir, tester, coder, livrer et suivre sa solution logicielle. Trés rapidement la question s’est posée „comment faire quand on est plus qu’une seule équipe?“ 🧐
- 2005 : Craig Larman et Bas Vodde commencent à développer et promouvoir LeSS (Large-Scale Scrum), une extension/évol de Scrum pour des équipes multiples travaillant sur le même produit.
2005 !! 😱 Il y a 20 ans !!!
Puis tout s’enchaine et s’accélère :
- 2007 : Dean Leffingwell commence à formaliser (et a publier) SAFe, visant à appliquer les pratiques agiles à des organisations à grande échelle.
- 2007- Enterprise Kanban (ou Portfolio Kanban) par David J. Anderson.
- 2011 – Publication de SAFe 1.0 Dean Leffingwell et Drew Jemilo.
- 2012 – Publication du livre blanc Scaling Agile @ Spotify, par Henrik Kniberg et Anders Ivarsson
- 2012- Agile Fluency Model de Diana Larsen and James Shore
- 2014 – Scrum@Scale – Jeff Sutherland.
- 2014 – XScale par Peter Merel.
- 2015 : Open Space Agility – par Daniel Mezick
- 2015 – Choose Your WoW!, de Scott Ambler et Mark Lines pose les bases de Discipline Agile Delivery
- 2015 – NEXUS – Ken Schwaber.
- 2015 – FAST Agile de Ron Quartel.
En 10 ans tout est posé ou presque. Que c’est-il passé depuis 2015 me demanderez-vous ? Pas grand chose
- LeSS => LeSS Huge
- Acquisition de Disciplined Agile par PMI
- et surtout SAFe 1.0, SAFe 2.0, SAFe … SAFe 6.0 qui devient omniprésent et „leader du marché“
Mais cette idée fausse que l’agilité à l’échelle est toute récente et vient de SAFe, n’est pas le seul mythe, et certains de ces croyances peuvent etre problématiques.
Les mythes de l’agilité à l’échelle 🎭
Mythe 1 : L’agilité à l’échelle signifie „simplement“ ajouter plus d’équipes Beaucoup pensent que pour étendre l’agilité, il suffit d’ajouter plus d’équipes agiles.
En réalité, scaler l’agilité nécessite des changements organisationnels profonds, y compris dans la structure de gestion, la culture, et les processus. Ajouter plus d’équipes sans adapter ces aspects conduit souvent à des inefficacités et à une complexité accrue.
Mythe 2 : Un cadre universel fonctionne pour toutes les organisations Il existe une croyance que des cadres comme SAFe, LeSS ou même „le modèle Spotify“ peuvent être appliqués tels quels dans n’importe quelle organisation.
En réalité, chaque organisation a des besoins uniques et ces cadres doivent être adaptés spécifiquement à leur contexte et à leur culture pour réussir
Mythe 3 : Les équipes autonomes n’ont pas besoin de Leadership Un autre mythe est que les équipes autonomes fonctionnent sans aucun leadership.
En réalité, un leadership actif et engagé est crucial pour guider, soutenir et aligner les équipes sur les objectifs stratégiques de l’organisation. Les leaders doivent également favoriser un environnement propice à l’autonomie et à l’innovation
Mythe 4 : L’agilité à l’échelle se concentre uniquement sur les équipes de Développement => et donc sur le Delivery
En réalité, pour réussir, l’agilité doit être adoptée par l’ensemble de l’organisation, y compris les départements de marketing, de finance, de ressources humaines, et autres, afin de soutenir une approche véritablement agile et collaborative
Par ailleurs restreindre le champ uniquement sur le Delivery en déconnectant des phases de Discovery ou Run, c’est c’exposer aux risques mortels de la Feature factory x 100 (une excellente façon de bruler votre argent)
Mythe 5 : L’agilité à l’échelle est juste une mode Certains pensent que l’agilité à l’échelle est une tendance passagère, ou une lubie de grosses entreprises pour se croire agile. On a déja vu plus haut que ce n’est pas récent comme questionnement, et il serait un peu insultant de croire que c’est l’agilité n’est pas envisageable pour les grands groupes ou les industriels.
et bien sûr pour finir Mythe #6 : „agilité à l’échelle = transformation agile“ avec un arrière plan la croyance qu’un changement de culture et d’organisation peut se faire en 3 quarter en suivant une roadmap d’implémentation de votre framework préféré.
Réalité : Un cadre agile n’est pas une transformation, et faire évoluer une culture est un processus continu qui demande du temps, de la patience et de l’engagement.
Les réalités du terrain : retours d’expérience 🌱
Lors de ma conférence à l’Agile Tour Genève 2024, j’ai partagé plusieurs cas concrets d’implémentation de l’agilité à l’échelle :
- LeSS (Large-Scale Scrum) chez un éditeur de logiciels en mode SaaS. L’adoption de LeSS a permis de réduire les silos entre les équipes. Cependant, la transition a été difficile pour certain·e·s managers qui ont dû repenser leur rôle.
- SAFe (Scaled Agile Framework) au sein du groupe AIRBUS, notement sur le projet SKYWISE, mais aussi sur des projets non IT (électromécanique) ou en tant que véhicule de transformation. Les résultats ont été positifs en termes d’alignement stratégique, de ramp up / ramp down rapide (résilience) et de compatibilité culturelle avec la culture trés cadrante / process oriented de l’avionneur.
- Open Space Agility au sein d’une banque, comme strater et catalyseur de transformation de la DSI puis par extension jusqu’aux Métiers. Ce cadre trés léger et peu prescriptif a permis une grande flexibilité et a favorisé l’innovation, mais a nécessité un fort leadership pour „autoriser“ le changement et maintenir la cohésion.
- „Modèle Spotify“ au sein de Spotify 😉
Vous trouverez dans ce slide deck un petit comparatif de ces 4 cadres, sur différents axes : leurs points forts et points faibles, avec quelles type d’orga ou de culture ils fonctionnement mieux, leur modalité d’installation et les couts associés, … c’est éminement subjectif car c’est basé sur mon expertise pour les avoir abondement pratiqués depuis 20 ans.
Une bonne astuce : N’écoutez pas les promesses produits de tout ces cadres (enfin surtout de leurs vendeurs) et basculez en mode “Acceptance criteria” !
On vous promet une „Performance Accrue“ ? questionnez :
- Les cycles de développement sont réduits de X% ?
- La productivité des équipes augmente de Y% ?
- Les délais de mise sur le marché diminuent de Z% ?
et comment est-ce réellement mesuré ? Temps moyen de cycle (Cycle Time) ? Vélocité des équipes? Nombre de releases par période? Certains KPIs sont mieux que d’autres …
Mon avis sur la question ?
agilité à l’échelle ≠ “transformation”
L’agilité à l’échelle n’est pas synonyme de transformation automatique. Vous pouvez (devez?) décoréller les deux : les frameworks d’agilité disponibles sont des cadres “on the shelf” pour vous aider à fonctionner en situation de complexité systémique, mais ils ne sont pas “plug and play” et ne règlent pas toutes vos questions. Leur mise en œuvre requiert une adaptation des humains et de leurs organisations, ainsi qu’une adaptation du cadre lui-même. Ce dernier ne doit pas devenir enfermant ou aliénant.
Les facteurs clé du succés ?
a) une proximité culturelle : Le cadre agile que vous choisissez doit être le plus proche de la culture de l’entreprise, sous peine de rejet précoce. C’est un point de départ, pas un but d’arrivée : vous le ferez évoluer en parallèle de votre propre évolution.
b) un leadership et des collaborateurs engagés : Le soutien et l’implication active de la direction sont essentiels. Les leaders doivent être formé·e·s aux principes agiles et montrer l’exemple. Il est aussi crucial d’impliquer les collaborateur·rice·s à tous les niveaux et de communiquer clairement sur les objectifs et les bénéfices attendus.
c) une tactique de petits pas : Privilégiez une approche itérative incrémentale plutôt qu’une transformation totale d’un coup. Commencez par des projets pilotes, tirez-en des enseignements, et étendez progressivement.
d) de la formation : Investissez dans la formation de vos équipes. L’agilité à l’échelle nécessite de nouvelles compétences et mindsets à tous les niveaux de l’organisation.
e) et surtout de l’adaptabilité : Soyez prêt·e·s à adapter votre approche. Ce qui fonctionne aujourd’hui pourrait ne plus être optimal demain. L’agilité, c’est aussi savoir se remettre en question.
Conseils pratiques :
- Éviter de passer à l’échelle à chaque fois que possible : L’agilité à l’échelle a un coût et des conséquences. Simplifiez l’organisation et le produit autant que possible.
- Découplage et autonomie : Un découplage efficace conduit à une plus grande autonomie, ce qui améliore l’agilité. Paradoxalement, plus vous scalez, moins vous devriez collaborer pour éviter des processus trop lents, risqués et coûteux.
- Sélectionner les bons éléments à rendre agiles : Tout n’a pas besoin d’être agile ou à l’échelle dans une organisation et en meme temps arrêtez de circonscrire par défaut l’agilité l’IT / DSI. Travaillez plutôt par flux de valeur (Value Stream Mapping) pour construire un bout-en-bout qui fait sens. Faites des choix judicieux pour maximiser l’efficacité.
L’agilité à l’échelle n’est pas un simple processus à mettre en place, mais un voyage continu d’apprentissage et d’adaptation. Il n’existe pas de solution miracle, mais en comprenant les mythes et les réalités, en s’inspirant des expériences d’autres organisations, et en restant fidèle à ses valeurs, chaque entreprise peut trouver sa voie vers une transformation agile réussie.
Pour approfondir le sujet, je vous recommande ces lectures :
- „Large-Scale Scrum: More with LeSS“ par Craig Larman et Bas Vodde (2016)
- „Doing Agile Right : Transformation Without Chaos“ par Darrell Rigby, Sarah Elk et Steve Berez (2020)
- “Rethinking Agile” et/ou „Flight Levels: Leading Organizations with Business Agility“ du Dr. Klaus Leopold
- „The Rollout: A Novel about Leadership and Building a Lean-Agile Enterprise with SAFe®“ by Alex Yakyma
- „Tribal Unity: Getting from Teams to Tribes by Creating a One Team Culture“ by Em Campbell-Pretty
Vous souhaitez discuter de votre expérience d’agilité a l’échelle ou vous souhaitez que je vous accompagne ? N’hésitez pas à me contacter ! On va voir ce qu’on peut faire 💪