Rechercher

Avant de parler d’agile à l’échelle, il nous faut, au préalable, définir ce qu’est l’agilité. HBR France nous propose la définition suivante : « Une entreprise agile est une entreprise capable de mobiliser son intelligence collective pour créer de la valeur et évoluer de façon itérative et en continu, avec une économie de moyens et d’énergie, et en créant les conditions d’épanouissement. »

En clair, il s’agit d’une méthode agile née lors de la signature en 2001 d’un « manifeste agile » rédigé par 17 professionnels du développement de logiciels à l’occasion d’une conférence. L’agile est applicable, le plus souvent, à la production de code informatique et elles prônent un développement incrémental par cycles courts, autour d’équipes pluridisciplinaires qui travaillent de façon synchronisée sur un même objectif. 

Néanmoins, la méthode s’est avérée être très efficace dans toute l’organisation (RH, Marketing, Finance etc..) et c’est aussi pour cela qu’on parle d’agile à l’échelle.

L’agile à l’échelle, c’est quoi ?

L’agilité à échelle, autrement appelée « Agile@Scale » est tout simplement la mise en place d’un cadre pour faire travailler plusieurs équipes agiles ensemble. 

L’agile à l’échelle inclut également la transformation globale d’une entreprise : ce qui représente un beau travail sur la culture d’entreprise mais aussi sur le passage d’une organisation projet à une organisation orientée produit. 

Quels sont les vrais enjeux qui se cachent derrière l’agilité à l’échelle ?

  • Le premier enjeu c’est la culture d’entreprise. On peut dire que l’Agile c’est 30% de pratiques/outils et 70% de culture. Ces méthodes sont, avant tout, destinées à rendre autonomes les équipes et à abandonner les chaînes de validation envers le grand chef suprême qui prend toutes les décisions. La difficulté majeure est de développer le « mindset » nécessaire à l’esprit du travail collectif pour désiloter et lever les freins culturels.
  • Le deuxième enjeu est l’accompagnement. Une organisation ne se transforme pas en un jour et il n’existe pas de mode opératoire. Un des enjeux est de comprendre quel est le vrai besoin d’une organisation et d’appliquer le modèle le plus adapté.
  • Le troisième enjeu est de suivre la transformation, comprendre la valeur ajoutée pour les équipes et garder le bon rythme dans le temps.

Exemples et cas d’usage avec le modèle Spotify et celui de SAFe®

Il existe plusieurs frameworks d’agilité à l’échelle. En voici quelques exemples: Le modèle Spotify (Internally created methods), SAFe, LeSS et Scrum Of Scrum (SOS). Dans cet article, nous allons développer deux de ces méthodes. 

Le modèle Spotify

Cette méthode est propre à l’entreprise qui porte ce nom. Elle a été publiée par Henrik Kniberg et Anders Ivarsson en 2012. Ce modèle a été présenté par Spotify après une maturation de 3 ans qui a vu les processus et les méthodologies évoluer. Les éléments clefs de ce modèle sont les “Squads”. La squad est une équipe pluridisciplinaire et autonome sur un périmètre ou une fonctionnalité pour concevoir, implémenter et opérer. Sa taille varie de 5 à 10 personnes maximum qui sont totalement autonomes, elles décident elles-mêmes de la méthodologie agile à appliquer : scrum, scrumban, kanban, lean startup, etc… Ces squads sont le plus souvent accompagnés par un coach Agile et elles sont regroupées au sein de “Tribus”. Ces tribus doivent regrouper des squads qui travaillent sur un même enjeu fonctionnel ou technique ; l’objectif étant de faire des regroupements qui ont du sens au niveau de l’organisation. Il a été conseillé de limiter la taille de ces tribus à 80 personnes pour garantir un fonctionnement optimal. Enfin, viennent s’ajouter les “chapitres” et les “guildes”. Ces regroupements ont pour objectif de favoriser la transmission et le partage mais chacun avec sa spécificité. Les chapitres sont des regroupements de profils similaires dans une tribu. Chaque chapitre aura un leader qui sera responsable du management et du développement RH des membres de son chapitre. Les guildes sont des regroupements, des communautés autour d’un intérêt commun sans aucune obligation et basé uniquement sur le volontariat. Cela va permettre aux collaborateurs de développer les compétences qui les intéressent.

Le modèle SAFe® Scale Agile Framework

SAFe® est un modèle opérationnel qui complète le modèle Spotify sans venir en opposition à ce modèle. SAFe® a été créée en 2011 par Dean Leffingwell qui partage ses propres expériences en matière de transformations agiles. La méthode SAFe® donne une solution clé en main à une entreprise souhaitant appliquer l’agile à l’échelle sur des programmes embarquant de 50 à 150 personnes. La base de SAFe® est de définir 3 niveaux de gouvernance pour l’agile à l’échelle :

  1. La gestion de portefeuille projet 
  2. La gestion de programmes
  3. La gestion d’équipes 

Pour articuler ces niveaux de gouvernance, il y a un concept qui centralise la méthodologie SAFe® : c’est le “Train” ou “Art” pour Agile Release Train. Concrètement, le train représente le backlog nécessaire au niveau programme pour atteindre l’objectif défini. Ce Train embarquera l’ensemble des passagers et acteurs SAFe® quels que soient leurs niveaux (portefeuille de projets, programme, équipes) et sera la base de travail de chaque “Program Implement Planning” (définition du travail à réaliser dans les 3 mois à venir). Les niveaux de gouvernance doivent être définis pour comprendre le sens de cette méthodologie. 

Le niveau « Gestion de portefeuille projet» est lié au top management de l’entreprise. Son objectif est d’apporter de la cohérence dans la stratégie de l’entreprise. Orienter la stratégie d’investissement pour définir des portefeuilles contenant des Epics niveau Business. Ces Epics sont définis par des “customers” conjointement avec des “solution managers” 

Le niveau « Programme » est le niveau où les Epics Business sont découpés pour définir un ou plusieurs trains via des Program Epics et des Features. Le niveau programme est porté par des “products managers” et des “business owners”. 

Le niveau « Équipes » équivaut à la scrum team qui va produire dans le but de participer à la réalisation de features et indirectement répondre aux Programs Epic et d’Epics business. Ce niveau représente le niveau de production de la méthodologie SAFe® incarné par le “Product Owner”.

Et pour aller plus loin avec l’agilité à l’échelle ?

Lorsque l’on travaille à transformer une entreprise vers plus d’agilité, la meilleure stratégie n’est pas d’appliquer à la lettre une quelconque méthodologie agile à l’échelle, sans prendre en compte son contexte. L’agilité ne doit pas se limiter au programme DSI. Pour que l’effet soit optimal il faut embarquer l’ensemble des équipes à tous les niveaux. Les feedbacks utilisateurs ont aussi un sens dans ces méthodes. Les utilisateurs sont des acteurs à part entière mais il faut pouvoir le comprendre à tous les niveaux. Henrik Kniberg d’ailleurs disait que : « Être agile n’est pas une solution unique, et ce n’est SURTOUT pas le but ultime. »

Photo by Daria Nepriakhina on Unsplash

Logo Discord

Envie de converser en mode Cozy Web avec toute la rédac’room et la formidable communauté bienveillante de plus de 500 personnes qui ont rejoint #BonjourPPC Le Digital pour tous ?
On vous accueille ici avec grand plaisir.

vignette podcast bonjourPPC

Tu cours après le temps ?
Si ça te dit de te joindre à nous et recevoir la newsletter hebdo te permettant d’apprendre plein de choses et de ne pas rater le train du digital, il te suffit de t’inscrire ici

Proposé par
Chadia Ben Ameur

Expert indemnisation – relation client

Room @ppc |Rt #i4emploi

Laisser un commentaire

A lire dans cette thématique

Deux StormTroopers en Lego branchent un cable de Mac

La digitalisation de Lego

Si tu es né·e entre 1960 et 2010, il est fort probable que tu aies à un moment donné joué avec des briques Lego. Il est même possible que...

La Playlist du DJ

C’est à lire

La newsletter