Le manifeste « Fragile »

Le manifeste Agile est un outil simple, visuel et particulièrement puissant. Son objectif est pour moi assez similaire à celui des 7 principes du test: faire comprendre l’état d’esprit à adopter.

Pour rappel le manifeste Agile c’est:

D’ailleurs, je considère personnellement que le manifeste Agile est un peu comme les 7 principes, du bon sens!

Le manifeste est court, simple mais malheureusement pas assez efficace. Il permet de prioriser des actions à travers des valeurs, se fixer des objectifs mais aussi de boussole pour s’assurer que l’on est vraiment « Agile ».

Car oui, malgré sa simplicité apparente ce manifeste n’est pas toujours suivi ou est mal compris… ce qui entraine de nombreuses problématiques. Je vais explorer dans cet article 2 familles de dérives courantes que j’observe trop souvent lors de l’implémentation de l’Agile dans les équipes.

Le manifeste Agile ignoré

Par « manifeste Agile ignoré » je veux dire par là que 1 ou plusieurs valeurs de « droite » se retrouve mise en avant par rapport aux valeurs de « gauche ». Cette dérive est étonnamment assez fréquente et souvent lié à un fort historique cycle en V et une organisation avec de nombreuses personnes.

Concrètement cela revient à ce type de situation:

  • Les équipes se voient imposer des outils non adaptés ou contre productifs (mettre 8 heures à faire quelque chose qui prend 1 heure sans l’outil (et je l’ai malheureusement vécu personnellement)) car se sont des outils « groupe » ou alors les équipes doivent forcément passer par des processus longs (parfois plusieurs semaines), lourds et à forte inertie (à prévoir plusieurs semaines à l’avance) afin de pouvoir faire un déploiement en production
  • Les US se retrouvent à être des spécifications découpées! Au final, l’équipe Agile se retrouve à être une équipe de développement (car le tests est aussi souvent à part) qui développe de manière incrémentale mais en amont il y a une documentation exhaustive et en aval les tests…
  • La définition du contenu des sprints prévu à l’avance car cela a « été vendu au client pour cette date ». L’équipe se retrouve alors à ne plus être impliquée et totalement surchargée… ce qui induit de la mauvaise qualité et/ou des échecs des livraisons
  • Les demandes récurrentes de « visibilité » sur 6 mois ou 1 an, il faut savoir ce qui sera livré et quand!

Ces points peuvent vous paraitre totalement étrangers et dans ce cas tant mieux. Ils sont malheureusement assez fréquents dans des entités ou équipes qui se disent Agile.

Si vous faîtes face à ces problématiques ou problématiques similaires c’est que votre transformation Agile n’est pas finie et qu’il y a encore des efforts à faire au niveau de l’état d’esprit à avoir en Agile au sein des équipes et de l’entreprise.

Le manifeste Agile caricaturé

On est ici sur une « sur-interprétation » du manifeste. La partie droite disparait comme par magie. Les « plus que » ou « plutôt que » devient subitement « à la place de » ou « mais surtout pas ». Cela revient également à totalement oublier la phrase finale du manifeste:

 » Précisément, même si les éléments à droite ont de la valeur, nous reconnaissons davantage de valeur dans les éléments à gauche. »

Je vois de moins en moins ces dérives mais cela correspond à ce types de dérives:

  • L’équipe est totalement libre est fait ce qu’elle veut. Les outils changent régulièrement (ils peuvent dépendre du membre de l’équipe) et les processus sont inexistants ou ignorés avec, par exemple, l’absence de Defition of Done.
  • Seul le logiciel compte, il n’y a pas de documentation, pas de référentiel d’exigence, seules les US – souvent mal écrites – font foi. Au final la seule vraie connaissance est dans les têtes des membres de l’équipe… qui sont présents depuis le début du développement du produit.
  • Je n’ai pas encore été témoin d’absence de négociation contractuelle et donc pas de dérive de ce point de vue là pour moi! =)
  • Les équipes Scrum se retrouvent à avoir des sprints « mouvants » avec des US qui sont retirées ou ajoutées en court de sprint, doivent être livrées au milieu du sprint ou encore évoluent/changent en cours de sprint.

Ces points peuvent vous paraitre totalement étrangers et dans ce cas tant mieux. Ils sont malheureusement encore trop fréquents (particulièrement celui sur la documentation ou les sprints mouvants).

Dans le cas contraire, il reste encore du travail dans la transformation Agile et il est important de rappeler que l’Agile ce n’est pas l’anarchie mais une extrême rigueur nécessaire dans les processus de développements

Conclusion

Comme vous le vivez ou l’avez sans doute déjà vécu, les transformations Agiles ne sont pas un long fleuve tranquille. Le manifeste Agile est là pour guider ces transformations mais il m’arrive trop souvent de voir un manifeste Agile outragé, un manifeste Agile brisé, un manifeste Agile martyrisé… Bref un manifeste Agile bien trop fragile. Si l’on veut réussir à aller au bout de la transformation Agile il va falloir réussir à avoir un « Manifeste Agile libéré » et inébranlable.

Pensez à rejoindre le groupe « Le métier du test » si vous souhaitez échanger sur le test

Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles

N’hésitez pas à faire vos propres retours d’expérience en commentaire.

6 réponses

  1. Bonjour
    Je crois que j’ai vécu les deux à la fois.
    Manifeste ignoré parce que nous avions des outils imposés. Des processus longs définis par une seules et unique personne et qui ne reflétaient pas toujours le fonctionnement des équipes.
    Impossibilité de tester au cours du sprint : les tests ne pouvaient se réaliser qu’à la fin du sprint ;
    Manifeste caricaturé : pas de DOD ou pas de DOD suivi, des US déscopées au cours du sprint, d’autres ajoutées pour s’aligner sur les autres modules des autres équipes ayant finies et testées leurs US plutôt que prévu.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Image représentant le test et de nombreux éléments liés
Images

Le test en image (11) – la taverne en 2020

Aujourd’hui je déterre une série très ancienne d’articles: « Le test en image« . Nouveau temps, nouvelle méthode, l’objectif de cet article est double: continuer à proposer des images représentant le test mais aussi offrir une rétrospective partielle des activités de la taverne en 2020. Les certifications ISTQB évoluent, s’étoffent et accompagnent

Lire la suite »
Processus de test pour mise en place de l'IA. Challenger le besoin d'utiliser de l'IA Challenger les besoins pour développer l'IA Elements à mettre en place si l'on met en place une IA

Les impacts de l’AI Act sur les tests

Rappels rapides Après une présentation de l’AI Act, il me semble important d’identifier les impacts concrets que l’on va observer lorsque l’on travaille dans le test et la qualité! Pour rappel l’AI Act définit 3 niveaux de risques qui définissent les éléments obligatoires à fournir: En fonction du niveau de

Lire la suite »
Logo Qualité durable avec ces 3 piliers: - L'environnement, la priorité pour les utilisateurs et le bien-être des créateurs
culture générale

Pourquoi la Qualité Durable est-elle nécessaire ?

Lorsque j’écris des articles pour la taverne j’essaye un maximum de varier les sujets afin de toucher autant de monde que possible. Néanmoins, certaines thématiques reviennent plus souvent que d’autres. Parmi ces thématiques il y a eu en 2023 la Qualité Durable! Notamment avec la conférence à la JFTL ou

Lire la suite »