Pourquoi les développeurs ont-ils du mal à être agiles ?

À l’occasion de l’Agile Tour qui s’est tenu à Montpellier le 18 septembre 2023, nous avons assisté à la conférence de Constantin Guay, coach agile, auteur et présentateur sur la chaîne YouTube “Scrum Life”.
Lors de son intervention, il pose la question suivante : “Pourquoi les développeurs ont du mal à être agiles ?”, en partant du constat suivant :
“Rares sont les développeurs qui ont une façon de penser qui leur permet une vraie agilité. Dans les entreprises, cela se traduit par des conflits entre les “métiers” et la “tech”, chacun disant que l’autre “est trop nul(le) et que c’est sa faute si tout plante”. Et le plus fou, c’est que chaque camp a raison !”

Nous étions plusieurs collaborateurs de Kaliop à assister à cette conférence, provenant de différents métiers (Chef de projet, Directeur de projets, Product Owner, Scrum Master et Développeur). D’une certaine manière, elle a fait écho à des ressentis que nous avions tous, pour des raisons parfois différentes. J’ai trouvé intéressant de retranscrire cette conférence en abordant ces différents points de vue.

L’agilité, qu’est-ce que c’est ?

Rappelons que l’agilité, c’est avant tout une approche de conception et de création de produit numérique qui se base sur des valeurs telles que la collaboration, l’adaptabilité, la simplicité et la communication. Son but est d’améliorer la manière dont les équipes travaillent ensemble : le client, l’équipe de pilotage, l’équipe produit, l’équipe de développement, l’équipe design… Cela passe par le fait de favoriser la flexibilité, la qualité, et de fournir le meilleur produit possible tout en maximisant la valeur pour l’utilisateur final, et par conséquent, pour le client.

Cette approche est construite autour de 4 valeurs et 12 principes expliqués dans cet article. Maintenant que nous avons ces éléments en tête, il est plus facile de comprendre qu’un·e développeur·se n’est pas “non-agile” par nature. En effet, l’agilité n’est pas une qualité propre à une personne, c’est une approche que l’on adopte pour atteindre un résultat.

Il faut donc chercher ailleurs les raisons qui empêchent une équipe d’avoir une approche agile.

Une question d’organisation et de performance

Au fil de la conférence, nous découvrons qu’un certain nombre de problématiques présentes au sein d’un projet vont empêcher non seulement les développeur·se·s, mais aussi l’ensemble de l’équipe, de tendre vers une approche agile dans la création du produit.
Ces problématiques peuvent être regroupées en deux familles, l’organisation du travail d’équipe et le jugement de la performance.

L’organisation du travail d’équipe

En fonction de la manière dont le projet est lancé, cadré et orchestré, il peut y avoir des mésententes ou des difficultés d’alignement. Il y a plusieurs écueils qui peuvent saboter la bonne organisation du travail d’équipe :

• Confondre projet “non cadré” et projet agile, flexible.
• Considérer les développeur·se·s comme des personnes interchangeables.
• Ne pas partager aux développeur·se·s la vision globale du projet (cela peut être dû à des développeur·se·s qui ne le demandent pas et à des chef·fe·s de projets qui estiment que ce n’est pas nécessaire).
• Oublier l’objectif commun du projet. Quand les objectifs au sein d’une équipe divergent, on peut arriver à des situations dans lesquelles tout le monde s’accuse :
  • Les chef·fe·s de projet ou le/la client·e pensent que les développeur·se·s vont faire de la sur-qualité si on les laisse choisir comment développer, et que le produit ne sortira jamais.
  • Les développeur·se·s pensent qu’on ne leur laisse pas le temps, ni les moyens de faire des développements de qualité.

Cette situation va en général entraîner des conflits au sein de l’équipe et un fort risque de décrochage humain.

Le jugement de la performance

Là aussi, on peut identifier des pratiques à risque :

• Mesurer la performance des développeur·se·s en “nombre de lignes de code”.
• Ne pas accorder de temps à l’équipe pour faire de la veille technique et de l’innovation.
• Considérer que les développeur·se·s n’ont pas le droit à l’erreur.
• Gaspiller des ressources et développer des fonctionnalités inutiles (80% des fonctionnalités produites ne sont pas ou peu utilisées d’après une étude de Standish Group publiée en 2014).

Toutes les situations listées ci-dessus peuvent se retrouver au sein de nombreuses équipes et peut-être que vous les avez vous-même déjà rencontrées. Il s’agit bien souvent d’un problème de communication et d’alignement. Cependant, si ces situations se produisent au sein d’un projet qui se veut agile, cela va à l’encontre des valeurs même de l’agilité. Dans ce cas, ce ne sont pas les développeur·se·s qui ont du mal à être agiles, c’est l’ensemble du projet qui n’applique pas une approche agile.

La solution, dans ce cas, est simple…

Remettre l’agilité au cœur du développement

Si on veut avoir une approche agile lors du développement d’un produit, il est important de constituer une équipe et de mettre en place une organisation en conséquence.

Tout d’abord, l’équipe projet doit être constituée de personnes motivées, des développeur·se·s, mais aussi des représentant·e·s des utilisateurs du produit (PO, client), et enfin d’un·e chef·fe de projet. Tous doivent avoir une vision et un objectif commun : développer un produit de qualité, et à forte valeur ajoutée pour l’utilisateur final.

Avoir une équipe stable va évidemment avoir un impact sur l’engagement, la motivation, la vision et l’objectif commun. L’approche agile nécessite un cadre, que ce soit un cadre de travail ou une méthode (SCRUM ou KANBAN, par exemple), ainsi que des outils de pilotage comme l’Extrême Quotation ou le Release Plan.

Adopter l’agilité et mettre en place une organisation en conséquence va créer un environnement propice et avoir un effet positif sur l’ensemble de l’équipe.

Une approche agile implique d’intégrer le développeur tout au long du processus de création du produit. Il devra participer au choix des solutions techniques, pourra tester ces solutions, et parfois se tromper (processus empirique). Cela va aussi encourager sa créativité et lui permettre de proposer des solutions innovantes pour résoudre un problème.

Inciter le développeur à penser au sens du produit, au besoin client et au meilleur moyen d’y répondre lui permettra aussi de déterminer quelles sont les fonctionnalités qui représentent le plus de valeur. Il est crucial que le logiciel fonctionnel soit la principale mesure de progression d’un projet, et non le nombre de lignes de code écrites. L’implication des développeurs n’en sera que renforcée, ainsi que la qualité du travail fourni, et le gaspillage de ressources sera largement réduit.

“Il est important de considérer les développeurs pour ce qu’ils sont : pas de simples codeurs, mais des ingénieurs passionnés, créatifs, qui peuvent être forces de propositions sur la manière de développer une fonctionnalité et de répondre à un besoin de manière efficace et adaptée.”
Constantin Guay

Ce qu’on en pense à Kaliop

À Kaliop, nous avons décidé d’adopter une approche agile sur nos projets il y a plusieurs années. Ça n’a pas toujours été simple à mettre en place, car cette approche était initialement pensée pour le développement de produits en amélioration continue. Dans le cadre du développement de sites web et d’applications mobiles dans lesquels nous appliquions une approche davantage axée projet (plutôt que produit), avec une organisation en “cycle en V”, cela a nécessité de nombreuses adaptations. Nous pouvons même nous amuser à dire qu’il y a eu une approche agile dans la manière d’intégrer l’agilité à notre travail !

Aujourd’hui, nous appliquons SCRUM, son découpage des développements en sprints et ses différents rituels, pour intégrer une approche agile dans nos projets :

• L’affinage avec la participation de toute l’équipe, permet de bien définir le besoin du client et de s’assurer qu’il est clair pour toute l’équipe.
• Le sprint planning avec la définition en équipe de l’objectif du sprint et des moyens techniques pour l’atteindre.
• La démonstration permettant d’avoir des retours clients et/ou utilisateurs de manière récurrente.
• La rétrospective, une réflexion en équipe sur le déroulement du sprint une fois celui-ci achevé et sur les leviers pour s’améliorer davantage sur les suivants.

Dans ces conditions, nous constatons qu’être agile devient petit à petit un mode de pensée naturel que nous appliquons sur l’ensemble de nos projets, dans lesquels tous les membres de l’équipe sont pleinement intégrés au processus de création. Et dans certaines situations problématiques, prendre du recul permet de se rendre compte que l’approche agile va nous aider à les résoudre.