L’Agilité, le tuteur légal des développeurs

Les méthodes agiles sont des ensembles de bonnes pratiques qui aident au développement de tout type de projet informatique. Celles-ci sont largement appliquées dans le monde du Web & Mobile en France. Ces mises en application sont éprouvées. Elles fonctionnent à différentes échelles. Du coup, pourquoi cet article ?

Papa impose des règles, mais grand frère ne les respecte pas..

L’agilité, comme elle est perçu par les développeurs, reste une approche théorique à la question: Comment améliorer la capacité de production afin de gérer des projets dont les evolutions (ajout/modification/maintenance de fonctionnalités) doivent intervenir de plus en plus vite?

Basons-nous sur la méthode agile SCRUM (qui est, de loin, la plus répandue) afin de voir comment les méthodes agiles répondent à cette question.

Comme tout problème de production, la solution la plus simple est d’instaurer un cadre organisationnel. C’est à dire, d’instaurer un certain nombre de processes et de responsabiliser les différents protagonistes du projet en les nommant garants de l’application d’un ou plusieurs de ces processes.

Ca tombe bien ! c’est exactement ce que fait SCRUM. En effet, elle instaure un certain nombre de processes basés sur des cycles de X semaine(s):

• backlog
• sprint planning
• daily scrum
• sprint retro
• sprint review

Ainsi que les garants des processes:

• Scrum master
• Product owner
• développeurs & graphistes

Ok ! Sur le papier, ça à l’air super ! Mais dans les faits, il y a un point qui vient bouleverser ce cadre.

Ce point, c’est la pression. La pression peut, entre autre, venir de la concurrence, de la hiérarchie ou des investisseurs.

En général, cette pression se matérialise par le fait que le PO veuille à tout prix rajouter des tickets en milieu de sprint ou que le sprint soit défini de manière très ambitieuse.

Ceci est vécu comme une TRAHISON (what a word !) par le reste de l’équipe.

Papa est peut-être “has been” ?

Cette “trahison” à pour effet de casser le cadre de confiance entre les différents protagonistes. À ce moment là, le cadre organisationnel (matérialisé par la méthode SCRUM) n’a plus aucun interêt car elle est basé sur la responsabilisation de chacun sous couvert que tout le monde se fasse confiance. on en arrive donc à des situations, parfois puériles et à la limite du ridicule:

• les sprint planning se transforment en joute oratoire.
• les sprint retro se transforment en procès.
• les sprint review en thérapie de groupe.
• aucun risque n’est pris de la part des développeurs.
• un changement simple peut prendre plusieurs sprints à être résolu.
• cela créer une hiérarchie et brise le concept de flat organization.

Du coup, le cadre organisationnel, qui est censé proposer un certain nombre de règles & d’outils afin:

• de responsabiliser l’équipe autour d’un but commun.
• de créer un cadre de confiance.
• d’améliorer la vitesse/qualité de production.

devient un cadre oppressant & conflictuel dans lequel la confiance et la cohésion de groupe est inexistante. Pire encore, des clans se créent au sein de l’équipe.

Ces situations que j’ai personnellement pas mal rencontré légitime le fait de se demander si la méthode SCRUM est encore efficace dans le monde du web & mobile.

En effet, de nos jours, le niveau d’exigence des clients & des utilisateurs est de plus en plus élevé. Ils ont tellement de choix avec la concurrence, que leurs degré de patience ainsi que le temps qu’ils vous accordent est de moins en moins élevé. De ce fait, votre produit ce doit d’être le plus stable & le meilleur possible tout en proposant un ensemble d’amelioration de plus en plus vite.

Ceci étant dit, le cadre organisationnel qu’offre SCRUM n’est pas assez flexible pour répondre aux problématiques actuelles.

Tu n’aimes pas ton papa ? c’est pas grave, tu peux changer..

Malgré tout, SCRUM a le mérite de faire réfléchir sur des points importants à ne surtout pas négliger:

• reflexion et prioritisation de la RoadMap projet
• communication quotidienne
• partage de connaissance
• entraide & création de binômes temporaires si nécessaire
• vision à moyen terme
• écriture d’une documentation claire
• mesure et amélioration de la capacité de production
• réflexion sur le travail accompli sur une période donnée
• réflexion sur les axes d’amélioration généraux
• etc..

Ces points peuvent tout à fait être appliqué hors du cadre de SCRUM. J’irai même plus loin. Je pense que chaque équipe devrait créer le cadre qui lui correspond tout en intégrant les points cités ci-dessus. Le tout en fonction:

• de la capacité d’équipe (nombre, expériences, talents)
• de l’ambition (leader, acteur secondaire)
• de la qualité de produit attendu (MVP, post-Product/market fit, SOA, etc..)

Ah tiens ! un papa tout neuf..

Rien de mieux qu’un bon exemple testé en situation réel pour appuyer mes propos. Il y a peu, j’ai effectué une mission dans le domaine du food delivery. Pour vous donner un peu de contexte:

• une équipe de 4 développeurs (2 backends, 1 frontend web, 1 frontend mobile), 1 UX designer, et un product owner (CEO)
• app web & app mobile hybrid
• ambition d’être numéro 1 français
• le produit se doit d’être stable car milieu concurrentiel

Du coup le cadre que j’ai proposé:

• gestion de cycle par feature (aucune durée défini pour un cycle)
• le PO propose la feature du moment aux développeurs & UX designer
• Les développeurs backend proposent un mock de l’API attendu afin que les développeurs frontend ne soit pas bloqués.
• les développeurs frontend travaillent directement avec le PO et le UX designer lors de l’élaboration des vues.
• daily scrum
• les bugs sont ultra-prioritaires. Ce qui veut dire que lorsqu’un bug est remonté (selon sa criticité) il doit être assigné à la bonne personne et traité en priorité.
• Le description du bug doit être complète
• les développeurs vont voir le PO lorsqu’ils ont fini de développer leur partie de la feature afin de récupérer la tâche prioritaire suivante (modification de feature existante, etc..).
• le PO donne la priorité aux tests de l’application afin d’effectuer un retour rapide aux développeurs.
• la capacité de production se mesure par mois, et via le nombre de ticket clos

J’ai proposé ce système, car l’équipe de développeur est homogène et petite. De plus, le projet est ambitieux et demande une maximum de flexibilité. De ce fait, il faut une équipe qui soit capable d’intervenir rapidement en cas de bug critique ou de retour utilisateur soudain et qui soit prêt à pivoter sur le produit s’il s’avère être un échec. Dans ce cadre, ou les features sont développées “à la volé” avec des priorités clairement définies (stability over feature), les développeurs ne sont pas surpris par les changements soudains (qui arrive assez souvent).

Ce système a demandé un temps d’adaptation à tout le monde. Mais il ne faut pas sous-estimer le cerveau humain. Après tout, Ils se sont bien adaptés rapidement à SCRUM.. :-)

Depuis, le produit se porte bien. L’équipe est contente de se retrouver tout les jours. Le PO est vu comme le type qui challenge l’équipe technique.

Néanmoins, je ne suis pas sur que ce cadre convienne à une équipe & un projet différent.

Ceci reste une opinion, et j’aimerais bien savoir si vous avez eu des problème similaire avec la méthode SCRUM. Du coup, n’hésitez pas à laisser un commentaire.

Merci d’avoir pris le temps de lire cet article. :-)

PS: J’ai récemment créé une newsletter technique concernant Ruby & Ruby on Rails. N’hésitez pas à vous abonner ici !