L’état d’esprit agile, plus que la méthode agile !
Depuis plusieurs années et après une transformation d’ampleur, l’AGILITE est devenue notre quotidien.
« Votre Daily vient de se terminer »
« Vous êtes pressés d’aller en démo pour voir la dernière fonctionnalité livrée par l’équipe de réalisation »
« Vous finalisez la rédaction de votre UserStory avant la séance de 3 amigos »
« Vous avez une PR en attente de relecture de code »
« Vous animez le story-map nécessaire à prioriser votre backlog »
« Le développeur vous attend pour une séance de Pair-Test » …
Sur tous nos projets, nous avons pioché dans les différents frameworks AGILE (KANBAN, SCRUM, SCRUMBAN…) des rituels, des boards etc… Des artefacts que nous manipulons maintenant naturellement. C’est devenu notre cadre, notre fonctionnement, notre langage.
Nous en maîtrisons, donc sans aucun doute, la forme, mais qu’en est-il du fond : le fameux mindset AGILE ?
Depuis un an, nous vous accompagnons sur les pratiques CRAFT & AGILE. Nous avons rencontré tous types de projets dans de nombreuses DSI. Vous nous avez parfois remontés vos difficultés sur la mise en place de tel ou tel artefacts AGILE … Mais finalement, ces difficultés ont souvent la même cause : essayer de mettre en place ces artefacts avant d’avoir ancré l’esprit AGILE.
L’AGILE ne se limite pas à ses Frameworks et ses artefacts. L’AGILE est un outil puissant mais son fond est bien plus complexe à appréhender et à appliquer que sa forme. Et pourtant, sans cet esprit AGILE, ces Frameworks deviennent vite inadaptés, impossibles à mettre en place, et peuvent même provoquer l’inverse de l’objectif recherché.
Donc, oui, reprenons depuis le début, et comme vous nous le faites régulièrement remarquer : « enfonçons des portes ouvertes », « prêchons des convaincus » … Nous allons vous rappeler ici, ce que nous avons tous vu 1000 fois dans nos cursus de formation AGILE :
Mais avons-nous vraiment intégré cette révolution de pensée qu’est l’esprit AGILE ?
Le SCOPE — La variable d’ajustement
A l’inverse du cycle en V (ou WaterFall), en AGILE, le coût et le temps sont fixés.
Donc pour réussir nos projets, la seule dimension ajustable reste le SCOPE.
Donc l’AGILITE, c’est se laisser l’opportunité d’ajuster le SCOPE.
Vous nous objectez alors : « Le métier ne voudra pas d’une version dégradée », « Cette nouvelle version ne sortira que si le SCOPE est ISO à la version précédente ».
Mais, nous y reviendrons …
Commencer par la fin
Vous avez peut-être eu la chance dans vos formations AGILE de participer au Marshmallow challenge. L’exercice est simple, par équipe munie d’un Marshmallow, quelques spaghettis et morceaux de scotch, vous devez, en quelques minutes, construire une structure pour porter le Marshmallow le plus haut possible. Les exercices montrent qu’à ce jeu, les meilleurs sont : les architectes et les enfants.
Laissons de côté les architectes qui « cheattent » par leur parfaite connaissance de la résistance des spaghettis.
Pourquoi donc les enfants sont-ils plus performants que les ingénieurs ?
Simplement parce que : les enfants commencent naturellement par la fin. Le plus « marrant » est d’empaler le Marshmallow sur un spaghetti et de voir ce que ça donne. Puis seulement après, ils pensent à monter une structure par la base, étage par étage…
A l’inverse, les ingénieurs élaborent une structure : elle est belle, d’aspect robuste, consommatrice de scotch, de spaghetti … de temps, puis … panique !!! … Il ne reste que quelques secondes…. « Posons le Marshmallow !!!! » … « CRACK !!!!!! ». L’issue est classique, ayant sous-estimé le poids du Marshmallow, la magnifique structure s’est écroulée …. Il est malheureusement trop tard pour envisager un « retour arrière ».
Donc l’AGILITE, c’est commencer par la finalité, avoir la lucidité de savoir que nous ne penserons jamais à tout, donc testons le plus vite possible, commençons par les défis le plus vite possible, levons les loups le plus vite possible, faisons notre demande d’ouverture de flux le plus vite possible…
Prioriser par la valeur
Une autre expérience, liée au point précédent, le puzzle.
La différence entre un « AGILISTE » et un « PUZZILISTE* » : le « PUZZILISTE » commence par les bords, l’AGILISTE commence par le centre. L’objectif de l’AGILISTE est de découvrir le plus rapidement possible la partie la plus intéressante, il ne perdra pas de temps avec les bords, pauvres pour la compréhension globale.
L’AGILITE, c’est identifier l’important et le prioriser.
Une seule constante « le changement »
Les User Stories (US) n’ont pas vocation à décrire complètement une « Feature », c’est un élément de travail, un jetable. La somme des US ne fera jamais une documentation exhaustive d’un produit : les US n’ont de sens que dans une temporalité et un contexte. Il est fréquent qu’une US « détricote » une US précédente. Et donc un cahier des charges ne sera jamais un bon backlog d’US.
Ne soyons pas dupes, nous l’avons tous vécu, il est impossible de penser à tout, et une seule chose est sure : « ça changera ». L’équipe PRODUIT doit pouvoir affiner, compléter son besoin au fur et à mesure des US, des incréments. L’équipe de REALISATION, elle, connait les pratiques de développements (BDD/PR/PT/CLEANCODE …) qui permettent d’accepter le changement sereinement.
L’AGILITE, c’est tester et adapter.
Maintenant, appliquons. Ceci n’est pas un exemple mais un retour d’expérience.
Voilà, maintenant que nous en avons fini avec ces quelques rappels tentant d’illustrer le mindset AGILE, appliquons-les, et prenons un cas concret. Un cas concret très représentatif, car nous le rencontrons dans le cadre de nos accompagnements plusieurs fois par semaine.
Nous sommes sur un projet de refonte, l’US présentée concerne un formulaire de demande d’attestation que le client peut utiliser pour envoyer une demande à son agent. Le formulaire est simple, et sa maquette fournie en pièce jointe a été pensée en avance de phase. Il comprend les informations de l’agent (Photo / Nom / Agence), une liste déroulante pour sélectionner le type de demande, un champ message pré-rempli que le client peut modifier, un compteur lui permettant de vérifier la longueur de son message, un bouton « Envoyer » et un bouton « Fermer ».
L’enjeux de l’US est simple, étant un projet de refonte, elle est vitale : « le produit ne pourra pas sortir sans ce formulaire ». La Business Value de l’US est donc de 1900, le maximum. Le cadre est posé.
La Business Value, est cette valeur arbitraire, sans échelle, indispensable pour prioriser les US dans un BACKLOG. Elle exprime la valeur métier apportée. Ici, l’équipe décide de travailler avec de grande valeur pour plus de finesse ; en limitant les égalités.
Premier constat
L’US est « énorme », elle comprend plus de 12 règles, avant même les 3 AMIGOS. Notre préconisation est d’éclater cette US. Il y a de nombreux intérêts à faire des US petites, ils seront égrainés au fur et à mesure par la suite. Mais l’un des plus évidents pour le pilotage de projet est d’éviter l’effet tunnel… une US comprenant 12 règles, c’est prendre le risque de 2 à 3 semaines de réalisation durant laquelle il n’y aura aucun état d’avancement factuel, aucune adaptabilité possible.
Une autre évidence : découper, c’est se laisser la possibilité de “paralléliser” les travaux.
Découpons
L’esprit AGILE, les puzzles et le MARSHMALLOW… nous aiguillent.
Identifions le « vraiment important », « recherchons du feedback », « levons les loups » et « commençons par la fin ». Le périmètre de la première US semble alors évident. Elle doit traiter de l’envoi du message, la finalité, la raison d’être, avec un formulaire vide, uniquement le bouton « envoyer » qui envoie le message par défaut. Cette US est idéale pour commencer, nous pouvons vérifier les dépendances, les ouvertures de flux etc. … Sa valeur Business est très importante 1900, identique à l’US initiale. Une fois rédigée, elle se limite à 3 Règles. Dans 2 à 3 jours, nous allons pouvoir cliquer sur le bouton « envoyer » et avoir nos premiers Feedbacks.
La deuxième US, émerge naturellement , ça sera la possibilité de modifier le message par défaut. Une nouvelle fois : rédigée, elle comporte 3 règles. La Business Value est de 1700.
La troisième US, parait découler : l’affichage des informations de l’agent. La rédaction commune de l’US commence, « En tant que … Je veux … Afin de … ? » et là c’est le blanc. Le « Afin de … » ne semble pas si évident… Il apparaît même que ces informations, quoi que présentes dans la maquette, n’apportent pas de valeur Business. Et pourtant, c’est une US qui techniquement n’est pas triviale, il faut récupérer les informations de l’agent, sa photo etc. … Un effort (budget/temps) difficile à justifier. Nous ne perdons pas plus de temps à investiguer, ni à rédiger (notion d’un backlog D.E.E.P). l’US n°3 n’a qu’un titre et une Business Value de 100.
Il reste quelques US, où riche de cette expérience, nous sommes vigilants aux « Afin de … »
Au final, nous avons découpé l’US initiale en 5 US.
En moyenne, chaque US comprend 2 à 3 règles. Le travail fourni pour l’écriture de ces 5 US est inférieur à celui de l’US initiale, car quelques-unes ont été jugées moins pertinentes et donc n’ont pas été « creusées » pour l’instant, et ne le seront peut-être jamais (Principe Lean). Mieux, le temps et le budget économisés, seront réinvestis pour enrichir d’autres fonctionnalités et apporter toujours plus de Business Values.
Nous sommes bien là dans l’approche prônée par l’AGILITE : Oui, c’est livrable dès la première itération. Ce premier livrable est bien LA réponse la plus simple au besoin fonctionnel exprimé : « permettre à un client de demander une attestation à son agent », le fameux « skate ». Il permet de « rouler » et surtout, maintenant il est testable. Nous nous laissons l’opportunité de l’améliorer par palier et tendre vers la satisfaction client optimale (« la voiture » peut-être), et le tout restant pragmatique.
Et donc non, l’AGILITE ne propose pas une version dégradée, « ni choisir entre son bras droit ou son bras gauche » mais l’Agilité garantie une version adaptée à nos clients à moindre coût.
Finalement
Le résultat est probant.
Nous avons mis en évidence qu’un projet, l’US initiale était considérée comme indispensable pour sa sortie, pouvait être mis en péril par le simple fait d’afficher des informations n’ayant aucune valeur. En découpant finement le besoin, en appliquant le principe de développement itératif et la priorisation par la valeur, nous construisons le produit ayant le plus de valeurs, et évitons les gâchis. Des US comme celle-ci, il y a des centaines par projets, sachant que nous travaillons sur des centaines de projets, à l’échelle : les économies seraient impressionnantes.
L’exercice est délicat, il nécessite toujours de « penser AGILE », ce qui n’est pas une pensée naturelle et les pièges sont nombreux. Par exemple, un des plus fréquents est de se laisser influencer par les maquettes proposées. Il faut les considérer comme des propositions, le respect de leur forme est indiscutable, le détail fonctionnel de leur contenu doit être toujours challengé par une approche itérative.
Pour conclure
Donc le mindset AGILE, c’est, entre autres, se laisser l’opportunité de jouer sur le SCOPE : variable d’ajustement.
Autrement dit, confondre l’esprit AGILE et l’utilisation ses frameworks AGILE, c’est figer les 3 leviers : COUTS / DELAI / SCOPE, et donc c’est l’échec assuré.
Nous finirons sur cette dernière formulation,
le mindset AGILE c’est l’assurance de ne jamais manquer une DEADLINE dans un coût maitrisé.
