Introduction
S’il y a un type d’erreur qui m’a posé des problèmes dans ma vie de consultant (et pas que!) c’est bien le fait de tirer des conclusions et de faire des jugements sans bien appréhender, au préalable, le contexte.
Je parle d’ailleurs de ces erreurs dans une de mes expérience chez Orange et une autre sur la mise en place d’une stratégie de test. Et, comme vous pouvez le constater, c’est un type d’erreur où l’on peut facilement se faire prendre plusieurs fois.
A titre personnel, je reproche souvent à des personnes de faire des jugements sur les réseaux sociaux cette erreur. D’arriver, de voir un post et tout de suite d’expliquer en quoi ce qui est montré est particulièrement mauvais. Toujours sur les réseaux sociaux je réponds (trop) souvent du tac au tac en me disant que les personnes ne connaissent pas suffisamment le contexte et essaye de leur expliquer…
Le problème ? Cela fini souvent en dialogue de sourd… Avec du recul (et la baisse d’adrénaline) je suis obligé de reconnaitre que de mon côté également, je suis retombé dans cet écueil de juger sans connaitre le contexte… Car je me retrouve à prêter des intentions à des personnes par rapport à leurs écrits sans réellement connaitre les raisons de ces écrits. Et, spoiler alerte, il s’avère très souvent que je m’étais trompé dans mon interprétation.
Comme vous pouvez vous en apercevoir je suis loin d’en avoir fini avec cette erreur mais je continue à faire des efforts pour l’éviter autant que possible!
Importance d’intégrer le contexte
Au delà de mes expériences personnelles (professionnelles ou non) il est particulièrement important de s’assurer d’une compréhension suffisante du contexte avant tout jugement ou prise de décision.
En effet, ce manque d’appréhension globale engendre de nombreux problèmes comme:
Un rejet pur et simple de ce que l’on propose
Cette conséquence n’est pas forcément la pire. Néanmoins, on peut se retrouver à avoir un rejet pour quelque chose qui aurait vraiment apporté de la valeur… Si elle avait été présenté d’une meilleure manière (avec des arguments qui auraient parlé aux interlocuteurs) ou si l’on avait acquis la légitimité suffisante dans son équipe.
Un rejet de notre personne et de tout ce que l’on pourra proposer
On est ici sur un autre niveau de rejet. Au final ce n’est pas ce que l’on propose qui est rejeté mais nous même. Cela fait généralement suite à une proposition particulièrement clivante ou rejetée dans l’équipe ou à un enchaînement de propositions rejetées.
A la fin l’équipe ne veut même plus échanger avec nous.
Des propositions non adaptées
C’est l’erreur la plus courante. On se retrouve à proposer des solutions qui ne sont pas applicables. Dans ce cas on fait perdre du temps à tout le monde avec une tentative d’implémentation qui doit ensuite être abandonnée.
Exemple de problème: un problème de temps sur l’exécution des tests
Solution possible 1: tests exploratoires
Problème solution 1: impossible à mettre en place pour certains tests réglementaires. Proposer des tests exploratoires pour gagner du temps dans ce cas n’est potentiellement pas valide par manque de traçabilité.
Solution possible 2: automatisation
Problème solution 2: si c’est pour des tests qui ne seront effectués qu’une seule fois ou des tests de bout en bout particulièrement complexes ou encore un manque de budget et/ou temps d’investissement l’automatisation peut s’avérer un échec ou tout bonnement impossible
Des propositions contre productives
C’est un peu le problème précédent poussé à l’extrême. On peut se retrouver à proposer une solution qui semble bien par rapport à une problématique mais qui s’avère aller à l’opposer de ce que l’on souhaite.
Exemple de problème: ce qui est livré ne correspond pas à l’attendu
Solution possible: proposer de faire des revues en entrée des tests
Problème solution: si le problème ne vient pas de la qualité des spécifications mais du recueil (ou de la compréhension) du besoin alors les équipes vont continuer à livrer ce qui n’est pas attendu et cela va créer de la frustration ainsi qu’un rejet des revues. De même, faire des revues efficaces ne s’improvise pas. Il est important d’accompagner les participants (voir de les former) afin d’éviter des dérives. Des revues qui se passent dans un climat délétère peuvent vite conduire à des personnes qui ne veulent plus se parler ni travailler ensemble.
Des propositions qui ont déjà été essayées et en échec
On est ici sur une autre variante des propositions non adaptées. Le hic c’est qu’en plus on montre ici qu’on ne connait pas le contexte, ni le produit. Cela peut alors conduire à nous identifier comme quelqu’un de « théorique » mais qui ne connait rien à la pratique et à décrédibiliser notre parole.
Conclusion
Une information seule, tout comme un indicateur n’est pas suffisante pour se forger une opinion.
Si l’on est dans une équipe qui ne fait pas de daily meeting peut-on en conclure que ce n’est pas une équipe Agile ? De même si cette équipe en fait, faut-il en conclure le contraire ?
J’ai connu beaucoup d’équipes qui se disaient agile car il y avait un daily meeting. Malheureusement ces dailys pouvaient être très long et improductifs… Tout en n’effaçant pas les habitudes du cycle en V avec des dates et des périmètres définis.
De même, il existe des équipes agiles qui communique de manière fluide toute la journée et qui peuvent être amenées à ne pas avoir de daily car il est devenu inutile, la synchronisation qui doit être amenée par le daily se faisant en continue.
Une fois n’est pas coutume, je souhaiterais finir cet article avec les paroles d’une de mes chansons préférée, « Enemy without« , qui résume parfaitement ma pensée:
You cannot judge me
That’s not your right
This is my room, no key, no light
You stand behind those faithless words
Have you seen what I’ve seen?
Have you heard what I’ve heard?
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.
