10/07/2018
Les cadres méthodologiques agiles existent depuis bientôt 20 ans et connaissent un nouvel essor ces dernières années. Malheureusement, leur adoption conduit trop souvent à les dénaturer : on fait “un peu” de Scrum, “un peu” d’Extreme Programming. Rien de surprenant à cela tant les valeurs sur lesquelles ces cadres méthodologiques reposent sont étrangères à nos organisations. Au travers de cet article, examinons plus particulièrement pourquoi la confiance est à la base de l’agilité, et comment l’instaurer.
Dans le domaine du développement d’applications de gestion, les méthodologies séquentielles prédominent. Dans ce contexte, Jim Johnson, président du Standish Group, estime que 45% des fonctionnalités mises en œuvre ne sont jamais utilisées (1). Cela signifie que nous pourrions faire des applications tout aussi utiles en deux fois moins de temps ou avec un budget deux fois inférieur. Comment en sommes-nous arrivés là ?
Les méthodologies séquentielles (cascade et cycle en V) proposent de concevoir un système dans son intégralité avant de procéder à sa mise en œuvre. On constate fréquemment que, ce faisant, la peur d’oublier une fonctionnalité et de ne pas pouvoir revenir en arrière facilement conduit à une recherche effrénée d’exhaustivité. Lotir ne fait que repousser le problème car la définition des lots ex ante ne laisse aucune place au retour d’expérience utilisateur, ou alors chèrement payée.
Mais la cause première de cette dérive est que nous concevons des applications sans presque jamais demander l’avis de l’utilisateur. Car après tout, avouons-le, on sait quand-même mieux que lui ce dont il a besoin, non ?
Non.
Non, car nous ne sommes pas représentatifs de la population des utilisateurs, même quand leur métier nous est familier (cas des applications grand public, chacun sait par exemple comment réserver un billet de train). A cela plusieurs raisons :
Nous, informaticiens, devons donc nous déclarer “incompétents” et faire confiance à l’utilisateur pour savoir ce dont il a besoin. L’une des vertus de l’agilité est justement de remettre l’utilisateur au centre (User-centered Design) en l’associant à la construction de l’application. L’utilisateur intervient en premier lieu pour clarifier son contexte de travail, spécifier la fonctionnalité attendue, puis, une fois celle-ci mise en œuvre, faire part de son expérience à l’utilisation. Les cadres méthodologiques agiles facilitent cette démarche en travaillant à la maille de la fonctionnalité et en organisant le recueil régulier de ce feedback (Minimum Viable Product, livraison continue).
Posons-le tout de suite : le besoin étant dicté au fur et à mesure par l’utilisateur final et non le commanditaire, agilité et engagement de résultat ne sont pas compatibles. Le cadre contractuel forfaitaire n’a plus cours, un fournisseur ne pouvant s’engager à réaliser “quelque chose” quand ce “quelque chose” n’est pas identifié au départ.
Nous mettons ainsi le doigt sur l’une des principales difficultés de l’agilité : une très grande confiance doit exister entre un client et son fournisseur pour qu’un projet puisse se dérouler dans le cadre d’un simple engagement de moyens, qui implique que le risque financier soit entièrement assumé par le client. En renonçant à tout engagement forfaitaire, le client reconnaît la responsabilité qui est la sienne dans la réussite du projet : à lui de prioriser les fonctionnalités à mettre en œuvre, à lui de fournir les informations en temps et en heure et de décider sans délai. Le Guide Scrum est très explicite à ce sujet :
Le Product Owner est responsable de maximiser la valeur du produit et du travail de l’Équipe de Développement
Atteindre ce niveau de confiance est un défi difficile à relever. C’est d’ailleurs pour cette raison que l’agilité est une modalité que l’on rencontre le plus souvent en dehors du cadre contractuel client-fournisseur, au sein de start-up, éditeurs de logiciels ou de grands groupes dont les équipes sont constituées exclusivement de salariés.
Relever ce défi nécessite que client et fournisseur travaillent plus que jamais dans une optique de partenariat sincère et généreuse. Nous devons lutter pour retrouver cet esprit, mis à mal depuis longtemps par les notions de “périmètre” et “d’écarts de périmètre”, qui cristallisent tant de crispations. De toute façon, l’engagement de résultat initial est bien souvent dénaturé par de multiples avenants au travers desquels le client assume une partie de la surcharge de travail, si bien que l’engagement du fournisseur devient de facto un engagement de moyens.
En matière de partenariat, la proximité physique du Product Owner client et de l’équipe de développement fournisseur est tout à fait nécessaire. Cette proximité est à la source d’une multitude d’interactions informelles qui, inconsciemment, contribuent à faire tomber les barrières. Travaillant ensemble, client et fournisseur voient les impacts réciproques de leurs demandes et développent ainsi l’empathie nécessaire à un travail en harmonie.
Il serait temps, enfin, de faire confiance aux membres de l’équipe de développement, qu’il s’agisse d’analystes/concepteurs fonctionnels ou de développeurs. Ne sont-ils pas les mieux à même d’évaluer la complexité d’une fonctionnalité à mettre en œuvre ? Ne sont-ils pas suffisamment autonomes et responsables pour améliorer d’eux-mêmes leur productivité ?
Créer les conditions pour que chacun se sente investi de responsabilités est un formidable levier de motivation des équipes. Le cadre méthodologique Scrum pousse le principe à l’extrême et promeut leur auto-gestion, ce qui n’est pas sans rappeler les nouvelles formes d’organisation du travail dites “horizontales” et décrites par Frédéric Laloux dans son ouvrage Reinventing Organizations.
Plus de chef de projets, donc, mais un Scrum Master au service de l’équipe, avec une différence fondamentale : le premier dirige, le second facilite et conseille. L’organisation interne des entreprises de services informatiques s’en trouve profondément chamboulée. Que faire du sacro-saint chef de projets ? Certaines entreprises, parce qu’elles sont jeunes et n’ont connu que l’agilité, l’ont compris et se sont structurées en conséquence. Pour les autres, c’est un changement de culture profond.
Cette approche suscite de fortes réticences parce qu’elle se heurte à l’idée que la prise de responsabilités managériales est la seule réussite sociale possible. Aussi bon soit-il, un développeur de 50 ans est vu comme quelqu’un qui n’a pas réussi à s’élever socialement. Pourquoi ? Comment expliquer que la voie dite “technique” soit à ce point déconsidérée, sociétalement et salarialement ? Quand aurons-nous enfin des développeurs “stars” français, reconnus au même titre que Martin Fowler, Dan Abramov ou André Staltz ?
Cessons de dépeindre le développeur comme un solitaire produisant frénétiquement du code sans prendre aucune décision ni rien comprendre du contexte dans lequel il travaille. Accordons lui la place centrale qu’il mérite et qu’il va souvent chercher Outre-Atlantique à défaut de la trouver en France. Développer efficacement suppose une compréhension avancée de systèmes fortement complexes, une rigueur infaillible, une grande connaissance de soi et de belles capacités relationnelles. Qu’est-ce qu’un bon développeur sinon déjà un architecte en devenir ?
Ces propos ne remettent nullement en question l’utilité d’un management, bien au contraire. Mais souhaitons ensemble une direction recentrée sur sa fonction première : orienter, inspirer et fédérer en donnant du sens au travail. Comme André Comte-Sponville a su l’expliquer de manière lumineuse, un manager devrait tenter de répondre à la question “pourquoi travailler ?” plutôt qu’à la question “comment travailler ?”.
Cet article avait pour but de démontrer que l’agilité n’est pas une méthodologie projet mais bien un projet de société fondé sur la confiance. Certains parleront d’utopie, soit, mais pourquoi ne pas y aspirer et faire le premier pas ? La meilleure façon de savoir si l’on peut faire confiance à quelqu’un, c’est de lui faire confiance.
Cet article a initialement été publié par Mathieu Eveillard sur Medium.
(1) Proceedings of the Third International Conference on Extreme Programming and Flexible Processes in Software Engineering (XP 2002), Alghero, Sardinia, Italy (Requirements usage: Always 7%, Often 13%, Sometimes 16%, Rarely 19%, Never 45%).