[Agile France] – Apologie du Mur
C’est lors du salon Agile France 2012, le 24 et 25 mai dernier, que j’ai eu l’occasion de donner une conférence nommée “Apologie du Mur” sur laquelle je vous propose de revenir via ce modeste article de synthèse.
Cette conférence traite des différents échecs rencontrés lors de nos projets et de leurs conséquences. Ces “murs”, souvent douloureux, toujours redoutés, sont pourtant souvent à l’origine d’une prise de conscience bénéfique pour un projet ou pour une équipe.
Découvrez ou re-découvrez à travers cette métaphore, l’apologie d’un mur trop souvent mal jugé !
Un mur ?
Tout d’abord, tentons de définir ce qu’est “un mur” que l’on peut rencontrer sur un projet, en omettant la première définition du dictionnaire traitant notamment de l’ouvrage de maçonnerie (ce sera peut être l’objet d’un autre article).
Le mur est ici une métaphore, représentant un imprévu ou un échec sur un projet, qui bouscule de manière inattendue le planning initialement prévu.
Derrière une tâche mal estimée, un choix d’outil inadapté ou un problème de livraison, le mur peut se cacher partout, à des degrés différents. Le plus souvent, la rencontre avec un mur n’est pas un évènement des plus joyeux car assez douloureux, du moins au premier abort.
Les murs jouissent donc d’une mauvaise réputation et sont le plus souvent redoutés comme le serait un diagramme de Gantt détaillé sur 2 ans présenté à un Agiliste en début de projet.
L’idée est ici, de voir à travers 3 exemples concrets, ce que peuvent apporter ces murs rencontrés sur un projet qui sont trop souvent injustement traités !
Les murs d’exemple
Mur N°1
Notre premier exemple se passe dans une société e-commerce, composée de plusieurs équipes dont une chargée de la maintenance et des évolutions du site.
Cette équipe, passée à l’agilité depuis quelques mois, emploie Kanban pour traiter les bugs et évolutions qui arrivent en flux chaotiques sur le projet. Son soucis premier étant la qualité de leur livrables, l’équipe a opté pour différentes stratégies de tests.
Des tests unitaires tout d’abord, permettant d’assurer un certain degré de qualité sur les composants techniques de l’application. Ces tests sont nombreux (75% de couverture du code), pratiqués en TDD, permettent de vérifier la solidité des briques techniques de l’application mais pas la cohérence entre ces différentes briques.
Des tests fonctionnels automatisés ensuite, pour assurer le fonctionnement nominal des principales fonctionnalités du site. Ces tests sont peu nombreux (1 ou 2 tests par fonctionnalité), assurent la cohérence complète d’une fonctionnalité mais sont difficiles à écrire et lents à l’exécution.
Si l’un et l’autre de ces tests se complètent plutôt bien, l’équipe a décidé de renforcer sa politique de tests en s’essayant à un troisième niveau de tests que sont les tests unitaires fonctionnels (ou TUF). Ces tests assurent la qualité d’un service complet sans la partie IHM. Ils allient, a priori, la rapidité d’execution et d’écriture d’un test unitaire avec l’efficacité d’un test fonctionnel.
L’adoption de ces TUF fût l’occasion pour l’équipe de se prendre un mur.
En effet, si les tests unitaires et les tests fonctionnels automatisés ont été rapidement adoptés et ont tout de suite prouvé leur efficacité, il n’en était rien pour ces fameux TUF.
Plus longs a écrire que prévus, difficiles à maintenir et finalement très peu efficaces pour relever différents bugs, ces TUF ont été abandonné au bout de quelques semaines d’efforts infructueux. (Attention, je ne remets pas ici en cause les TUF)
L’équipe a choisit une stratégie de tests finalement peu efficace, qui a de quoi décevoir à la vue du temps passé à réaliser des tests finalement abandonnés par la suite. Le mur fut ici un mur “Pas de bol”, à savoir un mur qui est survenu suite à un choix prit en conscience pour s’améliorer mais sans succès. Ce mur déçoit, du moins durant un court laps de temps, sans pour autant démoraliser toute une équipe.
Nous y reviendrons par la suite.
Mur N°2
Non, notre deuxième exemple, ne se passe pas dans une série des années 80 comme semble l’indiquer l’image à votre gauche. Elle se passe dans une société d’équipementier automobile (oui, il y a un rapport avec l’image) qui cherchait à gagner en flexibilité en passant à l’agilité notamment avec Scrum, sur un projet de portail d’entreprise.
Cette équipe composée de 5 personnes fortement motivées, commença donc ses sprints après une courte période d’étude du projet. Les 3 premiers Sprints se sont enchaînés avec une vélocité toujours croissante d’environ 30% à chaque nouveau Sprint.
Cette croissance de production montrée par l’équipe et applaudie par les demandeurs était malheureusement factice et la démonstration du 4ème sprint fût l’occasion à l’équipe de se prendre son 1er mur.
Sprint après Sprint, l’équipe tentait d’augmenter sa productivité au dépend de la qualité de ses livrables. Lors des 3 premières démonstrations, l’équipe arrivait à “masquer” les problèmes de qualité à grand renforts d’heures supplémentaires et de “rustines” appliquées continuellement. C’est lors de la 4ème démonstration que l’équipe, débordée par les bugs et fatiguée, n’a pu faire autrement que se prendre un mur révélant une qualité en berne et une vélocité réelle bien moindre que celle affichée.
Ce mur, qui surprend moins les développeurs que les décideurs, est survenu suite à une volonté de cacher un engagement trop élevé de la part de l’équipe (encouragée par les décideurs, il est vrai) sans réellement respecter la définition de l’état terminé (Definition Of Done) imposé pour chaque User Story, règle pourtant écrite par l’équipe elle-même. Ce mur peut donc être qualifié d’un mur “A la légère”, qui fait apparaitre au grand jour, un problème dans l’équipe dû apparemment à une application “à la légère” de certaines règles.
Ouch ! Ce mur n’est effectivement pas agréable a rencontrer, du moins au premier abord.
Mur N°3
Ce 3ème et dernier exemple (j’en avais d’autres, mais je pense à votre projet qui va prendre du retard en lisant un article trop long) se passe dans le milieu bancaire, avec une équipe composée de 7 personnes souhaitant gagner en flexibilité et en qualité, sur une application de gestion de portefeuilles.
Le projet était déjà démarré lors de la transition Agile, l’équipe a donc dû étudier son existant, se former sur l’agilité, choisir ses outils (Scrum) et écrire un backlog avec les spécifications qui étaient déjà réalisées. Le product Owner et le Scrum master désignés, se sont attelés à cette lourde tâche qu’est le portage des spécifications vers un backlog Scrum.
Une fois cette phase de préparation achevée, le Sprint #1 a donc pu commencer.
Evidemment (le suspens n’est pas vraiment là) ce premier Sprint fût l’occasion pour l’équipe de rencontrer un mur et ce, dès le sprint planning.
Mais pourquoi donc me direz vous ? Eh bien tout simplement car le Product Owner, qui voulait bien faire, a essayé de remanier seul le product backlog la veille du Sprint #1. Cette modification, pourtant basée sur la bonne volonté, s’est transformée en un élagage complet du backlog réduisant à 4 User Stories le contenu du fameux backlog (contre 72 précédemment). Enormes et sans critères d’acceptances, ces Stories n’étaient plus adaptées aux sprints de l’équipe et finalement non conformes aux définition de Scrum concernant les Stories.
Incapable de pouvoir s’engager sur ce type de User Story, toute l’équipe n’a eu d’autre choix que reporter ce premier sprint malmenant l’enthousiasme de chacun, en particulier celle du Product Owner qui eut bien conscience de son erreur.
Ce mur peut être qualifié du mur “A coté”, à savoir un mur engendré par des choix effectués en marge (à coté) des recommandations. Il fait mal, il est vrai, mais ce fût peut être un mal pour un bien.
La suite ?
Oui, parce qu’après ces différents exemples, vous pouvez simplement vous dire qu’un mur ne trouvent que peu d’émules sur un projet et que l’éviter n’est finalement pas une mauvaise idée.
Eh bien, sachez que je trouve plus dommageable d’éviter ces murs plutôt que de les rencontrer.
Sur ces 3 exemples, ces murs ont été bénéfiques une fois le premier effet Kiss Cool encaissé, à savoir reconnaître que l’on s’est trompé sur un choix, une décision ou un outil.
Sur l’exemple N°1, mettant en avant un choix de stratégie de tests (les TUF) infructueux, l’équipe s’est retournée après étude vers un nouvel outil de test fonctionnel automatisé cette fois ci très efficace. L’équipe a su rebondir sur l’échec des TUF en réalisant qu’ils n’étaient pas adaptés à leur contexte, pour ensuite s’accorder sur un nouvel outil et une nouvelle stratégie. Cet outil fût un succès, adapté à leur besoin qui trouva un écho positif dans la bouche de chaque membre de l’équipe.
L’exemple N°2, qui lui mettait en avant les problèmes de vélocité “inconsistante” de l’équipe qui s’engageait au delà de ses capacités, le mur a permis à tout le monde de comprendre la nécessité de définir des règles de qualité pour déclarer une User Story terminée (Defintion Of Done). De même, l’équipe a prit conscience que la notion d’engagement doit refléter un rythme soutenable afin de pouvoir garantir la régularité au fil des sprints. La aussi, ce mur difficile à accepter au début, fût un élément instructif pour l’équipe dans ce second temps qui a tout d’abord, corrigé ses bugs puis définit des règles à respecter aussi bien dans l’engagement que dans la définition de l’état terminé pour une Story. Ces bases “saines” ont marqué le début d’une agilité pérenne.
Quant à l’exemple N°3, le mur fût la aussi un élément très formateur pour l’équipe et le product owner principalement. Suite au malheureux remaniement du backlog par le PO, l’équipe s’est concertée avec ce dernier pour réécrire ensemble, un backlog clair, compris par tous et permettant de débuter sereinement un sprint #1.
Sur ces 3 exemples, le mur fût un élément déroutant dans un premier temps mais largement positif dans un second temps.
La vision du Mur
Ces murs, souvent assimilés à l’échec cuisant, la douleur, voir l’incompétence, sont en réalité bénéfiques sur vos projets la plupart du temps.
Cette volonté de tout prévoir, y compris ces aléas difficilement prévisibles, peuvent être une réminiscence de nos chers projets prédictifs (et de leur diagramme de Gantt) ou tout devait être envisagé. Dans le cas contraire, un imprévu dans un projet prédictif est synonyme de dépassement de coûts ou de délais rarement accepté par votre supérieur direct.
Pour résumer, le mur dans ce genre de projets prédéctifs (cycle en V ou modèle en cascade) est assimilé comme une faute grave. Le mur c’est la mort.
C’est différent en Agilité.
Souvenez-vous, l’agilité met en avant le changement comme étant le bienvenu dans les valeurs de son manifest. Le mode déterministe de l’agilité rend ces murs des acteurs, des outils comme les autres permettant de tester, réfléchir et choisir les orientations futures afin de s’améliorer en continu. En agilité, vous allez donc rencontrer des murs.
Pour autant, ne soyez pas kamikazes. Les gros murs doivent être évités pour ne pas affaiblir durablement le moral d’une équipe, votre productivité sur le projet ou la patience de votre product owner. Ainsi, les sujets d’architecture, de qualité ou d’organisation de votre équipe doivent souvent faire l’objet d’une étude collective pour éviter les écueils grossiers.
Exemple de Kamikaze
De même l’utilisation de la rétrospective ne doit pas être prise à la légère. Ce temps d’arrêt et de reflexion entre 2 cycles itératifs permet d’identifier les petits murs rencontrés avant qu’ils ne deviennent trop gros, de prendre des actions associées et d’en tirer pleinement profit.
Affichez vos murs, apprenez d’eux et comprenez qu’ils peuvent être le meilleur des professeurs.
Apologie du mur
C’est en adoptant cette idée que l’on peut parfois reculer pour mieux sauter, que vous serez à même d’apprécier à sa juste valeur ce mur trop souvent redouté, évité à tout prix ou même minimisé une fois rencontré.
Il est temps de redonner à ce mur injustement traité, toutes ses lettres de noblesse !
Pour aller plus loin …