Le courage de dire non

Nous sommes 4 à préparer le prochain séminaire SigmaT qui se déroulera dans le cadre de l'Agile Tour le 16 octobre. En plus de Thierry et Olivier, il y a maintenant Jean-Marie. C'est lui qui s'occupe de confectionner l'affiche qui va nous permettre d'annoncer cette demi-journée. En fait il est parti de l'affiche de Grenoble. Dans la partie droite, il y a une liste de méthodes agiles. Plutôt que de lister des méthodes confidentielles comme DSDM, Crystal, ASD, nous avons décidé de mettre des mots clés. Jean-Marie est parti sur 3 valeurs de XP : simplicité, rétroaction(feedback) et courage. Personnellement j'y aurais plus vu des pratiques que des valeurs et je tique un peu quand je vois écrit courage sur une affiche pour attirer le chaland à une conférence sur l'agilité.

Parce qu'enfin, qui n'est pas d'accord pour mettre le courage en avant ? Mais quel rapport avec le développement de logiciel ?

Le courage est une des 5 valeurs de XP. Je lis que XP valorise le courage. Est-ce qu'on doit comprendre qu'il faut être courageux pour pratiquer XP ? Ou que sa pratique rend courageux ?

Quand il présente XP, Thierry prend souvent comme exemple pour le courage, celui de jeter du code "pas beau". Mmmmmmmmmh, il me semble que ce courage est bien mince, que même parfois du code est jeté trop facilement. C'est l'effet "il vaut mieux tout réécrire".

En recherchant dans ma carrière à quel moment j'ai fait preuve de courage (ou j'aurais dû), la réponse qui me vient, c'est le courage de dire non. En particulier non à une demande qui rajoute du travail sans changer le délai.

De ce point de vue là, on peut considérer que les méthodes agiles encouragent le courage en donnant des facilités pour l'exprimer :

  • celui qui consiste à dire qu'on a un problème. Il en faut du courage, pour dire qu'on ne comprend rien à la nouvelle techno du framework de sécurité choisi sur le projet. Le scrum meeting favorise cette expression, avec la 3ème question.
  • celui qui consiste à dire non à un chef qui cherche à ajouter du travail à un sprint sans en changer l'objectif. Il en faut du courage pour pouvoir le faire et la gestion de projet à la scrum (ou à la XP) rend les choses plus faciles.
  • celui qui consiste à dire que le produit ne sortira pas à la date annoncée depuis longtemps, à moins qu'on réduise son périmètre, et qu'il n'est pas question de sacrifier sa qualité.

Pour en revenir à l'affiche, est-ce qu'y mettre courage (en petit) va nous apporter une inscription supplémentaire pour le séminaire du 16 octobre ?

Commentaires

1. Le mardi 22 juillet 2008, 13:48 par Fabien

Le courage, c'est aussi celui de conserver les bonnes pratiques lorsque tout ne se passe pas comme prévu. C'est, même quand les délais sont serrés, la résistance à cette envie de laisser tomber les tests pour faire vite et sale.
Comme dit Beck, le courage est la réaction face à la peur. La peur est est ce qui pousse certaines personnes à se protéger. Le courage, c'est ne pas craindre de ne plus être protégé.

2. Le mardi 22 juillet 2008, 20:56 par fredoc

En effet, le courage c'est aussi bien celui du ScrumMaster qui va jouer son rôle de facilitateur et se battre pour son équipe afin d'avoir les ressources (humaines, matérielles...) pour réaliser ls objectifs que l'équipe s'est fixée avec le Product Owner, que celui du Product Owner qui accepte la notion de priorité, de sortie régulière et planifiée en opposition avec les vieux réflexes de livraison contractuelle où tout doit être livré "à la fin"

3. Le jeudi 31 juillet 2008, 13:13 par iso9mix

Bien d'accord avec tes exemples de courage Claude mais aussi avec celui de Thierry : j'ai rencontré beaucoup de situation où les développeurs rechignent à supprimer du code pourri, et c'est psychologiquement compréhensible.

Quant à balancer tout le code pour repartir de zéro, je dirais que c'est une situation différente : si on eu le courage de remplacer progressivement du mauvais code, on ne devrait pas en arriver là.
Mais il est vrai qu'on rencontre parfois ce genre de situation.

A ces exemples de courage on pourrait ajouter celui de se mettre à la place de l'autre : client <-> développeur, développeur <-> coach...
Si j'ai bien compris, cette "empathie professionnelle" en essentielle à l'agilité

4. Le lundi 18 août 2008, 10:20 par JM.D

Pourquoi des valeurs pour illustrer et attirer vers les méthodes agiles ?

Pour répondre d'abord par la négative (le courage de dire non), je ne pense pas que des mots clé nommant des "pratiques" soient plus attirants. En effet : TDD, sprint, backlog, vélocité, binômage, user story, planning poker, rétrospective, ... ne me paraissent pas très compréhensibles. La difficulté de ce genre d'organisation est principalement de faire le choix du public visé. Nous avons décidé de privilégier un public "novice" et ces mots clé, même s'ils peuvent intriguer, vont-ils amener des "non convaincus" à se déplacer ?

Les valeurs me semblent plus fondamentales. Dans la démarche de Beck, des 5 valeurs sont déduites la douzaine de principes qui serviront ensuite à évaluer les pratiques proposées. Cette démarche est "ouverte" : si l'on souhaite installer une pratique qui n'est pas dans la liste de Beck, nous disposons des outils (valeurs, principes) pour décider de sa pertinence ou non. Présenter des méthodes comme "simplement" des assemblages de pratiques, des "recettes clé en main" pour la réussite (à définir) des projets, me parait très pragmatique mais moins "vendeur".

Plus particulièrement sur le courage, comme prévient Beck dans son ouvrage (XP Explained), sans les autres valeurs (feedback, communication, simplicité et respect), il n'amène qu'au "bidouillage" (dans le mauvais sens du terme). Il ne s'agit pas de faire la "tête brulée", tout seul dans son coin, ou de tout jeter pour tout refaire de façon irraisonnée, mais d'abord de mettre en pratique les autres valeurs puis de le faire avec courage. Toujours dans l'esprit de Beck, les valeurs sont là pour se renforcer mutuellement. Le courage peut alors apparaitre comme le supplément de motivation propre à nous aider à résister à nos vieilles habitudes, à aller un peu plus vers les nouveautés proposées par la méthode, ou encore, pour tenter de convaincre des interlocuteurs dubitatifs.

En cela, il me semble que la construction de l'affiche montre bien que ces valeurs s'épaulent et se complètent pour former un socle sur lequel sont construites les méthodes.
Mais comme nous travaillons de façon collaborative et concertée, cette affiche va encore bouger et je vous propose de suivre la suite de ses aventures sur le site de l'organisation : www.sigmat.fr !!