Rendons l'agilité aux devs - Partie 1 - Que pensent les devs de l'agilité ?

Introduction

Aux origines du mouvement agile

Nous sommes en février 2001, 17 développeurs se réunissent dans un chalet à Snowbird dans les montagnes de l’Utah. Ils échangent sur leurs expériences de développement logiciel, leurs frustrations et leurs aspirations. Ce rassemblement a mené à la création du terme “agile” qui regroupe principes, idéaux et raisonnements que ces devs avaient en commun, et qu’ils ont formalisés dans un texte intitulé “manifeste pour le développement agile de logiciels” ¹.

Mon expérience de l’agilité

Avant d’être développeuse, j’ai été durant quelques années linguiste au sein d’une équipe multilingue composée d’une quinzaine de linguistes de différentes nationalités. Notre travail consistait à créer et maintenir des données linguistiques pour différents modèles et produits liés à la parole. Alors même que nous ne parlions pas d’agilité, j’ai réalisé par la suite que nous travaillions déjà de manière agile. Nous avions une approche en flux (Kanban) qui nous permettait de pouvoir estimer la charge de travail et de prioriser les tâches en fonction des besoins de l’équipe et des projets en cours. Pour cela, nous avions des réunions hebdomadaires durant lesquels nous nous synchronisions les uns avec les autres. Ainsi, toute l’équipe avait une vision claire, globale et partagée de l’avancement de notre travail et des différents produits sur lesquels nous travaillions. Nous travaillions également en étroite collaboration (peer reviews, par exemple) qui nous permettaient de nous entraider et de nous améliorer mutuellement.

En passant de linguiste à développeuse, on m’avait dit que je retrouverais ces mêmes pratiques, tout du moins dans l’essence.

Mais je ne les ai jamais retrouvées. J’ai surtout vu des équipes dans lesquelles les devs entraient en compétition les uns envers les autres où il ne fallait surtout pas que l’ensemble de l’équipe puisse avoir la vision sur l’avancement du produit ou du projet. J’y ai également vu des jeux politiques de la part de Product Owners (PO) ou de Scrum Masters (SM) qui privilégiaient leur propre intérêt au détriment de l’équipe. J’ai aussi été considérée comme une exécutante à qui cela semblait normal de demander de travailler dans l’urgence, de changer les priorités toutes les semaines, de se plaindre lorsque les délais n’étaient pas respectés ou que les attendus n’étaient pas atteints.

J’en passe et des meilleures…

Depuis, j’ai une vision très critique de l’agilité. Lorsqu’une équipe se dit “agile”, je la vois d’un mauvais œil.

Sur les communautés de développeur, je constate également qu’un certain nombre de devs semble partager ce sentiment. Ce qui m’a mené à me poser la question suivante : que pensent les devs de l’agilité ?

Que pensent les devs de l’agilité ?

Pour répondre à cette question, j’ai réalisé une enquête qui a été diffusée sur LinkedIn, Discord et Twitter.

Au total, 31 personnes ont répondu à l’enquête : 30 hommes et 1 femme. Les 21 répondant(e)s ont un Bac +5 ou plus et 19 ont plus de 10 ans d’expérience dans le développement logiciel. Les répondant(e)s viennent majoritairement d’Auvergne-Rhône-Alpes, d’Île-de-France et d’Occitanie.

La Figure 1 présente les environnements dans lesquels les répondant(e)s ont évolué. Presque la totalité des répondant(e)s (29/31) a connu Scrum, un peu plus de la moitié (16/31) a connu Kanban moins d’un tiers a connu d’autres cadres de travail.

Un sentiment de défiance

Seuls 23% des répondant(e)s sont tout à fait d’accord ou d’accord avec l’affirmation “L’agilité, dans sa forme actuelle, répond toujours aux besoins des équipes de développement” ainsi que le montre la Figure 2. Il y en a également 45% qui indiquent avoir l’impression de subir l’agilité et 16% disent même vouloir éviter les environnements agiles.

Les répondant(e)s ont également eu l’occasion d’avoir une parole plus libre s’ils ou elles le souhaitaient. Dans ce qui transparaît de leurs réponses, nous pouvons observer un réel sentiment de défiance envers l’agilité.

J’éradiquerais la totalité de l’agilité telle qu’elle est présente actuellement.

Le souci, c’est jamais l’agile, c’est les clowns qui veulent coller une façade agile sur des méthodes et pensent que ça suffit.

L’application de l’agilité sert de prétexte à déresponsabiliser la plupart des intervenants et à casser le lien indispensable entre le client et le-la développeur-se.

Le terme [agilité] a été galvaudé.

Le commentaire suivant résume bien ce sentiment de défiance :

Selon moi l’agilité est un cancer qui se propage et qui détruit l’environnement de développement. Et cela uniquement pour le plaisir des “décideurs” afin qu’ils se sentent plus au contrôle des développements. Réunions inutiles et interminables, figement des développements, indécisions. Le summum de l’inutilité de l’agilité sont les postes créés uniquement pour l’agilité et qui n’ont aucun intérêt : scum (sic) master, coach agile, …

Des problèmes managériaux

En plus de ce sentiment de défiance, les répondant(e)s soulignent également des problèmes managériaux.

Scrum tourne rapidement au micro-management avec certains PM/Scrum masters.

Un management toxique transforme malheureusement l’agilité en une coquille vide, où les pratiques sont suivies mécaniquement, sans l’esprit collaboratif et innovant qui en fait la véritable force…

À l’instant où une contrainte artificielle est imposée, telles que la durée de sprint, kpi pour un métier intellectuel (…), présence physique imposée, etc. La productivité va drastiquement chuter, ou les devs vont exploser en vol, ou les deux.

Pour comprendre cette défiance de l’agilité, nous devons déterminer si le problème provient de l’agilité en elle-même ou de la manière dont elle est appliquée.

Sur la piste des anti-patterns Scrum

J’ai présenté aux répondant(e)s une liste de 36 anti-patterns Scrum (liste non exhaustive) et leur ai demandé s’ils ou elles les avaient déjà rencontrés.

La Figure 3 présente le nombre d’anti-patterns rencontrés par les devs. Les résultats suggèrent que toutes et tous ont rencontré au moins 4 anti-patterns Scrum et plus de la moitié des répondant(e)s (52%) en ont rencontré au moins 16.

Six anti-patterns, spécifiques aux équipes de développement, ont été présentés aux répondant(e)s :

1. Les devs sacrifient la qualité au profit de la quantité.
2. Les devs sont des exécutants.
3. Les devs recueillent le besoin utilisateur.
4. Il n’y a pas de transmission des connaissances et compétences entre les devs.
5. Les devs travaillent en silos.
6. Il existe une hiérarchie entre les devs.

La Figure 4 nous permet de constater que moins de 10% des répondant(e)s n’en ont jamais rencontré. En revanche, plus des deux tiers des répondant(e)s en ont rencontré au moins 3.

Si nous nous intéressons aux liens entre les anti-patterns Scrum et les résultats des affirmations précédentes, deux corrélations significatives sont mises en évidence, ainsi qu’illustré dans les Figures 5 et 6. En effet, an appliquant un test de corrélation de Pearson², nous obtenons un coefficient de corrélation r = 0.37 (p = 0.04) — soit une corrélation moyenne — entre le nombre d’anti-patterns Scrum rencontrés et l’impression de subir l’agilité.

De même, il existe une corrélation négative moyenne entre le nombre d’anti-patterns Scrum rencontrés et la pensée que l’agilité est toujours adaptée aux équipes de développement (coefficient de corrélation r = -0.42 (p = 0.02)). Ainsi, plus les répondant(e)s ont rencontré d’anti-patterns Scrum, plus ils ou elles ont l’impression de subir l’agilité et moins ils ou elles pensent que l’agilité est toujours adaptée aux équipes de développement.

Ce qu’il faut retenir de cette enquête

De manière générale, les répondant(e)s ont un sentiment de décalage et de défiance envers l’agilité. Seuls 23% des répondants estiment que l’agilité répond à leurs besoins, tandis que plus de la moitié ont l’impression de la subir, et 16% cherchent même à éviter les environnements agiles.

Zombie Scrum is the New Black

Ce malaise est renforcé par la fréquence élevée des anti-patterns Scrum rencontrés. Tout d’abord, aucun des devs interrogés n’a connu de Scrum qui fonctionne parfaitement. En effet, 100% des répondant(e)s ont rencontré au moins 4 anti-pattern Scrum et plus de la moitié en ont rencontré 16 et même une personne en a rencontré 33 sur les 36 anti-patterns présentés.

Un outil pour les devs ?

Nous l’avons vu, l’agilité a été conçue par des développeurs pour des développeurs. Cependant, dans sa mise en œuvre actuelle, elle est souvent perçue comme un ensemble de contraintes managériales ou de pratiques déconnectées des contextes et problématiques des équipes de développement. Sa mise en œuvre défaillante corrèle avec l’impression de subir l’agilité et la pensée que l’agilité n’est plus adaptée aux équipes de développement.

Cela a pour effet de créer un sentiment de défiance envers l’agilité, vécue comme un ensemble de contraintes managériales ou de pratiques déconnectées de leurs contextes et problématiques, alors qu’elle a été conçue pour être un outil à leur service.

Un retour aux sources

Plusieurs répondant(e)s ont exprimé le souhait de revenir à des pratiques agiles non pas liées à l’organisation d’équipe, mais au développement logiciel, telles que l’eXtreme Programming (XP) ou encore le Software Craftsmanship.

Bibliographie