Scaling Agile ou l’agilité à l’échelle
Scaling Agile ou l’agilité à l’échelle
L’agilité à l’échelle, ou «Agile@Scale» ou parfois « Scaling Agile », consiste à mettre en place un cadre pour faire travailler plusieurs équipes ensemble et en parallèle, ces équipes travaillant bien sûr elles-mêmes en mode Agile.
La vision du Scaling Agile
Pour mettre en place cette approche, il faudra créer une organisation qui permettra de faire travailler de manière transverse toutes ces équipes ensemble autour d’un même produit (ou de plusieurs produits), que ce soit pour de la création d’un produit ou d’une modification de version.
Mettre en place l’agilité à l’échelle incluera également la transformation profonde et globale de l’entreprise (management, budget, ressources humaines, métiers, commerce, marketing, chaîne logistique d’approvisionnements et de livraisons, partenariats, contrats, … ).
Ce sont le coaching, le mentorat et la formation qui permettront aux collaborateurs de s’intégrer dans cette transformation.
Ceci implique un changement de paradigme, et il est difficile de transformer réellement l’entreprise si l’ensemble de l’entreprise (en particulier le Management) n’adhère pas à cette vision systémique.
Pour cela, il existe plusieurs modèles ou frameworks (cadres de travail) différents qui permettent de faire de l’agilité à l’échelle.
Ceux-ci sont en général assez différents et répondent à des problématiques et des enjeux distincts.
Certains frameworks d’agilité à l’échelle sont aussi liés à des philosophies qui diffèrent par leur approche du coaching Agile.
Sur quoi agit le Scaling Agile
Lorsqu’une Organisation souhaite passer à l’agilité à l’échelle, c’est-à-dire introduire l’agilité à tous les niveaux de l’entreprise, il faut un changement d’approche par rapport aux projets menés traditionnellement en « cycle en cascade » ou « cycle en V ».
Et plutôt que continuer à travailler dans une Organisation en silos, il faudra introduire de la transversalité et de l’approche globale ou systémique centrée sur le Client.
Mais avant de passer à l’agilité à l’échelle, il faudra commencer par maîtriser les méthodologies Agile de base (Scrum, Lean, Kanban, Crystal clear, ASD, FDD, DSDM, XP …).
Dans quel but passer au Scaling Agile ?
Le Scaling Agile permet de mieux s’adapter et se réadapter à un marché qui évolue de plus en plus vite dans des univers complexes et changeants.
Cela va permettre aussi de raccourcir le « Time to Market » en diminuant le « Lead Time », notion essentielle pour se démarquer de ses concurrents.
Cette démarche centrée sur une approche produit va faciliter aussi l’innovation et l’intelligence collective.
Les pré-requis pour le passage à l’échelle (Scaling Agile)
Les pré-requis pour un passage à l’échelle sont :
- une bonne compréhension des valeurs, principes et concepts Agile tels que décrits dans le Manifeste Agile
- un changement de paradigme facilité par l’approche Lean thinking
- de Pla compréhension du besoin de synchronisation et de cadencement qui va faciliter la coordination des différentes équipes
- la création d’un écosystème de Partenaires permettant la création de valeurs pour chacune des Parties Prenantes
Les principaux modèles de passage à l’agilité à l’échelle (Scaling Agile)
Les principaux modèles de passage à l’agilité à l’échelle sont :
- Scrum of Scrum
- Scrum@Scale
- Nexus
- Discipline Agile (DA) et Discipline Agile Delivery (DAD)
- Spotify
- Large Scale Scrum (LeSS)
- SAFe, the Scaled Agile Framework
Les méthodes ou frameworks nécessaires pour le passage à l’échelle (Scaling Agile)
Les méthodes Agile ou frameworks Agile nécessaires pour faciliter le passage à l’échelle ou Scaling Agile sont :
- Lean Product Development
- framework Agile Scrum
La démarche DevOps est au cœur de l’agilité à l’échelle, elle n’est surtout pas optionnelle.
La démarche DevOps est une base de travail intéressante au service de valeurs Agile ou d’une philosophie Agile adaptée à l’ensemble de l’Organisation et à tout son écosystème de Partenaires.
Il faut être conscient qu’aucune approche d’agilité à l’échelle n’est la solution unique à toutes les problématiques.
Il faut réfléchir en fonction de l’environnement, du contexte, de l’écosystème de partenaires et des enjeux et voir quel va être le modèle le plus approprié.
Le modèle SAFe se démarque par son approche structurée « Entreprise » et son succès commercial.
Les Feature Teams
Les Feature Teams sont des équipes qui travaillent de manière autonome.
Une « Feature Team » est une équipe qui développe,
teste, déploie et idéalement livre ses « Features ».
Une Feature Team est une équipe Agile multi-disciplinaire, cross-fonctionnelle, auto-Organisée, autogérée (voir Agile Teams).
C’est une notion indispensable pour le passage à l’agilité à l’échelle.
Le Scrum Master sera là pour aider les équipes à être autonomes.Elles sont autogérées.
Il pourra être formé et supervisé par le Coach Agile.
Au niveau du management, cette autonomie des équipes est un changement d’approche essentiel et il sera important que le coach Agile accompagne les Managers sur cet aspect, de façon à ce qu’ils puissent favoriser la montée en compétences et en connaissances de leurs équipes.
Le System thinking
L’approche Produit ou System thinking est centrale, c’est elle qui va permettre la coordination, la synchronisation et le cadencement.
Ce qui est essentiel, c’est de réfléchir avec toutes les Parties Prenantes à optimiser la performance du Value Stream plutôt que sur-optimiser une partie de l’activité.
Cela sera organisé dans des séances de « Value Stream Analysis« .
Les nouveaux rôles
Nous connaissions déjà les rôles de Product Owner, Dev Team, Scrum Master.
De nouveaux rôles pour le passage à l’agilité à l’échelle vont être nécessaires :
- Product Management (owns, defines, prioritize the Program Backlog)
- System Architect / Engineer (System Arch/Eng) provides : architectural guidance, technical enablement to the Teams on the Train
- Release Train Engineer (RTE) = Chief Scrum Master for the Train
- Business Owner(s) = Key Stakeholders on the Lean Agile Release Train (ART)
Le rôle de Product Management
Le rôle de Product Management est un rôle essentiel pour le management de programme Agile.
Il est d’autant plus important que nous quittons une démarche Projet pour aborder une démarche Produit, le Lean Product Management sans perdre de vue notre démarche d’excellence et de qualité totale.
Le Product management est le leader sur le Contenu à délivrer (Content Authority).
Il est une sorte de Product Owner Leader.
Product Management has content authority for the Program Backlog. They are responsible for identifying Customer needs, prioritizing Features, guiding the work through the Program Kanban and developing the program Vision and Roadmap.
© Scaled Agile, Inc..
Il s’appuie notamment sur les Product Owner des Scrums Teams (et/ou Business Analyst,… des autres Teams) dans l’idée d’en faire une équipe collaborative centrée sur la création du Program Baclog et sa gestion.
Cette équipe doit être focalisée sur la production de valeur pour le Client (et par là même la création de valeurs pour les Utilisateurs).
Le rôle de System Architect / Engineer
Le System Architect / Engineer (System Arch/Eng) est le leader de la solution Technique à délivrer (Design Authority).
Il s’appuie notamment sur les Développeurs des Scrum Teams (et/ou Architectes, Développeurs,des autres Teams) et la System Team.
Le rôle de Release Train Engineer (RTE)
Le Release Train Engineer (RTE) est le leader sur le Processus et son exécution.
Il s’appuie sur les Scrum Master des Scrum Teams (et/ou Chefs de Projet (CP) des autres Teams).
C’est aussi une sorte de coach pour l’ensemble des équipes qui constituent le Train.
Il est une sorte de super Scrum Master, un Scrum Master Leader.
Le rôle de Business Owner
Les Business Owners ont une ou plusieurs des caractéristiques suivantes :
- ils ont autorité pour engager les moyens humains et financiers demandés par la phase Design et/ou Delivery
- ils sont partie prenantes (clients ou impactés) par le Produit/Service à concevoir (Business, Métier (processus, positions de travail, …)
- ils s’inscrivent dans un temps long, celui du cycle de vie du Produit/Service, donc au-delà du Projet
Pour plus d’informations sur les rôles, consulter l’article suivant : SAFe, roles in the Lean-Agile Enterprise
Le rôle essentiel de la System Team
Puisqu’il y a plusieurs équipes qui travaillent en parallèle, pour faciliter le cadencement et la synchronisation à coordonner, il va donc nous falloir une équipe centrée sur les aspects coordination, c’est la System Team.
The System Team is a specialized Agile Team that assists in building and supporting the Agile development environment, typically including development and maintenance of the toolchain that supports the Continuous Delivery Pipeline. The System Team may also support the integration of assets from Agile teams, perform end-to-end Solution testing where necessary, and assists with deployment and Release on Demand.
© Scaled Agile, Inc..
La System Team fournit les process, outils et support pour intégrer et évaluer le System très tôt dans le cycle de Delivery et le plus souvent possible.
Le périmètre du Programme : le Backlog Program
Le périmètre du produit est représenté par un artéfact appelé Program Backlog.
En effet, il n’y a qu’un seul Program Backlog en relation avec le Product Backlog de chaque Dev Team.
C’est la coordination de ces différents Product Backlogs et la synchronisation et le cadencement qui font l’agilité à l’échelle.
Continuous exploration, Continuous developement, Continuous deployment, Release on Demand
La centration continue sur le Produit permet la « Continuous exploration », le « Continuous developement », le « Continuous deployment » et la « Release on Demand » créatrice de valeurs business pour le Client.
La phase exploration (continuous exploration)
La « continuous integration est décrite ici.
Le Program Kanban
Le Programme est suivi en mode Kanban, ce qui permet de visualiser et manager l’ensemble du flux de valeur dans le Program Kanban.
Ceci permet de diminuer le Lead time.
C’est la fin du « start & stop » du mode Projet, remplacé par l’approche Produit.
Ceci constitue un changement de vision essentiel pour le passage à l’agilité à l’échelle avec un autre regard sur les coûts (voir Lean budgeting).
La priorisation du Program Backlog
La priorisation du Program Backlog se fait par la méthode MoSCoW.
C’est une priorisation par le coût du retard, « Cost Of Delay (CoD) » et la durée.
Si la durée n’est pas facile à estimer, elle peut être remplacée par l’effort de réalisation plus facile à estimer en relatif.
C’est la notion de « Job size ».
Cadencement et synchronisation
Ce sont le cadencement et la synchronisation qui permettent la coordination et la livraison de valeurs.
Le cadencement sans la synchronisation n’est pas suffisant.
La Synchronisation permet d’assurer le Delivery
Comme nous sommes dans une approche Lean, le principe sous-jacent à la synchronisation est d’augmenter la fréquence des boucles d’apprentissage (les feedbacks).
Le principe sous-jacent à la synchronisation et au cadencement est d’augmenter la fréquence des boucles d’apprentissage.
Le cadencement et la synchronisation sont permis par l’approche de planification appelée « PI Planning » (Program Increment Planning).
Le PI Planning
Le PI Planning est une cérémonie de planification du Program Increment, l’artéfact qui sera créé à la fin de chaque itérations menées en parallèle par les différentes équipes constituant le Train.
Ce PI Planning va donner la cadence du Train.
Cette cérémonie dure 2 jours toutes les 8 à 12 Semaines (10 en moyenne).
Le Train est constitué de 50 à 125 personnes, c’est le nombre de Dumbar, nombre idéal pour lancer une transformation.
Tout les Acteurs y assistent.
Le Product Management priorise les Features.
La Dev Team ou équipe de réalisation planifie les différentes Stories et fait une première estimation de ces Stories.
Le travail des différentes équipes est planifié sans oublier bien sûr les dépendances entre équipes.
Ces dépendances seront prises en charge par la System team.
Approche Lean Start-up
Comme nous sommes dans une approche Lean centrée sur la création de Valeurs, il est privilégié une approche de type Lean Startup.
Cette approche de type Lean Startup permet des cycles courts, avec des itérations de 2 semaines (Lean Start-up Cycle).
Ces itérations de 2 semaines menées en parallèle par les différentes équipes constituant le Train vont faciliter le cadencement et la synchronisation.
Réaliser un Program Increment avec SAFe
La réalisation d’un Program Increment avec SAFe se fait avec plusieurs itérations menées en parallèle.
Ce sont le cadencement et la synchronisation qui permettent de créer cet artéfact : le « Program Increment ».
La Roadmap est un engagement et une prévision adaptable de System Demo ( big Review) en System Demo.
Et bien sûr, en parallèle le contact est maintenu tout le long du cycle avec les utilisateurs et en particulier les « Key Users » ou « Personas »; ce qui va permettre de récupérer de l’information et des feedbacks, c’est le « Lean UX Cycle »,.
Ce lean UX Cycle va permettre l’adaptation et la réadaptation
La modélisation
La modélisation doit être réfléchie a minima au niveau programme.
La « System Team » va réfléchir sur l’Architectural Runway.
Le System Architect et la System Team préparent la conception émergente grâce aux Enablers.
Enablers support the activities needed to extend the Architectural Runway to provide future business functionality. These include exploration, infrastructure, compliance, and architecture development. They are captured in the various backlogs and occur at all levels of the Framework.
© Scaled Agile, Inc.null
SAFe Implementation Roadmap
La « SAFe Implementation Roadmap » va nous permettre de mettre en place une démarche et une transformation structurée.
The SAFe Implementation Roadmap consists of an overview graphic and a 12-article series that describes a strategy and an ordered set of activities that have proven to be effective in successfully implementing SAFe. Achieving the business benefits of Lean-Agile development at scale is not a trivial effort, so SAFe is not a trivial framework. Before realizing SAFe’s rewards, organizations must embrace a Lean-Agile Mindset as well as understand and apply Lean-Agile principles. They must identify Value Streams and Agile Release Trains (ARTs), implement a Lean-Agile portfolio, build quality in, and establish the mechanisms for continuous value delivery and DevOps. And, of course, the culture must evolve as well. Based on proven organizational change management strategies, the SAFe Implementation Roadmap graphic and article series describes the steps, or ‘critical moves,’ an enterprise can take to implement SAFe in an orderly, reliable, and successful fashion.
© Scaled Agile, Inc.null
Scaling Agile : avantages et challenges
Scaling Agile : avantages et challenges
x
Sitographie : quelques liens utiles
- Scaled Agile Frameworks in a Nutshell
- Scaled Agile Framework
- Large Scale Scrum
- Discipline Agile Delivery
- DSDM and AgilePM
Sitographie : autres articles sur SAFe
- The 5 core competencies of the Lean-agile Enterprise
- SAFe : Roles in the Lean-Agile Enterprise
- SAFe : a Lean-Agile Mindset
- SAFe : Agile Scaled Framework
../…
Leave a Reply
You must be logged in to post a comment.