Demandez à un Québécois ce qui le dérange le plus chez les Français et il vous répondra en premier que les Français sont prétentieux, le fameux Maudit Français. En deuxième viendra le fait que les Français sont tout sauf pragmatique.

En caricaturant un peu, si on demande à un Québécois de construire un barbecue, la première chose qu’il fera sera d’aller chercher des tôles et de les arranger ensemble. Le Français va d’abord réunir un groupe de travail pour discuter de quoi ils vont discuter pendant les prochaines réunions qui détermineront quand faire les réunions pour écrire la documentation qui expliquera comment organiser les réunions !

Un mois plus tard, le Québécois aura un tas de tôle qui permettra de se cuire des saucisses et le Français aura une pile de documents qui permettront sans risque et rapidement de fabriquer le barbecue…

Quand des Québécois et des Français travaillent ensemble, le premier est exaspéré de voir le nombre de réunions, de discussions, de documents produits et le peu de temps à réaliser réellement le produit demandé. À l’inverse, le Français est exaspéré de voir le Québécois foncer tête baissée dans le projet sans même réfléchir aux risques, processus, méthodes, qu’il risquent de rencontrer.

Si je devais choisir entre ces 2 extrêmes, je choisirais surement la solution Québécoise, car au bout du compte on a quelque chose de concret à montrer qui a une réelle valeur pour le client.

Évidemment, la meilleure solution serait un mixe des deux et c’est exactement ce que prônent les méthodes agiles. Malgré ce que pensent beaucoup de monde, elles ne consistent pas à foncer tête baissée sans réfléchir, mais proposent d’avancer concrètement sur le projet jusqu’au moment où un problème survient, alors, à ce moment-là, l’équipe entière se pose autour d’une table pour trouver une solution. Tout le problème est donc de mettre en place des pratiques pour détecter facilement l’apparition des problèmes au cours du projet.

Pourquoi devoir faire des réunions pour trouver une solution à un problème qui n’existe même pas au moment où on fait cette réunion ? À moins d’êtres réellement voyants, vous n’avez aucune idée de quels problèmes se produiront réellement pendant votre projet.

En utilisant cette méthode, il sera facile aux anti-agilistes de dire au moment où un problème est détecté “Ah !! Vous voyez, je vous l’avais dit il y a 6 mois que vous aurez ce problème et maintenant on va mettre 2 fois plus de temps pour le résoudre que si on avait réfléchi à ce problème dès le début “. En effet, ça sera surement plus long à régler, mais à côté de ça, combien de réunion et de mise en production de solutions plus ou moins lourdes pour des problèmes qui ne se sont jamais produits ont été évités.

Ce pragmatisme s’applique à tous les niveaux, aussi bien pour le code (éviter de faire de l’overdesign) que pour le management. Pourquoi planifier des réunions pour faire communiquer les programmeurs entre eux s’il n’y a pas de problème de communication ? Même si sur un précédent projet, ce problème se posait, aucun élément ne permet d’affirmer de façon certaine que ça se reproduira. Les projets ne sont pas les mêmes, les équipes non plus, etc.

Dans le développement logiciel, il existe des milliers de problèmes qui peuvent se produire lors d’un développement. Mais vous ne saurez jamais à l’avance lesquels de ces milliers de problèmes tomberont sur votre prochain projet. Il est illusoire de croire que vous pourrez lister et prévoir tous les problèmes donc autant mettre en place des moyens de les détecter quand ils arriveront et de prendre le temps de les résoudre dès qu’ils apparaitront. Alors, profitez du fait que vous n’ayez pas de problème aujourd’hui pour avancer sur votre projet plutôt que vous prendre la tête à résoudre des non-problèmes !

Pour résumer simplement la démarche agile :

• L’équipe développe le projet jusqu’au moment où quelqu’un lève un problème.


• L’équipe se réunit pour exposer le problème et trouver une solution.


• L’équipe applique la solution et reprend le développement.


• À la fin de l’itération (une ou deux semaines), lors de la réunion de rétrospective, l’équipe se demande si la solution a bien résolu le problème. Si la réponse est oui, alors l’équipe continue à appliquer la solution. Si la solution n’a pas fonctionné, l’équipe se réunit pour trouver une nouvelle solution, l’applique pendant une itération, refait une rétrospective et ça boucle jusqu’à ce que le problème soit résolu.