"Et si on passait à l’Agilité à l’échelle".
C’est une phrase que l’on entend de plus en plus fréquemment au sein des entreprises qui gagnent en maturité Agile. Mais à quoi cette phrase correspond-elle exactement ? Qu’implique l’idée de “passer à l’échelle” ? Existe-t-il des solutions applicables rapidement ?
L’expression “Agile à l’Échelle” est souvent accompagnée de noms de solutions comme “SAFe”, “DaD”, “LeSS”, “Nexus”,... Il s’agit des noms de frameworks ou référentiels de pratiques dédiés à l’implémentation de l’Agile à l’échelle de plusieurs équipes de delivery; ces “frameworks” sont des ensembles cohérents de pratiques/rituels/rôles/artefacts censés permettre à une organisation de fonctionner selon les principes Agiles.
En fonction du degré de maturité de ces entreprises, les principes Agiles se déclinent de la petite équipe isolée qui fonctionne en “full agile”, à des organisations composées d’équipes pluridisciplinaires qui délivrent du logiciel de qualité, fréquemment, en phase avec des objectifs stratégiques et opérationnels de l’entreprise.
Dans la majorité des cas, l’annonce produit un électrochoc dans les équipes : l’Agile a bonne presse. La direction, et tout le monde à sa suite, s’en empare et utilise le terme à toutes les sauces : “ok, on va modifier le cahier des charges, on est agile”, “On coupe les tests pour aller plus vite, parce qu’on est Agile”, “Désolé, je suis à la bourre à la réunion, mais ça va, on est agile”...
Mais l’enchantement ne dure pas ; l’instauration de nouveaux rites opérationnels s’effectuent au pas de charge, souvent sans remise en question profonde des éléments structurels de l’entreprise. On renomme des fonctions avec des noms “agile”, on modifie des fiches de poste à la marge, on ajoute un scrummaster par ci, un Product owner par là, les liens hiérarchiques ne changent surtout pas, l’ensemble des collaborateurs passent à la moulinette de formations agiles raccourcies et édulcorées.
C’est alors que l’entreprise fait de l’agile mais n’est pas Agile.
Ces méthodes standards, packagées et brandées, regroupent des outils de la collaboration et de l’organisation du travail en équipes. Utilisés en bloc, sans en comprendre les fondements, les frameworks ne permettent pas la transformation profonde des modes de travail des entreprises.
C’est dans un de ces articles que Dan North utilise le premier l’acronyme SWARMing : Scaling Without A Religious Methodology.
Ron Jeffries prônait même de façon provocatrice que les “développeurs devraient abandonner l’agile”. Il s’agit en fait d’abandonner les processus décrits par ces frameworks “Agiles” qui se révèlent être de véritables carcans qui freinent l’apprentissage et l’amélioration d’une équipe dans son contexte.
La meilleure façon d’instaurer, au sein d’une équipe, un mode de fonctionnement qui se rapproche des principes de l’Agile est de donner le pouvoir (temps, disponibilité, légitimité) à l’équipe (ou à l’organisation) pour améliorer son fonctionnement régulièrement sur la base des 4 valeurs du Manifeste Agile. Ce n’est donc pas d’"installer" tel ou tel framework ou méthode Agile, ni de le respecter à la lettre. C’est avant tout de savoir régulièrement écouter et comprendre les freins rencontrés par l’équipe et, tester collectivement des solutions permettant à l’équipe de lever ces freins.
Ceci étant dit, tout n’est pas à jeter dans les frameworks d’agilité à l’échelle.
Cette citation d’Abraham Maslow nous rappelle que notre vision des problèmes est distordue par les solutions que nous avons l’habitude d’utiliser.
Les frameworks agile sont des boîtes à outils ; il faut savoir piocher dedans à la recherche de l’outil qui vous aidera le mieux à résoudre le problème que vous rencontrez.
Prenons un peu de hauteur.
Au lieu de se pencher immédiatement sur les activités opérationnelles, attachons nous à lister les grandes thématiques pour lesquelles l’agilité apporte une vision différente :
La diffusion des éléments de sens autour d’un produit logiciel permet une certaine autonomie des équipes et une capacité de prise d’initiatives des équipiers.
L’entreprise s’attache à choisir là où doivent être positionnés ses efforts. La priorisation est un concept incontournable de l’agile et celui-ci se retrouve à tous les niveaux de la stratégie aux opérations.
Une façon de gagner en réactivité est de rapprocher le lieu de la conception, de la décision et de la réalisation.
L’autonomie donnée aux équipes doit être compensée par un effort supplémentaire de synchronisation inter-équipe pour conserver un haut niveau d’efficience et de cohérence dans la réalisation d’une application.
Dans un contexte de travail agile, la responsabilité de l’ordonnancement du travail, autrefois “centralisée” au niveau du PMO, revient maintenant au collectif des équipes. Quels mécanismes mettre en place pour réaliser des fonctionnalités qui nécessitent un séquencement des interventions ?
Un principe sous-jacent à l’agile est l’amélioration continue du processus et des outils de travail de l’équipe. Que signifie l’amélioration continue à l’échelle de l’entreprise ?
Comment délivrer plus fréquemment des fonctionnalités aux utilisateurs, et ainsi obtenir des feedbacks ?
L’agile amène l’équipe à s’engager sur un encours de travail qui lui permet de tenir un rythme soutenable. la logique budgétaire s’en trouve donc inversée. Comment cela s’implémente-t-il au niveau d’un projet multi-équipe ?
Ces problématiques peuvent être résolues par une ou plusieurs activités, que vous trouverez décrites dans des frameworks agiles, ou que vous inventerez pour l’adapter au mieux au contexte de votre entreprise.
Mais au-delà d’appliquer des pratiques d’agilité à l’échelle, votre intérêt doit se porter sur la résolution d’une douleur réelle pour l’entreprise, et sur la capacité de votre organisation à s’observer et à adapter son fonctionnement pour tendre vers un fonctionnement optimal.