Respectons le sens des valeurs agiles

Il serait bien hardi de croire que des discours tels que : « le compte rendu, c’est superflu, depuis qu’on est passé en mode agile, on en rédige plus », ou « pas besoin de planifier, on est agile maintenant », soient en cohérence avec les valeurs agiles tant ces propos sont loin de respecter le cœur fondateur de notre manifeste préféré ; et pourtant combien de fois les avons-nous entendu ?

Nous possédons en tant qu’être humain une propension à interpréter les choses comme bon nous semble du moment que ces dernières nous simplifient la vie. Cependant ces interprétations, qui deviennent au fil du temps presque des convictions, souvent faute de remise en question, nous invitent à la dérive dans les pratiques ; et l’agilité n’y échappe pas.

Arrêtons-nous un instant sur le manifeste agile et sur les quatre valeurs qu’il porte. Que disent-elles :

source : www.agilemanifesto.org

« Les individus et leurs interactions plus que les processus et les outils »

D’accord, il faut privilégier les relations entre les individus avant de s’attacher au processus et aux outils. Mais qu’est-ce que cela signifie dans la pratique ?

Prenons l’exemple de l’envoi systématique de mails entre deux managers d’un même service pour tenter de régler une situation complexe liée à des subordonnés ou à un projet commun. Cette situation vous dit quelque chose ? Si c’est le cas vous savez aussi bien que nous que la lecture de ces mails faite par chacun, peut laisser place à l’interprétation et renforcer généralement le degré d’incompréhension entre les protagonistes. Cela fini assez régulièrement par générer de la tension. Il suffirait simplement, comme le dit cette valeur, de privilégier le face-à-face entre acteurs pour clarifier une situation avec un dialogue bienveillant dénué de suppositions.

 

« Des produits opérationnels plus qu’une documentation exhaustive »

Bien évidemment, vous l’avez reconnu, c’est le premier exemple de notre billet : « pas besoin de comptes rendus, on est agile » et ses variantes qui nous font tomber dans la facilité sont nombreuses. Force est de constater qu’à aucun moment, cette valeur n’indique de ne pas rédiger un document, aussi exhaustif soit-il. Si celui-ci est essentiel à la bonne conception du produit, à l’instar des documents de spécifications ou qu’il permet la clarté du projet à l’exemple des comptes rendus de réunions, tout nous invite à le rédiger.

Sous une mauvaise interprétation de cette valeur, certains membres de l’équipe auraient tendance à ne pas produire la documentation adéquate au détriment de la bonne réalisation du projet ou du produit. Nous avons observé ce cas avec les comptes rendus de réunions. Ces derniers sont souvent occultés en mode agile. Pourtant dans certaines situations, nous référer aux écrits des comptes rendus peut être salvateur.

Toutefois, il faut graduer la génération de documentation. En effet, au sein d’une équipe agile qui se connaît bien et qui évolue avec confiance et autonomie, la documentation écrite concerne essentiellement la compréhension que l’on se doit de donner au client.

Cette valeur veut nous engager dans notre capacité à « juste produire » la documentation essentielle pour aboutir à la compréhension et la conception d’un produit ou d’un logiciel opérationnel.

 

« La collaboration avec le client plus que la négociation contractuelle »

Ne nous le cachons pas, il est encore à ce jour épineux de négocier un contrat agile. Le plus généralement par manque de maturité des parties prenantes. Certainement aussi par simple réflexe naturel de protection mais encore plus raisonnablement par souci de limiter les risques en cas de « dérapage du projet ».

A ce jour, des exemples de contrats agiles existent, comme les contrats de forfaits à engagement de moyen, les forfaits sur une métrique ou encore les « target cost » qui permettent de conserver les avantages d’une démarche agile basée sur la collaboration.

Cette troisième valeur agile souligne l’importance de la confiance qui doit demeurer dans une relation client/prestataire. Evidemment cette confiance  ne peut naître que si le prestataire fournit un haut degré de visibilité et/ou de flexibilité avec une qualité de livrables maintenue dans le temps. De son côté le client, dont les exigences sont souvent changeantes, doit jouer le jeu de la disponibilité. D’un point de vue d’agiliste, il est intéressant d’ancrer la démarche dans une relation « satisfait/satisfait ».

Aujourd’hui il est nécessaire de prendre de la hauteur, et comme le dit Jurgen Appelo, de se considérer chacun, à travers nos contextes opérationnels, « comme le client d’autrui », et ce, dans le but de favoriser cette collaboration.

 

« L’adaptation au changement plus que le suivi d’un plan »

C’est la phrase moult fois entendue : « pas besoin de planifier, on est agile » révélatrice de cette valeur si souvent bafouée. En effet, le manifeste agile ne nous interdit en aucun cas de planifier et donc de suivre un plan ! Voire bien au contraire.

Il faut considérer qu’un individu qui clame qu’il n’y a plus besoin de planifier depuis que l’organisation évolue en mode agile, peut perturber de manière significative le système en place. Un tel comportement crée généralement de la tension avec une cellule de gestion de portefeuille de projets qui doit apporter une visibilité à l’échelon supérieur (au CODIR par exemple). A fortiori, si l’adoption de l’agilité en son sein n’en est qu’à ses balbutiements. Il devient judicieux de ramener le porteur de ce discours à cette quatrième valeur agile qui dit que planifier est une bonne chose même si réagir au changement est mieux.

Cette valeur nous invite donc à nous adapter aux changements qui interviendront dans nos projets, puisque nos environnements sont devenus de plus en plus complexes et incertains. Elle prépare notre esprit à la réactivité dans l’action. Comme le disait Kent Beck, il est nécessaire « d’embrasser le changement plutôt que de le craindre et de le combattre ».

 

Dans tous les cas, revenir systématiquement aux valeurs et aux principes agiles reste la meilleure façon d’agir. Ainsi, éclairerons les porteurs de ces différents discours en mettant l’essentiel au cœur de l’important. Portons à la lumière cette phrase, ô combien délaissée au fil du temps et des pratiques, gravée dans le marbre par les fondateurs sous les valeurs du manifeste :

«  Nous reconnaissons la valeur des seconds éléments mais privilégions les premiers »

Commentaires (1)

100% d’accord pour dire que l’absence ou le manque de documentation est anti-agile. D’une itération à l’autre il peut devenir très difficile de savoir ce qui était attendu à l’époque. Résultat : on croit accélérer en faisant l’impasse sur une tâche prétendument lourde, mais finalement on se ralentit.

De même, des US pas assez détaillées à l’écrit et explicitées à l’oral sont sources de tensions à moyen terme : « mais non je n’ai pas dit ça, tu as mal compris ! » « on ne peut pas dire que je n’ai pas suivi la spec ! » etc. –> niveau « individus et interactions », on peut faire mieux que ça !

D’où l’intérêt aussi d’avoir des rapports de bugs détaillés (–> ils peuvent expliciter un fonctionnement et un attendu à un moment donné) ainsi que des tests de non-régression automatisés (–> là aussi, on a une explicitation très fine du fonctionnement attendu).

Merci pour cet article !

Ajoutez un commentaire

Share This