Prendre de la hauteur sur l’utilisation des frameworks d’agilité à l’échelle

"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.

Quel est le déclencheur d’une transformation Agile “à l’échelle” ?

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.

Éclairés par la popularité de quelques frameworks, les patrons des entreprises les moins matures s’empressent de déclarer l’Agile dans leurs équipes, dépêchent une armée de “coachs Agiles” et veillent au déploiement à la lettre des préceptes d’une doctrine méthodologique au sein des équipes. En 6 mois, il faut que ce soit plié !

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.

SWARMing, kesako?

La situation décrite au-dessus s’accompagne souvent de l’utilisation désincarnée de méthodes agiles. Ces “frameworks” invitent/obligent les collaborateurs à organiser leur journée autrement, sans remettre en question les fondamentaux de la collaboration.

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.

“My argument isn’t that packaged scaling methods are unhelpful per se, rather that they are neither necessary nor sufficient for successful transformation.” Dan North résume ainsi une pensée partagée au sein d’OCTO ; les frameworks d’Agile à l’échelle ne peuvent être que des boîtes à outils, et en aucun cas des doctrines ou des recettes magiques à suivre à la lettre pour pouvoir se revendiquer “entreprise agile”. Ces frameworks se mettent au service d’une volonté de l’entreprise d’adopter les principes Agiles dans sa façon de fonctionner, et non le contraire. L’habit ne fait pas le moine. A la pratique, il est indispensable d’y associer les principes / l’idéologie sous-jacente.

Abandonner l’agile ?

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.

Revenir à la base : donner le pouvoir à l’équipe de s’améliorer

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.

Savoir s’inspirer sans s’enfermer

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.

Prendre le meilleur de chaque framework d’agilité à l’échelle, en fonction de son contexte et de son objectif

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 :

• Partager de la Vision et de la Stratégie

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.

• Prioriser et gérer les projets à l’échelle de l’entreprise

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.

• Composer des équipes pluridisciplinaires autonomes

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.

• Faire converger les efforts des équipes au quotidien

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.

• Résoudre les dépendances

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 ?

• S’améliorer en continu

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 ?

• Réduire le temps de cycle

Comment délivrer plus fréquemment des fonctionnalités aux utilisateurs, et ainsi obtenir des feedbacks ?

• Prévoir et suivre un exercice budgétaire

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.