L’agilité à l’échelle, c’est l’application de méthodes de travail agiles, à l’échelle de l’entreprise. Ainsi la mise en place de l’agilité à l’échelle est un projet d’entreprise dans sa globalité, et pas seulement un projet de la direction informatique. C’est donc une transformation qui devrait impliquer tous les collaborateurs… De prime abord, ça semble déjà compromis pour beaucoup d’organisations…
Pourquoi passer à l’agilité à l’échelle?
Dans les faits, pour la plupart des organisations, passer à l’agilité à l’échelle au sens strict est un vœux pieux. Et c’est d’autant plus vrai quand la taille de l’organisation augmente. D’ailleurs aucune méthodologie ne permet ou ne propose d’aligner tous les collaborateurs. Mais soyons pragmatiques.
L’agilité à l’échelle est possible, et surtout utile pour des projets d’une certaine envergure qui sont de fait en alignement avec la stratégie de l’entreprise et son budget. Et puis il existe différentes méthodes, plus ou moins encadrantes, à choisir en fonction de son besoin et ses contraintes organisationnelles. Même SAFe, méthode la plus connue, propose différents niveaux de mise en place et sera capable de donner un cadre à une entreprise qui souhaite fonctionner en agilité de façon globale.
La mise en place d’une méthode agile à l’échelle sera utile dès qu’il s’agit de synchroniser plusieurs équipes spécialisées qui travaillent dans un même but de transformation à l’échelle de l’entreprise. Par exemple quand celle ci refond son site web, intranet, et boutique en ligne : il s’agit de 3 sites distincts avec leur infrastructure et qui nécessitent des compétences différentes : web design, solutions collaboratives internes, ecommerce, etc. Dans ce cas, il y a plusieurs équipes qui devront s’aligner régulièrement : intégrateurs CMS, Développeurs Front, Ingénieurs infrastructure, intégrateurs Ecommerce, etc.
Quelles méthodes agiles à l’échelle?
Si Scrum est la méthode largement plébiscitée pour cadrer les équipes agiles, quand il s’agit de passer à l’échelle, là le choix est plus vaste et il s’agit de trouver la bonne méthode. Si SAFe jouit d’un succès certain, cette méthode est exigeante et stricte dans sa mise en place. Bien implémentée, elle réserve une grande efficacité, mais demande une grande rigueur. Il en existe d’autres qui peuvent être plus souples, chacune ayant ses avantages et ses limites. Ci après quelques méthodes qui permettent de synchroniser plusieurs équipes pour les grands projets.
Large Scale Scrum (LeSS)
LeSS propose d’appliquer la méthode Scrum à grande échelle, le plus simplement possible pour éviter d’imposer un cadre trop strict. L’idée de LeSS est de faire travailler ensemble plusieurs équipes Scrum pour un même produit. C’est là une des limites de la méthode : dans le cas d’une transformation d’entreprise ou d’un projet plus important encore, la méthode LeSS est pensée pour plusieurs équipes Scrum (8 maximum) avec toujours un seul Product Owner (puisqu’un seul produit). Pour plusieurs produits liés les uns aux autres, LeSS n’est peut être pas la bonne méthode, même sa dérivée LeSS Huge qui autorise plus d’équipes, mais toujours pour le même PO…
LeSS est peut être la méthode la plus facile à implémenter pour un travail à l’échelle, mais elle souffrira rapidement de lacunes pour s’adapter au contexte de chacun. LeSS est donc un framework de base qu’il convient de personnaliser. Cela peut donc aboutir à quelque chose de très efficace au plus proche des particularités de l’organisation, mais également à quelque chose qui le serait beaucoup moins si les ajustements du framework s’avèrent contre productifs. Le choix de LeSS implique alors une vraie maturité sur Scrum et l’agilité en général, au risque de faire dévier la méthode de ses atouts de base. C’est le paradoxe de LeSS: une méthode tentante pour passer à l’échelle car peu contraignante et relativement facile à appréhender, mais qui nécessite d’être enrichie en gardant sa maitrise.
- Nombre d’équipes : 2 – 8
- Nombre de personnes : 15 – 50
Scaled Agile Framework (SAFe)
SAFe est une méthodologie d’agilité à l’échelle complète et très encadrante. Elle propose même un planning de mise en place de la méthode. Celle ci implique en effet souvent une transformation des process de l’entreprise et son implémentation n’est pas à prendre à la légère. Bien intégrée, elle sera d’une grande efficacité. SAFe propose plusieurs strates, et tous peuvent ne pas être déployés :
- Essential : Aligner plusieurs équipes agiles travaillant autour d’un produit complexe.
- Large Solution (Incl. Essential) : Aligner plusieurs équipes pour un ou plusieurs produits qui nécessitent différents cœurs de métier.
- Porfolio (Incl. Essential) : Aligner les équipes avec la stratégie, le budget.
- Full (Incl. Essential + Portfolio) : La méthode Large Solution avec la couche Portfolio. SAFe full est adapté à la transformation de l’entreprise.
SAFe est une méthode populaire parce qu’elle offre un cadre pointu et rassurant, et une modularité selon la taille du projet et le nombre d’équipes à aligner. Sa mise en place est un projet en soi, mais elle ne nécessite pas une expertise des équipes sur Scrum. Dans son déroulé SAFe est assez contraignante notamment parce qu’elle ne néglige pas les cérémonies : le « PI planning » requière la réunion régulière et en présentiel de toutes les équipes pour un alignement complet (mise à jour des dépendances, des avancements, du reste à faire, etc… ).
- Nombre d’équipes : 10 – 25
- Nombre de personnes : 50 – 150
Scrum of Scrums (SoS)
L’approche de Scrum of Scrums est très simple. Elle consiste à construire une démarche Scrum au dessus des équipes déjà en Scrum : les équipes s’alignent donc grâce à la ou les équipes SoS constituées de délégués issus des équipes Scrum. L’objectif de ces équipes mise à l’échelle est d’aligner les équipes Scrum pour synchroniser les livraisons à chaque Sprint.
La mise en place est facile, mais pour être optimale et même fonctionnelle, elle nécessite des équipes Scrum assez petites et de taille la plus homogène possible. De façon générale, l’homogénéité est de mise : la maturité de chaque équipe sur la méthode Scrum doit être assez avancée, et les complexités des tâches ou la compétence de chaque équipe sur leurs tâches doivent être le plus homogène possible. Pour des maturités, des vélocités, et des tailles trop disparates, SoS rendra difficile le travail des équipes Scrum virtuelles pour le travail à l’échelle.
- Nombre d’équipes : 2 – 9
- Nombre de personnes : 10 – 40
Spotify
Cette méthodologie porte le même nom que la société qui l’a inventée. Spotify s’est donc construit une méthode sur mesure, capable de suivre son expension rapide et sa culture du travail collaboratif. S’il s’agit bien d’agilité, cette méthode reste surtout très adaptée à son inventrice et est peut être plus à considérer comme un exemple ou une excellente source d’inspiration pour construire la propre méthode agile qui épouse la culture de l’entreprise. Pourtant Spotify fait bien partie des méthodes proposées par de nombreux outils de gestion de projet à l’échelle, puisqu’il s’agit d’une méthode assez singulière qu’il est intéressant de considérer dans sa démarche de transformation agile.
La méthode Spotify nécessite une forte culture de la confiance et de l’autonomie dans la prise de décision et la montée en compétence. Avec Spotify, les équipes sont libres de travailler comme les le souhaitent, même avec les outils qu’elles souhaitent, mais elles doivent transparence au reste de l’organisation. La méthode autorise alors l’expérimentation, et donc l’echec, mais pour favoriser l’innovation.
Concrètement, Spotify organise les personnes en groupes croisés, et chaque type de groupe a son rôle :
Squad : Proches du concept d’équipe Scrum, les squads sont des équipes autonomes qui se concentrent sur une mission unique, un objectif clair. Une Squad a sa propre méthode agile de travail, possède un coach agile et un product owner. Chaque membre d’une Squad a son métier, son rôle, ses spécialités. Attention, dans le cas du passage de Scrum à Spotify, les équipes Scrum ne deviennent pas automatiquement les Squads!
Tribe : une tribu est constituée de squads qui travaillent autour d’une même thématique ou macro fonctionnalité et qui doivent de coordonner étroitement. Chaque tribu possède un référent qui s’assure de l’alignement des squads, et de l’animation du travail collaboratif de façon générale.
Chapter : un chapitre est constitué des homologues de chaque squad dans une tribu, ou les personnes ayant les mêmes compétences. Pas plus d’une personne par squad, et chaque membre d’une squad ne fait pas forcément partie d’un chapitre. Chaque chapitre a son référent et il sert à partager et développer les bonnes pratiques, faire progresser les squads.
Guild : les guildes sont utiles pour rassembler les personnes intéressées par un même sujet, ou possédant les mêmes compétences. La construction d’une guilde est libre à travers toutes les tribus et les échanges plutôt informels. L’idée est de partager autour d’un sujet ou d’une compétence et de faire progresser le groupe.
Squad et Tribus sont la structure, les chapitres et guildes vont favoriser l’innovation, le dialogue transverse, la transparence. Imbriqués ensemble, ces éléments permettent en théorie une agilité à l’échelle efficace jusqu’à un nombre important de personnes.
- Nombre d’équipes : 4 +
- Nombre de personnes : 50 +
Atteindre l’efficacité sur Scrum avant de passer à l’échelle
Le passage à une méthode agile à l’échelle de l’entreprise peut être un gros changement en soi et il nécessite d’abord une certaine maturité sur l’agilité au niveau des équipes et notamment sur Scrum qui est la base de beaucoup de méthodes d’agilité à l’échelle.
Atteindre la maturité sur Scrum signifie la maitrise de la méthodologie de façon pour apporter de la valeur plus efficacement qu’avec la méthode traditionnelle. Cela passe alors par la maitrise de l’outil lui même et par l’adoption des bonnes pratiques qui le concerne. Les solutions pour l’agilité à l’échelle peuvent s’alimenter de données projets (notamment les tâches au niveau des équipes) en se connectant à un existant (Azure DevOps, Jira, … ), et parfois ne proposent même pas la gestion de tâches pour ne pas apporter de redondance. L’outil de base pour la gestion des tâches et des sprints doit alors être pleinement compatible par son usage avec la solution qui viendra se brancher au dessus d’une ou plusieurs instances d’outils parfois même différents.
Jira Align par exemple nécessite un ou des instances Jira pour fonctionner. D’une façon similaire, Planview portfolios recommande l’usage de Agileplace et/ou Projectplace pour la partie basse de l’agilité. Chez Atlassian, le couple Jira / Jira Align étant obligatoire, l’éditeur propose un outil d’audit (Jet by Jira Align) pour vérifier que l’usage des instances Jira à synchroniser sont prêtes pour passer à l’échelle avec Jira Align. Il s’agit en effet de se préparer avant de sauter le pas!
Pour aller plus loin dans l’analyse de ses performances Scrum, des solutions comme Wiveez proposent d’ajouter à Jira des indicateurs, métriques, et tableaux de bord qui permettent de suivre son efficacité en agilité, estimer sa maturité pour passer à l’échelle, puis suivre sa bonne mise en route. Il s’agit de s’assurer que investissement mis dans un changement de démarche globale porte ses fruits. Les solutions de gestion de projet à l’échelle peuvent apporter une plus-value de taille si elles sont bien mises en places, basées sur des données projet issues des bonnes pratiques agile, et bien utilisées. Or tout cela est difficile à mesurer. C’est ce que propose Wiveez : un outil de pilotage de l’agilité. Le produit n’est aujourd’hui compatible qu’avec Jira.
