L’un de nos abonnés, dont nous tairons le nom, nous a fait parvenir un billet d’humeur, quant à la manière dont a été effectuée dans sa compagnie, la mise en œuvre de Scrum, la méthode agile vedette. On ne peut pas dire qu’il ait été ébloui par son efficacité et surtout par certains de ses artefacts, dont le moins que l’on peut dire, est qu’il ne les a pas tout à fait compris…
Bienvenue donc aux établissements « Duguidon », qui tentent d’appliquer à la lettre les principes Scrum…
Attention quand même. Le témoignage de Tom Barrett se veut humoristique. N’allez-pas nous faire un procès parce qu’il aura dit des horreurs…
La prochaine fois nous donnerons la parole à un inconditionnel…

Chez Duguidon, mon employeur, fabricant d’équipements pour cycles, on fait de l’informatique à l’ancienne, avec cahiers des charges et mises en production classique. J’ai aussi un boss, Bill, qui ne jure que par Java, surveille mon travail et me harcèle dès que j’ai quelques retards. J’ai beau lui dire que si je ne livre pas cette année, il n’y aura pas « le feu au lac », comme disent les suisses, il ne veut rien entendre. Il a des principes qu’il veut me faire observer.

A vrai dire, il m’agace.

En plus, il me fait participer à des comités de pilotage toutes les semaines où il invite les clients, des réunions qui ne servent à rien, car personne ne se comprend. Les clients parlent un jargon de comptables qui me passe au-dessus de la tête et Bill parle une langue perçue par les utilisateurs comme proche des hiéroglyphes égyptiens. C’est dire l’incompréhension. Des comités inutiles qui se terminent toujours par la désignation « aléatoire » de celui qui devra écrire le compte-rendu (les réunions ça sert surtout à faire des compte-rendus), le dénommé « aléatoire » ayant bon dos, car c’est toujours sur moi que ça tombe…

Bref, on fait du traditionnel et tout le monde est content.

Tout aurait pu continuer comme cela si Bill n’était pas tombé par hasard sur la publicité d’un consultant qui lui promettait le paradis sur terre, s’il adoptait une méthode révolutionnaire de gestion de projet, dite SCRUM.

Au début j’avais compris SCREAM (crier) et je me suis dit que peut-être il nous faudrait désormais hurler en réunion de pilotage pour mieux nous faire comprendre, mais ce n’était pas cela. Je me suis dit que c’était peut-être SCRAM (se sauver), histoire de nous donner un prétexte pour partir en courant lors de cette même réunion de pilotage.

Que nenni, il s’agissait bien de SCRUM, néologisme inconnu pour moi, puisqu’il veut dire mêlée chez les spécialistes du rugby, alors que je suis un fan de soccer. La mêlée étant cet agglomérat humain d’individus de 150 kg minimum (330 livres), qui fument comme les chevaux du Derby d’Epsom…

A vrai dire, l’inquiétude m’a saisi.

Peut-être que Bill voulait nous entraîner à la dure pour mieux nous préparer à affronter les « utilisateurs qui ne savent pas ce qu’ils veulent ». Peut-être était-ce plus grave.

Et j’avais raison de m’inquiéter.

Les développeurs SCRUM sont des équipiers et c’est eux qui valorisent le travail à effectuer en termes d’efforts de développement et de valeur ajoutée pour l’entreprise.
Des idées révolutionnaires

Car Bill lors d’une réunion efficace et courte dont il a le secret, qui commence en général à 7 AM et s’interrompt à 8 PM, vu qu’on n’a pas encore réglé le premier point de l’agenda, nous annonce derechef que dorénavant les projets seraient gérés conformément à SCRUM et que nous appliquerions 3 grands principes :

on commencerait à travailler sans savoir ce que l’on a à faire
il n’y aurait plus de documentation sur ce que nous allions produire et que le premier qui mettrait un commentaire dans le code serait fusillé
il n’y aurait plus de chef et que comme dans les Kolkhoses soviétiques, c’est nous les développeurs qui allions prendre le pouvoir. De l’autogestion qu’il disait. Et que d’ailleurs nous ne serions plus des développeurs, mais des équipiers comme chez MacDo.

Au début, on a cru qu’il se payait notre tête et on s’est mis à chercher discrètement mais fébrilement où était la caméra. Mais non, il n’y en avait pas. Il était sérieux et ne faisait que traduire pour les esprits simples que nous étions, les grands principes de l’agilité, tels quel les vrais développeurs, ceux qui ne font pas n’importe quoi, pratiquent aujourd’hui. Comme dirait le Gartner, en faisant la distinction entre les vieux qui font du Cobol et du cycle en cascade et les jeunes « agiles » qui pratiquent DevOps. Comme je ne savais pas ce qu’était DevOps, j’ai préféré ne rien dire.

Effectivement, le lundi suivant, Bill nous réunissait dans une grande salle nouvellement aménagée, dénommée « porte-avion » par Bill, qui a toujours eu le sens de l’humour, une plate-forme ouverte où tout le monde se voit, comme dans les séries américaines. Bill appliquant une autre règle SCRUM, à savoir que chacun doit pouvoir surveiller ce que fait l’autre. Ce n’est peut-être pas tout à fait ça, mais c’est ce que j’ai compris. C’est d’ailleurs ce à quoi semble servir un grand tableau papier, visible de tout le monde avec des « postits » jaunes, le « nec plus ultra » d’après Bill, puisqu’il vient du Japon (Kambon, Kanban ou quelque chose d’approchant).

Une fois l’installation terminée, Bill nous convia à la première réunion du nouveau projet, voulu par la direction, dit « zéro défaut ».

C’est là où il nous a présenté le véritable patron du projet, Marcel RouxVoilée, comptable chez Duguidon depuis 30 ans et qui connaît la boutique par cœur.

Pour faire sérieux, Bill nous a dit que c’était le « Product Owner »…

Et Bill de nous expliquer qu’avec la nouvelle méthode, le vrai responsable c’était lui, qu’il n’y avait plus de chef de projet et que lui Bill, devenait « Scrum Master », ce qui d’après sa fiche de poste, voulait dire qu’il devait désormais veiller à la santé morale des équipiers…ce qui a fortement ajouté à notre inquiétude.

Comme il est le chef, Marcel, Product Owner, nous a expliqué la finalité du projet, à savoir supprimer les retours de livraison clients, qui ont représenté plus de 60 % de celles de l’année dernière et interdire la perte du peu de clients qui nous restent. Un projet grandiose.

Il nous a aussi appris qu’il n’y avait pas de cahier des charges. Mais un « Backlog », qui était selon lui, la liste des « user stories » à affecter aux différents sprints du projet !!! Dont l’objet était de maximiser la « Business Value »…

Nous nous sommes tous regardés, convaincus, devant un tel délire, qu’il y avait forcément une caméra quelque part et Hillary, très forte en JavaScript, a prétendu qu’elle devait aller chercher sa fille à l’école pour s’éclipser. De peur de vivre la suite…

Les cérémonials de Scrum ont quelque peu déstabilisé notre auteur, plus particulièrement la réunion quotidienne « Scrum Daily Meeting » et son interdiction de s’asseoir…
La planification

Mais le pire était pourtant à venir.

Fort de son Backlog, Marcel nous a expliqué rapidement ce que devaient faire chacune des « user stories » qui le constituaient et nous a invités à une réunion dite de planification, dont il nous a annoncé qu’elle ne devrait pas dépasser 4 heures, sous peine de sanctions. Ca commençait mal.

D’habitude c’est Bill qui fait le travail, mais cette fois, c’est nous les équipiers qui devions nous y « coller ».

Comme nous ne savions pas comment nous y prendre, Bill nous a distribué à chacun un jeu de cartes, sur lequel était marqué « poker gaming ». Et on s’est dit que pour soigner notre santé morale, il avait peut-être décidé que l’on passerait désormais du temps à jouer au poker, pour nous reposer, mais sans que l’on comprenne bien le rapport avec la planification.

En fait, c’était très clair (!!!). Car à vrai dire le jeu de cartes n’en était pas un. Chaque carte affichant une valeur numérique : 0, ½, 1, 1, 2, 3, 5, 8, 13, 20, 40, 100 et ?. La suite étant, comme l’a précisé Marcel, celle de Fibonacci, célèbre depuis le Da Vinci Code que j’ai vu 3 fois, n’ai-je pu m’empêcher de préciser.

L’idée étant que pour chaque « user story », nous choisissions une carte pour valoriser l’effort de réalisation qu’il nous faudrait effectuer. En gros pour dire si elle nous semblait facile ou au contraire difficile à coder. Et Marcel d’ajouter qu’il fallait que nous soyons tous d’accord sur une valeur commune, sinon que l’on ne passerait pas à la « story » suivante.

Je ne veux pas vous importuner avec le détail de la réunion, qui au grand désespoir de Marcel et Bill,  a duré 4 jours pleins. Mais toujours est-il qu’en final, épuisés mais ravis, nous avions un planning sur 6 mois. Et c’est d’ailleurs à cette occasion que j’ai appris que l’équipe projet dont je fais partie avait une vélocité de 354.

Evidemment j’en ai été très honoré, sauf que je n’ai pas bien vu non plus à quoi ça correspondait.

Le quotidien

Il me faudrait des heures pour vous narrer ce que Bill nous a fait endurer.

D’abord, une réunion quotidienne dans le « porte-avions ». Il l’appelait la « scrum daily meeting ». Qui ne devait pas durer plus d’un quart d’heure et pendant laquelle on devait rester debout, face au tableau papier. Comme en Corée du Nord.

Inutile de vous dire que certains équipiers n’ont pas apprécié, d’autant qu’ils étaient sommés de s’exprimer chacun leur tour et de préciser où ils en étaient dans les tâches qui leur avaient été confiées.

Avec toujours le même ballet : «Je dis où j’en suis. Je me déplace vers le tableau. Je change un postit de colonne, je retourne à ma place ».

Impossible de dormir ou de consulter les résultats sportifs. Un vrai bagne qui c’est sûr allait nous mener au « burn out ».

Au bout d’un mois de ce régime, nous avions réalisé le premier sprint. Avec 332 points d’effort, car Marcel avait dû abandonner en cours de route quelques histoires impossibles à réaliser dans les temps impartis. Dont celle de la mise à jour des données livraisons clients, pourtant fondamentale, car au cœur de « zéro défaut », mais pour laquelle nous n’avions aucune directive précise.

Mais 332, ça m’a paru quand même pas trop mal, bien que ne voyais toujours pas à quoi ça servait, vu que jusqu’à maintenant j’ai toujours parlé en jours/hommes.

Les réunions de fin d’exercices

Contrairement aux réunions quotidiennes qui m’irritaient profondément, j’avoue avoir bien aimé les « Sprint Review » à la fin de chaque sprint. Des réunions pendant lesquelles, nous les équipiers et pas les chefs, pouvions présenter notre travail, Marcel en tant que « Product Owner » se gardant le soin de resituer le sprint terminé dans l’ensemble du projet « zéro defaut ».

Ce qui m’a bien plu, c’est que plutôt que de se mettre bêtement devant un écran avec les utilisateurs, on a préparé un petit buffet, avec quelques bonnes bouteilles pour accompagner nos démonstrations et les rendre plus agréables. Le tout sous l’œil attendri de Marcel « Product Owner » et de Bill « Scrum Master », ce dernier ayant compris que, somme toute, pour améliorer la santé morale des équipiers, le mieux est encore de la confier à quelques bouteilles de bon acabit…

Je dois reconnaître que la première « Sprint Review » a duré, elle-aussi, un peu plus longtemps que prévu, puisqu’en partant, légèrement titubants, nous avons croisé les services de nettoyage…

Pas de documentation

Outre ces cérémoniaux, auxquels il a bien fallu que je me fasse, la méthode SCRUM de Bill, nous a quelque peu bousculés dans nos habitudes techniques de développeurs.

D’abord pour la documentation, réduite au minimum, alors qu’il y a peu, Bill hurlait si nous ne produisions pas 350 pages pour illustrer la moindre fonction JavaScript.

A vrai dire, ça ne me déplaisait pas, car je n’ai jamais été bon en rédaction et à part rappeler le code, je n’ai jamais su ce qu’il fallait écrire pour être compris par la maintenance.

Le fait ensuite que nous ne sachions jamais très bien où nous allions en termes fonctionnels et que contrairement à l’objectif de l’agilité, nous devions revenir sans cesse sur les codes déjà écrits. Bill, jamais à court d’un néologisme appelait cela du « refactoring ». Evidemment comme ça, c’est mieux…

Quant à cette idée qui consiste à coder les tests avant les fonctions proprement dites, on ne peut pas dire qu’elle ait fait l’unanimité.

Car il faut être sérieux. Vous ne croyez pas que c’est complètement ridicule ? Si une fonction n’est pas codée, il ne faut pas être devin pour savoir qu’elle ne va pas marcher… A moins d’une intervention divine…

Ce qui a fait dire à un équipier qu’on le prenait décidément pour un primate…

Reste cette drôle d’invention qui a consisté à nous faire travailler en binômes sur un même écran. Ca ça ne pouvait évidemment pas marcher. Je connais mon métier et je n’ai pas besoin d’un coach pour me dire ce que j’ai à faire. D’autant que mon binôme à moi, n’a jamais voulu taper sur le clavier, sous prétexte que ça l’empêchait de réfléchir.

Je pourrais multiplier comme cela les bizarreries à l‘infini. Avec « in fine », au bout de quelques mois

de mêlée, un ressenti quelque peu mitigé….

Il paraît que cette méthode SCRUM dont Bill est si content, nous permet d’aboutir dans 85 % des projets, à la fois dans les temps et les budgets.

Je suppose que c’est vrai et en tout cas, Bill en est intimement convaincu.

Mais je n’arrive toujours pas à comprendre pourquoi il faut absolument simuler un QI (Quotient Intellectuel) négatif pour être éligible à cette méthode.

Y aurait-il correspondance biunivoque, comme disent les mathématiciens, entre agilité et enfantillages ?

En pratiquant Java, j’ai appris à coder dans un « bac à sable ». Avec SCRUM, j’ai l’impression d’être définitivement retourné en enfance.

Mais ça, impossible de le dire à Bill. Il ne comprendrait pas.