- "On a mis en place les méthodes Agiles avant que ça ne soit à la mode !"
- "On a une équipe full Scrum ici, on fait un scrum meeting tous les matins"
Des exemples de personnes qui te vendent de l’agilité sans s’être posé la question de ce que c’est vraiment, malheureusement il y en a beaucoup. Les exemples ci-dessus sont des choses que j’ai vraiment entendues parmi tant d’autres.
Ces phrases participent à une mauvaise compréhension globale de l’agilité. Elles deviennent assez rapidement une "private joke" quand on évolue dans un milieu qui comprend l’agilité, ses forces, ses faiblesses, sa philosophie et ses méthodes.
Si tu es responsable d’une équipe, tu as déjà été confronté à une mauvaise explication de l’agilité.
Si tu es dev, tu as déjà entendu ça des dizaines de fois.
Sans parler de certains recruteurs qui te promettent une équipe “Scrum Agile XP++” à la moindre occasion. Ils savent que c’est en vogue, et ils pensent que c’est suffisant pour rendre une offre d’emploi attractive.
Je parlerais un jour des recruteurs, parce qu’il y en a plein qui font bien leur travail dans le milieu de l’IT, mais les pauvres sont éclipsés par les quelques-uns qui ne connaissent pas notre métier et disent des choses affreusement drôles (ou juste affreuses).
Bref c’est bien joli tout ça, mais si on ne parle pas des perles des recruteurs, on parle de quoi alors ?
Bien c’est assez simple, j’vais t’expliquer rapidement (et j'espère simplement) ce que ça veut dire d’être agile. Je ferais de mon mieux pour te donner quelques éléments clefs qui te permettront de faire la différence entre une équipe Agile et des gens qui te vendent une agilité qui n'existe que dans la description du poste.
Mais c’est quoi alors "être Agile" ?
Origine des Méthodes Agiles
Bon, selon les sources que l’on trouve sur le sujet, on trouve des traces de l’origine de "l’agilité" entre 1950 et 1990. Ça nous fait une sacrée belle fourchette ça ! Et 1950 ça paraît très vieux pour quelque chose qui semble si récent. On peut l’expliquer assez simplement: développer un logiciel est une tâche complexe, n’en déplaise à tous les tutos sur internet "apprenez à coder en deux jours". Oui, on peut apprendre à coder rapidement. Mais créer, maintenir et faire évoluer un logiciel sont des tâches interdépendantes et particulièrement complexes. Ce n’est donc pas anormal de voir qu’on se pose des questions sur comment bien faire ça depuis que l’on crée des logiciels.
Tout ça pour dire, la date de création on s’en fout en fait, comme de savoir qui en est l’inventeur. D’ailleurs, spoiler: il n’y en a pas vraiment. C’est en fait beaucoup de gens qui se sont posé les mêmes questions au cours du temps, et qui ont trouvé des réponses allant dans la même direction, avec des méthodes qui prônent la flexibilité et le bon sens (en gros).
En fait, une bonne partie des problèmes auxquels on fait face aujourd’hui en logiciel, existent depuis qu’on fait du logiciel. Il a fallu apprendre à s’adapter au changement dès le début.
Parce que le client qui change d’avis (au dernier moment idéalement d’ailleurs) eh bien ça existe depuis l’invention de l’offre de service + 20 minutes à peu près. N’oublions pas non plus qu’on peut aussi avoir des surprises durant un projet (un risque quoi), qui fait qu’on doit réagir rapidement. Tout ça existait aussi dans les autres domaines avant d’ailleurs, ce n’est en aucun cas propre au logiciel.
On commence à nommer ces approches “méthodes Agile” suite à la rédaction du “Manifesto for Agile Software Development”, rédigé en 2001 par 17 professionnels du logiciel. Ce manifeste a été complété quelque temps plus tard par un autre document avec le “Manifesto for Software Craftsmanship”. Ces manifestes ont pour but de donner les principes fondamentaux de “comment faire un logiciel correctement”.
La philosophie de l’agilité
Alors, que nous disent ces manifestes ?
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more.
Je vous offre ma traduction (de rien, ça me fait plaisir) :
Nous identifions de meilleures manières de développer des logiciels en le pratiquant, et en aidant d’autres à le faire. Au travers de ce travail, nous en sommes venus à valoriser: Les individus et leurs interactions plutôt que les processus et les outils. Un logiciel fonctionnel plutôt qu’une documentation complète. La collaboration avec le client plutôt que la négociation du contrat. Réagir au changement plutôt que suivre un plan. Ceci étant, même si les éléments de droite ont de la valeur, nous considérons que les éléments de gauche en ont plus.
Le tout étant complété par les “Twelve Principles of Agile Software” qui nous détaillent un peu plus les idées du manifeste lui-même. Je ne vais pas les détailler ici, je le ferai dans le prochain article, mais je t’invite fortement à y jeter un œil si tu as 5 minutes.
On va prendre un instant pour réfléchir à ça, parce qu’en arrière de l’apparente simplicité du manifeste, les mots ont été choisis avec grand soin. On prend ce moment de réflexion aussi pour éviter d’en sortir la conclusion préféré de tout bon dev qui se respecte : "Ouaiiiis trop cool, on fait pas de doc, ils ont dit que ça servait à rien, on va écrire du code tout dsuite !"
Tout va bien
Que nenni cher collègue barbu (ou barbue, n’ayons pas peur d’être inclusifs) ! Personne n’a dit que ça ne servait à rien, bien au contraire. Ce qui est intéressant dans ce manifeste, c’est justement la nuance qui y est incluse.
Une lecture un peu trop rapide de la chose pourrait nous amener à penser que la doc, les outils, les processus et les plans c’est naze, ça nous ralentit, c’est donc contre-productif, donc hop, on n’en fait pas !
Non non non !
Ce qui est dit ici c’est que livrer un software qui fonctionne c’est plus important que de donner une doc bien faite. Mais absolument pas que la documentation ne sert à rien.
Exemple: Si tu achètes une boîte de Lego, tu pourras jouer avec même si la notice de montage est manquante. Par contre tu risques d’avoir pas mal moins de fun si tu as la notice mais pas les briques. La meilleure expérience que tu pourras avoir, c’est en ayant les briques ET la notice !
Je ne te ferais pas l’affront de trouver une métaphore pour chacun des 4 principes, je pense que tu as saisi l’idée: le manifeste donne les éléments clefs à considérer pour la réussite du développement d’un logiciel, et leur donne un ordre d’importance.
Dit autrement, les 8 éléments présentés sont indispensables pour fournir un logiciel de qualité. Par contre, les éléments de droite n’ont de valeur que si ceux de gauche sont réussis.
Passons maintenant au second manifeste, qui est construit sous forme d’écho au premier :
As aspiring Software Craftsmen we are raising the bar of professional software development by practicing it and helping others learn the craft. Through this work we have come to value: Not only working software, but also well-crafted software. Not only responding to change, but also steadily adding value. Not only individuals and interactions, but also a community of professionals. Not only customer collaboration, but also productive partnerships. That is, in pursuit of the items on the left we have found the items on the right to be indispensable.
Le voici traduit par mes soins :
En tant qu’aspirants artisans du logiciel, nous montons la barre du professionnalisme dans le développement logiciel en le pratiquant et en aidant d’autres à apprendre cet artisanat. Au travers ce travail nous en sommes arrivé à valoriser: Pas seulement un logiciel fonctionnel, mais aussi un logiciel bien fabriqué. Pas seulement une réaction au changement, mais aussi l’ajout constant de valeur. Pas seulement les individus et leurs interactions, mais aussi une communauté de professionnels. Pas seulement la collaboration avec le client, mais aussi des partenariats productifs.
On a ici un chouette complément au manifeste agile, qui nous indique à quoi faire attention pour arriver à faire ce que le premier manifeste nous dit.
Je dois dire en passant, que j’aime beaucoup l’utilisation du terme d’artisanat. Ça rejoint assez bien l’illustration que j’ai utilisée plus haut au sujet des tutos qui nous apprennent à être dev en deux jours. Oui ok, on peut apprendre beaucoup de choses rapidement dans ce milieu, mais il n’en reste pas moins que faire un logiciel est un acte artisanal. Il faut beaucoup de pratique et d’expérience bien utilisée pour arriver à produire de vrais bons résultats dans notre domaine. Je trouve que l’aspect artisanal n’est pas assez mis en valeur dans notre métier, et c’est très probablement à cause de son aspect immatériel et impalpable.
Revenons sur le contenu de ce second manifeste. Les deux premiers éléments sont pour moi des indicateurs à mesurer lors du déroulement du développement d’un logiciel. Oui, parce que pour avoir un logiciel qui marche et qui continue de fonctionner avec le temps, ben il faut qu’il soit bien fait !
Présenté comme cela, c’est évident. Mais les équipes sont très (trop ?) souvent mises sous pression par leur environnement pour livrer vite. On veut en général arriver en premier, et on nous fait alors oublier la valeur des choses :
- "On corrigera ça plus tard"
- "C’est une feature cool, mais on n’a pas le temps de l'implémenter là là, parce qu’on est en retard sur [ un truc ]"
- "C’est suffisant pour le moment"
Ces petites phrases indiquent souvent qu’on choisit la vitesse au lieu de la qualité, ou de la valeur apportée. Elles sont d'excellents indicateurs des moments charnières où l’on commence à mettre beaucoup d’énergie aux mauvais endroits.
Les deux autres points sont plus axés autour de l’humain créateur de valeur dans le projet. Certes, c’est bien si les membres de l’équipe interagissent, mais est-ce suffisant ? Je ne pense pas qu’il existe une seule équipe 100% compétente sur tous les aspects d’un projet. La collaboration avec l'extérieur n’est pas optionnelle dans ce métier. Il n’y a qu'à voir le succès des plateformes d’échange entre professionnels comme StackOverflow par exemple.
En bref
Je pense au final que la philosophie de l’agilité c’est de combiner et d’utiliser plusieurs qualités dans son équipe et personnellement.
- La modestie déjà. Histoire de savoir à quel moment on a besoin d’un coup de main d’autres gens pour faire les choses correctement, et aussi simplement pour être bien certain de savoir ce qu’on sait.
- La patience aussi. Faire les choses correctement, ben ça prend du temps, il n’y a pas de secret. Le terme d’artisanat à lui seul met, à mon sens, beaucoup l’emphase sur cette qualité.
- La prise de recul. Parce que nous sommes dans un milieu qui évolue tellement vite qu’on a tendance à foncer tête baissé lors de nos prises de décision. Prendre du recul, c’est utiliser de nouveau notre bon sens. C’est prendre une pause de temps en temps, et regarder si tous nos actes et décisions sont cohérents entre eux, et avec le projet, dont l’objectif évolue au cours du temps.
- La flexibilité bien entendu. Tout change vite, il faut apprendre à être à l’écoute de l’évolution des besoins, et savoir pivoter au bon moment.
- La transparence, dans le succès comme dans l’erreur. Chaque membre de l’équipe doit être en mesure de savoir et comprendre ce qui a permis les réussites et les ratés. Pour continuer de faire ce qui fonctionne bien, et améliorer continuellement ce qui fonctionne moins bien, entre autres.
Ces qualités (et d’autres) sont mises en avant par ce qu’on appelle maintenant les méthodes agiles. Ces méthodes sont nombreuses et variées, elles sont faites pour différents contextes et ne sont pas fondamentalement bonnes. Si tu souhaites en savoir plus, il faut aller voir les différentes options qui existent: Scrum, XP, Lean, TDD, etc..., il y en a des dizaines, et rien ne t’empêche d’ailleurs de créer la tienne.
Il faut lire sur chacune d’entre elles, pour trouver celle qui conviendra à ton contexte. Ensuite il faut l'essayer, et prendre le temps de s’y adapter, ça ne donne pas des résultats probants 15 minutes après la mise en place.
Contrairement à ce qu’on essaye souvent de nous vendre, ni "Agile" ni "Scrum" ne sont des solutions magiques pour faire du bon software.
Enfin, si tu gardes bien ces idées de base en tête, et que tu en comprends les principes, tu pourras appliquer l’approche à d’autres domaines que le logiciel.
Comment faire la différence entre l’Agilité et le "Marketing" ?
Bon eh bien là, il n’y a pas de secret, il faut d’abord que toi, tu comprennes un peu de quoi il s’agit. Normalement, maintenant c’est à peu près le cas, tu as les éléments de base pour comprendre l’idée portée par ce mouvement.
Pour arriver à faire la différence entre une promesse d’agilité et une vraie organisation flexible, il faut poser des questions aux personnes qui te “vendent” leur agilité, ou directement à l’équipe, et voir s’ils ont eu une réflexion poussée lors de la mise en place de l’agilité dans leur processus interne.
La question qui permet d’identifier très vite le bluff dans une entreprise, c’est simplement de demander leur définition de l’agilité, et de demander de décrire leur processus agile.
C'est un grand classique !
Je ne résiste pas à te partager un petit bout de vécu personnel. Il m’est arrivé de me retrouver dans un meeting de “transformation méthodologique” d’une entreprise, qui prenait le virage vers Scrum.
Jusque-là, la méthode "Waterfall" était bien en place, mais c’était long et fastidieux pour chaque nouveau client. En général avant d’arriver à la mise en production, il s’est écoulé des mois, voire des années, et ce qui est livré ne correspond plus au besoin du client qui a changé entre-temps. Bah oui, en fait si t’as besoin d’un truc et que ça prend 2 ans pour l’avoir, en général tu te débrouilles autrement entre temps.
L’entreprise a donc décidé de devenir "Scrum". La réunion de présentation du nouveau processus à durée environ 45 minutes, en mode "keynote #révolution".
Le nouveau processus a été présenté avec le même schéma qu’avant, mais avec une petite flèche en plus, qui va de la dernière étape, à la première. C’est LA flèche magique. BOUM ! Une révolution ! Le processus est devenu itératif !
Au final, notre mode de travail de tous les jours n’a pas changé, la productivité et la pertinence des releases non plus.
Si tu as vaguement compris ce que j’ai écrit dans cet article, et/ou que tu connais au moins vaguement Scrum, c’est flagrant que ce type de "changement" n’apporte pas de flexibilité, mais plus un avantage marketing pour l’entreprise (et encore...).
Ça y est, ils sont Agile, ou Scrum, ou les deux tiens !
De toute manière, qui fait la différence ?
Et ça fait bien, sur les offres d’emploi, mais aussi pour vendre aux clients, même si en arrière, la philosophie de l’agilité est quasi inexistante.
Conclusion
Pour terminer, je voulais vraiment insister sur le fait qu’autour de l’agilité, quand on souhaite le faire avec sérieux, on cherche à mettre en place une philosophie de travail au sein d’une équipe, ou même d’une entreprise. Et on peut l’appliquer à autre chose que juste le logiciel, à partir du moment où on le fait avec intelligence.
C’est un travail qui peut être long et compliqué, mais qui en vaut la peine pour peu qu’on s’y intéresse avec sincérité. C’est d’ailleurs ce que je fais, et c’est une des raisons pour lesquelles je suis en freelance maintenant. Je veux mettre l’emphase sur un partage des connaissances et des compétences, au bénéfice de tous. Donc si jamais tu as besoin d’aide ou de conseils, n’hésite pas à me contacter !
J'espère dans ce premier article avoir pu te donner ne serait-ce qu’une vague idée de ce que sont l’agilité et les méthodes agiles, ou au moins t’avoir donné le minimum pour voir quand quelque chose ne l’est pas.
Mon but avec cet article et les suivants c’est de rendre plus accessible certains jargons sur-utilisés dans les différents médias. De me pencher un peu plus sur ce que ça veut dire vraiment, et montrer aussi que comme souvent, les choses ne sont pas si simples qu’elles peuvent paraître.
Et j’ai une belle liste de sujets à creuser en tête !
N’hésite pas à m’écrire pour réagir sur ce sujet, me donner tes impressions sur l’article, ou même pour me suggérer des sujets pour les prochains articles. Je suis toujours ravi de pouvoir échanger avec d’autres personnes, d’autres horizons, c’est une super manière d’apprendre de nouvelles choses, et j’adore ça apprendre des choses !