Pour être agile, ne déployez pas la méthode Agile
Où il est question d'agilité et de méthode Agile
Vous avez dit Agile ?
La méthode Agile est devenue totalement mainstream. Si vous n’en êtes pas convaincu, tapez “agile gartner” dans Google. Vous verrez que Gartner produit de nombreuses études sur le sujet Agile.
À commencer par le premier résultat, que l’on peut voir ci-dessous :
Cette étude, “Enterprise Agile Planning Tools Reviews 2021” est une étude portant sur les outils “qui aident les organisations à utiliser les pratiques agiles à l’échelle” (“Enterprise agile planning (EAP) tools help organizations to make use of agile practices at scale[...]”).
Il est question de planning, d’outils, de processus - et de mise à l’échelle. Ce n’est qu’un exemple, mais significatif : lorsqu’on évoque la méthode Agile, on parle d’abord d’outils et de processus.
Vous l’avez probablement vécu si vous travaillez à créer dans la tech. Une transformation Agile consiste à déployer un cadre de processus - Scrum souvent, ou SAFe - et à demander aux équipes d’adopter un ensemble de rituels, de pratiques et d’outils.
L’objectif n’est plus de créer des logiciels de valeur, mais d’être Agile. Mais est-ce bien le cas ?
Est-on vraiment agile lorsque l’on déploie une méthode Agile ?
Du manifeste à la méthode Agile
Le mouvement Agile trouve son origine dans le “Manifesto for Agile Software Development”, publié en 2001, texte court qui met en avant quatre principes permettant de créer de meilleurs logiciels.
Les signataires de ce texte, développeurs, sont créateurs de différentes pratiques de développement: Kent Beck a publié eXtreme Programming en 1999, Ken Schwaber et Jeff Sutherland développent Scrum, Alistair Cockburn a crée Crystal Clear, parmi d’autres exemples.
Le manifeste a pour but de mettre en avant les principes clés qu’ils partagent.
Depuis, la méthode Agile s’est diffusée largement, y compris hors du champ du développement logiciel, et est devenue un business à consultants florissant.
Les start-up en phase de croissance sont des cibles naturelles de la méthode Agile.
Sous la pression d’une croissance rapide de l’organisation, on tente de déployer la méthode Agile à l’échelle de l’entreprise. Cela devient un objectif en soi.
Dans un contexte difficile, la tentation est forte d’appliquer aveuglément des recettes toutes faites. Il est demandé aux équipes de souscrire à des rituels, des contraintes et des pratiques qui sont hors sol et déconnectés des réalités quotidiennes de l’équipe.
Les grandes organisations traditionnelles, menacées par les start-up, la transition numérique, leur bureaucratie interne, pensent que la méthode Agile va leur permettre de mieux innover.
C’est une recherche vaine d’une solution miracle à des problèmes complexes. Outre qu’il n’est bien souvent plus question de développement logiciel, c’est une mauvaise analyse de penser que l’agilité des start-up vient de leur organisation.
Comme l’explique Philippe Silberzahn, spécialiste du management des organisations en contexte de rupture :
“Ce que montre le dilemme de l’innovateur, c’est que l’avantage des start-up n’est tant pas leur agilité que le fait qu’elles n’ont pas d’activité historique à protéger”.
Pourtant, les grandes organisations sont la première source de revenus des vendeurs de méthode Agile, SAFe en tête, pour une agilité à l’échelle clé en main : tout est fait pour assurer la grande organisation contre le risque.
“Run, you fool!”
Ces dérives ont des conséquences délétères sur les équipes. Elles sont dénoncées depuis plusieurs années, en premier lieu par des signataires du manifeste.
Dans Agile is Dead (Long Live Agility), Dave Thomas, signataire du manifeste et auteur du classique “The pragmatic programmer”, est direct :
"The word “agile” has been subverted to the point where it is effectively meaningless, and what passes for an agile community seems to be largely an arena for consultants and vendors to hawk services and products."
Scrum, par la volonté de ses créateurs, est devenu un standard Agile de fait. Les témoignages sur les dégâts d’une application sans recul de ces préceptes sont nombreux. La charge de Michael O’Church est l’une des plus virulentes :
“Scrum is the worst, with its silliness around two-week “iterations”. It induces needless anxiety about microfluctuations in one’s own productivity. There’s absolutely no evidence that any of this snake oil actually makes things get done quicker or better in the long run. It just makes people nervous. There are many in business who think that this is a good thing because they’ll “work faster”.
Pourtant, les acteurs sur le terrain sont de bonne volonté et de bonne foi. L’agilité est demandée par les équipes, les directions y voient l’opportunité d’une amélioration du fonctionnement de l’organisation, les facilitateurs veulent vraiment aider.
Alors comment en arrive-t-on à cette situation ?
C’est le paradoxe (apparent) de l’agilité.
Vouloir imposer une méthode Agile vous éloigne de l’agilité, parce que vous entrez directement en contradiction avec le premier principe du manifeste.
“Individuals and interactions over processes and tools”
L’agilité packagée - de Scrum à SAFe, mais pas seulement - permet de rassurer des décideurs averses au risque, et des opérationnels mal à l’aise avec l’incertitude.
Avec ses rituels et ses pratiques, un framework Agile est une solution miracle à des problèmes complexes.
Mais cela n’a plus grand-chose à voir avec le manifeste, et - surtout - avec les besoins des organisations et des équipes.
Accepter la complexité
Les managers doivent sortir du faux confort d’une méthode toute prête et affronter l’incertitude du terrain.
Être agile peut être un bon moyen d’atteindre vos objectifs - mais cela n’est pas garanti.
Pour cela, foin de méthode toute faite, de framework et de rituels.
Pour une organisation “tech”, c’est-à-dire pour qui le logiciel est au centre de la création de valeur, vouloir que l’organisation soit Agile n’est pas un objectif.
Ce que vous souhaitez, c’est créer plus de valeur : augmenter le chiffre d’affaires, le bien-être des salariés, la satisfaction des utilisateurs, la marge, ou n’importe quel objectif qui fait sens dans votre contexte.
Bien identifier ces objectifs, les décliner dans une vision et des missions pour chaque équipe est un bon point de départ.
Charge ensuite à chaque équipe de s’organiser, comme le rappelle Ron Jeffries dans Developers Should Abandon Agile :
"The Manifesto calls for “self-organizing” teams, and in the best case, that comes down to the team choosing its own process. If I were starting a company, I’d let the teams choose any process they wish. I’d ask for results, not a specific process"
Il faut partir du terrain : des gens, du contexte, et utiliser la boîte à outils des méthodes pour construire la meilleure solution, comme l'explique Dave Thomas :
"What to do: Find out where you are Take a small step towards your goal Adjust your understanding based on what you learned Repeat How to do it: When faced with two or more alternatives that deliver roughly the same value, take the path that makes future change easier."
Mettre en place des équipes autonomes, donner le contexte stratégique et la vision, et permettre à l’équipe de construire ses solutions pour atteindre les objectifs de l'organisation est un pas vers une organisation agile.
Au fondement ... ou pas
Utiliser aveuglèment une méthode Agile est en contradiction fondamentale avec le manifeste.
Si cela fonctionnait, ce ne serait pas bien grave - on se fiche de la fidélité au dogme originel. Mais appliquer des méthodes Agile prêtes à l’emploi fait beaucoup de dégâts, et bien souvent cela crée plus de problèmes que cela n’en résout.
Commencez par identifier les objectifs véritables de votre organisation.
Il est indispensable de mettre les mains dans la complexité et travailler au plus près du terrain, donner des objectifs, une vision et des moyens à des équipes autonomes, capables de s’organiser pour délivrer des résultats.
Si vous êtes une organisation dont le logiciel est au cœur de la proposition de valeur, l’agilité, c'est à dire la capacité à s'adapter à un environnement d'incertitude - commence par l’excellence technique.
C’est souvent la grande oubliée des projets de transformation - et c’est pourtant le fondement à bâtir en premier.
Je remercie Marie-Laure Kléville, Frédéric Bourguignon et Valentin Decker pour leurs relectures et avis sur cet article. Que ce soit le premier d’une longue série.
Des liens cool
Voici quelques ressources en lien avec le sujet: