Jour J-10 : Premier jour chez le client, grand compte français.
En tant que Product Owner sur un projet d’application mobile, difficile de cacher mon enthousiasme face à l’idée de me lancer dans un projet d’une telle envergure, pour une entreprise de cette renommée.
Jour J-4 – 9h05 : Comité de pilotage
« À compter d’aujourd’hui, on passe en mode agile sur le projet ! » annonce fièrement le client. Face à l’air dubitatif de son assemblée, il ajoute : « Rien à craindre, Mr X, expert agile dans l’entreprise, vous contactera bientôt pour une petite formation, vous verrez, c’est très simple… ».
Jour J
Mr X réunit toute l’équipe : développeurs, designers, Product Owner (en la personne du client…et de moi-même), Scrum Master (avec un peu de recul je suppose que ça aurait dû être moi, mais à ce moment-là, ce rôle n’avait en réalité pas été clairement défini).
Après trois heures de présentation de la méthode agile, des principes du Scrum et des bonnes pratiques à adopter, nous voilà tous théoriquement fin prêts à mener notre projet en mode agile… ou presque. Car ce qui devait être simple s’est en réalité avéré être tout sauf facile ! Et pour cause : à trop vouloir suivre ce qui était perçu comme une tendance, sans pour autant en comprendre les fondements et établir une transformation de fond, on limite fortement ses chances de succès.
Comment en sommes-nous arrivés là ? Retour sur les difficultés rencontrées dans le cadre d’un projet estampillé « agile ».
Sprint 1_Jour 1 – 14h : Réunion de « Sprint Planning »
Le projet ayant déjà été défini par une liste de fonctionnalités (devenue notre « Backlog produit »), il a suffi de choisir les plus importantes et hop, c’est parti ! Le périmètre de la première itération (« Sprint Backlog ») est identifié par l’équipe métier…à vous de jouer les dévs !
Sprint 1_Jours 2, 3, 4, etc. – 9h : Daily Scrum
Présence de toute l’équipe, présentation de l’état d’avancement, échanges pour préciser quelques fonctionnalités. Premier constat : ces dernières sont énoncées à un niveau trop macro, il est impératif de les découper en « User story » pour mieux juger de leur complexité ! L’exercice est fait pour le premier Sprint. Résultat des courses : une charge beaucoup trop importante pour un cycle de deux semaines, il faut donc prioriser. Relance de la machine… Promesse non tenue : les réunions quotidiennes censées durer 15min se prolongent et personne n’arrive à y mettre fin.
Sprint 1_Jours 7 et 8…
Premiers signes d’essoufflement : A et B ont un imprévu, le Daily Scrum passe à la trappe…en réalité, vu le temps quotidien requis, ils estiment avoir mieux à faire…
Sprint 1_Jour 9… les bonnes résolutions reprennent : Daily Scrum
Sprint 1_Jour 15
Démonstration (« Sprint Review ») – Les engagements en termes de périmètre n’ont pas pu être tenus mais tout le monde est conscient que l’on expérimente et que la capacité de l’équipe reste à affiner.
Rétrospective : mise en place progressive de la méthode agile…mais il va falloir identifier un gardien du temps pour ne pas déborder sur toutes les réunions !
Lancement du Sprint 2
Les Users Stories ont été à nouveau décomposées et l’on s’efforce de définir un périmètre raisonnable…toujours du point de vue de l’équipe métier. Cette-fois ci, petit changement : on soumet la Backlog aux développeurs pour avoir un avis sur l’estimation et réajuster le périmètre. Plusieurs items sont reportés à un prochain Sprint… « bon faisons leur confiance pour cette fois mais quand-même, il faudra être plus attentifs à l’avenir pour ne pas se faire embobiner par la MOE ! »
C’est à partir de là que les choses se corsent : progressivement, le représentant métier se perd dans son rôle de Product Owner et reprend sa posture de Chef de Produit. Il veut finalement que la fonctionnalité X soit intégrée dans le Sprint en cours, mais ne souhaite en aucun cas que cela se fasse au détriment d’une autre…il est le chef, le donneur d’ordre, sa parole prime donc ! Après tout, n’est-ce pas ça être agile ? Pouvoir s’adapter, être flexible et réactif en toutes circonstances ?
Pour poursuivre le projet dans de bonnes conditions sans passer par la case « Client insatisfait », après quelques négociations, les développeurs acceptent ce changement de plan. S’entame alors un cercle vicieux interminable, cadencé par des négociations sans fin, des bouleversements de périmètre réguliers, qui en réalité ont un prix, et non des moindres. Car, nous le comprendrons plus tard, toutes ces concessions ce sont faites au détriment de la qualité des livraisons qui s’est vu détériorée petit à petit.
À qui la faute ? Dans ce genre de situation il est toujours préférable de trouver un coupable, un bouc émissaire…le verdict est sans appel : si le produit est mauvais, les responsables ne peuvent être que ceux qui l’ont créé, développé ! Et hors de question pour le « donneur d’ordre » de se remettre en question. La MOE est pointée du doigt, le climat se refroidit, la collaboration se transforme en confrontation perpétuelle et la volonté de bien faire laisse place à la mauvaise foi des uns et des autres. Le projet se retrouve face à une multitude d’obstacles non pas techniques mais humains, et l’état d’esprit général se fonde désormais sur la méfiance et le manque de confiance.
Bilan
La situation décrite ici représente un cas d’échec de la mise en place d’une méthodologie agile, mais n’est clairement pas un cas isolé. Elle illustre simplement qu’il ne suffit pas de décider de devenir agile pour l’être. Pour y parvenir un travail de fond s’impose ainsi qu’une forte mobilisation. Évidemment, les échecs sont tolérés et c’est justement l’expérience qui permet de se perfectionner pour parvenir à construire une équipe auto-organisée et autonome.
L’agilité c’est avant tout une culture d’entreprise, des valeurs partagées, un état d’esprit positif et constructif dans une atmosphère de confiance où chacun peut s’exprimer. Être accompagné dans le lancement de la méthodologie peut souvent apporter les bases et bonnes pratiques à adopter pour en tirer le meilleur (cf « 7 recommandations clés pour démarrer du bon pied et réussir votre premier projet agile ! » par Sophia Hafyane).
Sara BENMOUSSA – Publié le 24 Mai 2017
