Retour d'expérience : comment Trustt a hacké sa productivité grâce à la méthode agile

Scrum, sprints, backlog… Ces termes encore inconnus il y a vingt ans sont aujourd'hui sur toutes les lèvres dans le milieu du développement logiciel. Retour d'expérience sur cette méthode agile.

Depuis que des experts américains ont mis le doigt sur l’énorme quantité de déperdition (perte de temps, projets abandonnés ou en stock…) qu’entraînaient les méthodologies de production traditionnelles, l’agilité n’a cessé de gagner du terrain et séduit aujourd’hui les entreprises de tous secteurs. Certaines start-up, comme Trustt, n’hésitent pas à étendre cette méthodologie à l’ensemble de leurs pôles dont voici le retour d’expérience.

Quelles sont toutefois les limites de cette organisation ? Comment éviter de “produire pour produire” et se retrouver avec un stock de livrables sur les bras ? Comment faire de cette méthode une force pour le développement de son business ?

Une méthodologie qui s’ancre dans son époque

1. Historique de la méthode agile

En 2001, aux Etats-Unis, dix-sept experts du développement logiciel écrivaient le Manifeste pour le développement agile de logiciels. L’objectif ? Trouver un “dénominateur commun” à leurs organisations de travail et à leur productivité optimisée. Tous s’élèvent contre un statu quo : l’organisation en “cascade”, traditionnellement utilisée par la majorité des entreprises, entraîne un décalage entre les attentes du client et les fonctionnalités développées. 

La méthodologie en cascade repose sur un traitement séquentiel des tâches où la validation par le client n’intervient qu’après l’ensemble des étapes de conception. Chaque phase dépend des précédentes, ce qui signifie que si le client souhaite apporter des modifications au livrable, toutes les étapes en aval de la modification seront impactées et nécessiteront elles-mêmes des ajustements. Les conséquences de cette méthodologie sont un nombre conséquent d’allers-retours et d’itérations, qui entraînent une perte de temps, d’énergie, ainsi que de la surproduction (les livrables refusés par les clients sont mis de côté, souvent jamais utilisés et constituent un stock dormant). 

Le concept de méthodologie dite “agile” a été introduit et développé par les entreprises tech et les outils SaaS (à améliorations constantes) car il faut développer des fonctionnalités régulièrement pour rester performant. C'est aujourd’hui une méthode phare utilisée dans les équipes tech des entreprises de tous secteurs depuis une vingtaine d’années.

2. Fondements et intérêt de la méthodologie  

La méthodologie agile sert à développer la productivité des équipes et repose sur la co-création avec les clients. L’enjeu est donc de sortir une V1 d’une fonctionnalité rapidement, en collectant des feedbacks clients à chaque étape du développement de la feature pour être en phase avec leurs attentes.

L’agile regroupe en réalité différentes méthodologies. Parmi elles, la méthode Scrum, par exemple, découpe le projet en sprints (périodes de deux semaines) et donne une vue d’ensemble du projet à l’ensemble de ses acteurs. Un chef de l‘avancement du projet est désigné : c’est le scrum master. Il assure la coordination et la communication entre les parties prenantes. La répartition des tâches pour chaque sprint est visible dans un fichier appelé backlog, qui détaille chaque étape à réaliser pour la conception de la fonctionnalité. Ces étapes sont classées dans l’ordre de leur priorité, et attribuées à un membre de la delivery team avec une deadline à respecter. Cette priorisation et répartition des tâches est organisée dans une réunion appelée le sprint planning meeting, tenue par le scrum master. Des réunions quotidiennes, les stand up meetings, assurent également la motivation des équipes et permettent de lever les zones d’ombres qui pourraient planer sur certaines tâches.

La méthodologie agile prend d’autant plus de sens à l’avènement du télétravail et du flex office, où les équipes et les clients sont à distance et moins joignables. Cette organisation aide à gagner en productivité avec son équipe et permet de faire valider les livrables par le client à chaque fin de sprint, ce qui limite les itérations, les incompréhensions et les pertes (à la manière du lean management).

Application : passage à l’agile dans la start-up Trustt 

Trustt est une start-up qui propose un logiciel SaaS d’engagement communautaire aux marques de biens de consommation / services de tous secteurs. Cédric Driaux, développeur back-end chez Trustt et ancien indépendant, revient sur son parcours et sur la transition de Trustt dans ses méthodes organisationnelles.

“Dans mon ancienne expérience, des managers arrivaient avec de nouvelles idées toutes les deux heures et me demandaient de les traiter dans la journée. Ça bouleversait tout le temps mon planning, et le sentiment d’être dépassé par la charge de travail arrivait très vite. La méthode agile donne une ligne directrice pour la journée. Cela décharge mentalement de savoir que la todo list ne va pas changer du tout au tout au bout de deux heures !” explique Cédric. 

“Bien sûr, c’est un investissement en termes de temps : il faut passer du temps à faire les différentes réunions (sprint planning, stand up…), mais c’est un temps considérable qui est gagné au final, grâce à la productivité augmentée de chaque membre de l’équipe.”

Le pôle tech a été la première équipe de Trustt à adopter la méthode agile. Cédric revient sur les premières difficultés rencontrées : “Je suis arrivé chez Trustt au tout début de la mise en place des sprints. Notre scrum master, Richard, dit souvent qu’on a besoin de 5 ou 6 sprints avant d’être bien au point sur cette méthodologie. La difficulté ? S’analyser sur les sprints : être capable de s’auto-critiquer, de voir ce qui a posé problème, seul ou pour toute l’équipe. Aussi, être capable de dire quand c’est bien ! C’est très important pour le moral, la motivation et pour avancer dans de bonnes conditions.”

Bien sûr, une fois que la méthodologie est maîtrisée, les bénéfices sont multiples : 

“J’ai fait plusieurs fois l’erreur de passer 6 mois à un an sur un projet, pour me rendre compte qu'à la fin, j’étais “à côté de la plaque”, continue le développeur. “Dans un secteur comme le marketing, tout évolue très vite. On ne peut pas se permettre d’attendre 6 mois pour développer quelque chose : ça serait obsolète.” 

“L’idée du sprint, c’est de sortir une V1 rapidement qui répond à un besoin ou à un minimum de besoins client. À partir des retours du client, on fait une V2. D’une part, on va plus vite, et d’autre part, le client a vraiment l’impression que le logiciel a été développé pour lui, et pas par le développeur tout seul de son côté !”

Déploiement de la méthodologie agile dans les autres pôles de Trustt

Cette méthode s’adapte donc parfaitement au développement de fonctionnalités pour les développeurs d’un produit SaaS : mais qu’en est-il des autres pôles de l’entreprise ? 

Chez Trustt, la méthode agile a été diffusée à l’ensemble des équipes. 

Dans le pôle marketing, par exemple, il faut comprendre comment fonctionne cette méthode et “l’apprivoiser”. On ne produit pas un contenu rédactionnel comme on sort une fonctionnalité : les délais sont très courts, il faut donc être capable de trouver l’inspiration rapidement. Pour éviter que les sprints n’entraînent des “syndromes de la page blanche” et la perte de motivation des rédacteurs, l’équipe content marketing inclut dans son backlog des temps dédiés à aller interviewer les autres membres de l’équipe, à condenser leurs conseils ou à faire des benchmarks.

Évoluer dans une petite structure comme une start-up donne l’avantage à tous les collaborateurs de pouvoir être autonomes et forces de propositions. Cela s’oppose au fonctionnement des grandes entreprises où tout est plus “protocolaire”. Cependant, cette liberté accordée à l’équipe content implique de devoir se remettre constamment en question, d'accepter le fait de devoir recommencer son travail - parfois à zéro - quand une proposition n’est pas retenue. La content manager et scrum master de l’équipe éditoriale doit donc être vigilante quant au moral de son équipe et pallier aux baisses de motivation et de confiance.

Les limites de l’exercice 

1. Features pour features ?

Un des risques de la méthodologie agile est la surproduction de nouvelles fonctionnalités. Les équipes vont vite, les clients sont satisfaits, alors, pourquoi ne pas continuer sur cette lancée et produire plus ?

Le danger est la création de nouvelles fonctionnalités qui ne seront pas ou peu utilisées par les utilisateurs, ou de créer des fonctionnalités qui n’atteignent pas leurs aboutissements. Dans ce cas, il vaut mieux se concentrer sur l’amélioration de features existantes !

2. Gare au stock ! 

Comme dans le retail, le stock représente de la perte… (livrables, fonctionnalités…). On y pense pas forcément car il est moins visible qu'un stock physique, or c'est une réalité. En effet, s’il y a une surproduction - de fonctionnalités ou de contenus marketing - ces productions sont stockées et deviennent obsolètes avant même d’être sorties. C’est une perte de temps et d’effort pour les équipes. L’optimisation de fonctionnalités et de contenus permet alors d’apporter de la valeur aux productions existantes, sans surproduire.

3. Obtenir de vrais feedbacks de la part du client 

La méthodologie agile implique un développement par itérations où les retours du client interviennent à chaque étape du développement. Il est capital d’obtenir de vrais feedbacks qui valident ou invalident ce qui a été fait pour pouvoir passer à l’étape suivante. Ces allers-retours peuvent être difficiles à mettre en place (lorsque le client est occupé et peu joignable) et rallonger le temps de production de la feature.