Comment j’ai appris à introduire le Manifeste Agile

Le Manifeste Agile, considéré comme un texte saint pour certains, est souvent évoqué (si ce n’est tout le temps) dans les formations Agile du marché. A force d’échanger au sein de la communauté, je me suis rendu compte que nous n’avions pas la même façon de l’aborder, ni de le présenter lors de nos formations.

C’est pourquoi je me suis dit que j’allais expliquer la manière dont j’ai appris à le faire jusqu’ici.

Un peu d’histoire

L’histoire du Manifeste Agile, c’est ce lien sur http://agilemanifesto.org/ que semble t’il peu de personnes ont eu la curiosité de parcourir, et pourtant ce qui y est raconté est passionnant ! Une traduction française est d’ailleurs disponible grâce à Fabrice Aimetti.

On sait que 17 experts du développement logiciel se sont réunis du 11 au 13 Février 2001 à Snowbird, Utah, et ont abouti à l’élaboration de ce que l’on appelle aujourd’hui fièrement le « Manifeste Agile ». Mais comment leur est venue cette idée de rencontre ?

Pourquoi ils se sont réunis

L’idée de la réunion est née suite à une précédente rencontre organisée par Kent Beck entre les promoteurs de l’eXtreme Programming et quelques « outsiders » où les participants ont exprimé leur soutien pour un ensemble de méthodes dites « légères » sans que rien de concret n’en sorte vraiment. Le terme « léger » était utilisé en opposition aux approches « lourdes » de développement logiciel pilotées par la documentation.

En Septembre 2000, Bob Martin envoya un email pour proposer « une petite conférence (de deux jours) (…) ici à Chicago » permettant de réunir tous les leaders de ces méthodes « légères » dans la même pièce.

L’idée derrière le Manifeste Agile

D’après Jim Highsmith, fondamentalement, les Agilistes veulent livrer de bons produits à leurs clients en opérant dans un environnement qui fait plus que dire que les « personnes sont leur plus grande ressource » mais qui agit réellement comme si les gens étaient les plus importants, en oubliant le terme « ressource ».

Donc en effet, la plupart des débats autour de l’agilité tournent autour de ces sujets – considérés à l’eau de rose par certains – de valeurs et de culture. Ainsi, même si le Manifeste Agile fournit quelques idées spécifiques, l’important est de redonner de la valeur à l’humain en le plaçant au coeur de nos stratégies (professionnelles et personnelles) et en repensant nos manières d’être et de faire en conséquence.

Quelques anecdotes

• Martin Fowler (un anglais) souleva le problème que la plupart des Américains ne savaient pas prononcer le mot « agile ».
• Personne ne pensait initialement que ce groupe d’anarchistes organisationnels tomberait d’accord sur quoi que ce soit de substantiel.
• Le débat le plus féroce ayant éclaté fut à propos du choix du lieu : trop froid, trop chaud, trop loin, rien d’intéressant à faire…

Comment je décris le Manifeste Agile

Le Manifeste Agile est un texte composé de 4 parties distinctes:

• 2 phrases d’introduction
• les 4 valeurs Agile
• 2 phrases de clôture
• un listing des auteurs

Je ne présente pas toujours ces parties dans l’ordre chronologique. Très rarement en fait.

J’utilise généralement cet ordre ci :

Les phrases d’introduction

Nous découvrons comment mieux développer des logiciels par la pratique et en aidant les autres à le faire. Ces expériences nous ont amené à valoriser :

De manière générale, j’invite les participants à identifier les éléments qui leur paraissent importants, base sur laquelle les échanges vont s’appuyer.

• « Nous découvrons… »

Je ne m’étais jamais attardé sur cette partie auparavant mais un jour un participant m’a dit:

« L’utilisation du verbe découvrir au présent peut induire l’idée que nous ne restons pas sur la base de ce qui a déjà été trouvé, et que l’on continue encore aujourd’hui à découvrir de nouvelles choses. »

Lorsque l’on dit que l’agilité n’est pas une fin en soi mais plutôt un voyage vers l’amélioration continue, je trouve que l’on retrouve bien cette idée à cet endroit. J’ai souvent entendu que l’on apprenait autant voire même plus que les participants en animant des formations, en voici un exemple flagrant, alors j’ai gardé ! :-p

• « …des logiciels… »

N’oublions pas qu’initialement, les 17 personnes qui se sont réunies sont des représentants de méthodes de développement logiciel.

Cependant, j’ai tendance à ajouter le fait que le Manifeste serait tout aussi juste voire même plus en remplaçant le terme « logiciel » par « produit » comme le disait Alistair Cockburn en Keynote du ScrumDay 2014 à Paris.

• « …par la pratique… »

En traduction littérale de l’anglais, « …en le faisant… », j’évoque ici la caractéristique empirique de l’approche Agile en opposition à la caractéristique prédictive de l’approche Traditionnelle. En effet, c’est par l’expérience que l’on apprend concrètement (et que l’on continue à apprendre) dans une optique d’amélioration continue.

• « …en aidant les autres à le faire. »

Je parle ici de la communauté Agile qui a pour vocation de partager les bonnes pratiques et de les diffuser au plus grand nombre. En effet, chacun est susceptible de découvrir quelque chose de nouveau, de remettre en question des concepts peut-être devenus obsolètes, maintenant l’important est de ne pas le garder pour soi et la communauté Agile est un bon endroit pour partager ! 🙂

Les phrases de clôture

Nous reconnaissons la valeur des seconds éléments, mais privilégions les premiers.

Je décris souvent cette partie à ce moment là pour préparer le terrain. En effet, cela permet d’expliquer la structure utilisée par les 4 valeurs Agile comparant des éléments (littéralement) à gauche et à droite.

J’insiste alors sur le fait que cette comparaison n’est pas une opposition stricte. On ne parle pas d’opposition Bien / Mal mais plutôt d’une opposition Mieux / Bien. En effet, on reconnaît la valeur des seconds éléments, mais on souhaite tendre vers les premiers le plus souvent possible. Dit autrement, c’est une question de curseur.

Les 4 valeurs Agile

Les individus et leurs interactions plus que les processus et les outils

Les organisations sont constituées d’individus qui produisent de la valeur en vue de répondre à la stratégie d’entreprise. La plupart du temps même ils ne la produisent pas seuls mais en équipe, ce qui rend l’importance de leurs interactions d’autant plus grande.

J’ai tendance à injecter cet adage à ce moment là :

« L’ensemble est plus grand que la somme des parties. »

Je l’explique en disant qu’en effet, ce qui fait qu’une organisation est plus grande que la somme de ses individus est que l’on y ajoute la somme de toutes les interactions qui y opèrent. C’est ainsi en prenant soin de ces interactions que l’on aura une meilleure maîtrise de la valeur que l’on souhaite produire.

Maintenant, les processus et les outils ne sont pas non plus à supprimer. Je ne connais pas beaucoup d’entreprises (voire pas du tout) qui fonctionnerait sans processus ou sans outil et il y a bien une raison pour cela : l’évolution du monde et de la technologie est tellement rapide qu’il est difficile de gérer la complexité engendrée. Cependant, n’oublions pas que les outils n’ont pas d’utilité en soi, sauf lorsqu’ils agissent en support. Ainsi, des processus et des outils adéquats peuvent aider les individus à mieux gérer leurs interactions.

Dans le cas contraire, les individus sont alors assujettis à leurs outils, ce qui à tendance à plutôt diminuer leur capacité à interagir entre eux. Refrain connu ? :-p

Des logiciels opérationnels plus qu’une documentation exhaustive

La première remarque que j’effectue est de l’ordre de la traduction. En effet, la version anglais parle de « comprehensive documentation » qui se traduit effectivement par « documentation exhaustive » en français. Attention au faux ami et donc à une éventuelle incompréhension ou mauvaise interprétation.

L’idée derrière cette valeur est que l’on privilégie avoir un logiciel qui fonctionne concrètement devant soi plutôt que d’avoir une documentation nous expliquant très précisément comment il devrait fonctionner.

Je fais souvent le parallèle avec les indicateurs d’avancement, un des principes sous-jacents au Manifeste Agile d’ailleurs. Je raconte l’histoire d’un projet dans lequel j’avais travaillé où j’avais établi 2 indicateurs d’avancement pour mes supérieurs hiérarchiques : un indicateur d’avancement réel et un indicateur d’avancement théorique. Le premier correspondait à l’avancement du logiciel concrètement terminé (donc également testé) alors que le second prenait également en compte les tâches en cours.

Dans le premier cas, on a un avancement réel sur lequel on peut communiquer sans surprise alors que dans le second on risque d’avoir l’effet du graphe qui va rapidement de 0 à 50% puis moins vite de 50 à 90% et qui a un mal fou pour faire avancer les 10 % de fin !

Maintenant, cela ne signifie pas que la documentation est inutile et qu’on la supprime entièrement, elle n’est juste plus utilisée de la même façon. Je parlerais de la documentation Agile dans un prochain article 😉

La collaboration avec les clients plus que la négociation contractuelle

L’idée principale que je transmets pour cette valeur est le changement de relation avec les clients. En effet, on cherche ici à remplacer la vieille relation client-fournisseur par un véritable partenariat, dans une relation win-win où chacun s’y retrouverait.

Cette approche semble plutôt logique lorsque l’on voit la précision avec laquelle les clients expriment leurs besoins. Ce n’est même pas forcément de leur faute, mais le besoin même précis à un moment tend à changer avec le temps. C’est là que la collaboration client entre en jeu et que la relation de confiance se crée. Outre la partie expertise qui réside chez le partenaire fournisseur, ce qui transparaît est la volonté d’apporter la meilleure solution au meilleur moment pour le client et donc de lui permettre de nourrir son avantage concurrentiel.

Maintenant, tout ceci ne peut se faire sans contrat, il faut bien évidemment définir un cadre dans lequel les 2 parties pourront évoluer. Cependant, ce ne sont plus les mêmes qu’auparavant – qui ne servaient qu’à se protéger mutuellement l’un de l’autre – mais bien au contraire, ils offrent de nouvelles perspectives de collaboration !

L’adaptation au changement plus que le suivi d’un plan

Une petite citation pour commencer :

« Dans la préparation à la bataille j’ai toujours constaté que les plans étaient inutiles, mais la planification est indispensable. » – Général D. Eisenhower

J’aime bien cette citation car elle me permet d’enchaîner en disant :

« En Agile, ce n’est pas que l’on n’aime pas planifier, bien au contraire, on planifie de planifier ! » 🙂

J’explique alors qu’aujourd’hui le changement est quelque chose d’inévitable, voire même nécessaire, ce qui fait que nous avons le choix de la perspective que nous lui donnons. En Agile, le changement est considéré comme une opportunité : une opportunité pour le client de garder un avantage concurrentiel, une opportunité pour le fournisseur de fournir la meilleure solution au bon moment.

Je parle alors de la tournure que prennent généralement les projets en approche traditionnelle en dessinant ce schéma :

Lorsque tout va bien, tout va bien. Par contre lorsque l’on commence à dévier du plan et bien on fait tout pour revenir sur le plan. Mais est-ce bien la bonne solution ? Le problème qui se pose le plus souvent est qu’à la fin d’un projet, le besoin ayant changé, le point B n’est plus la bonne destination !

Je dessine alors ce schéma :

On a une hypothèse et un plan de base mais parfois le point de départ peut évoluer, on replanifie alors à partir de ce point (A’) mais moins loin. Des changements arrivent en cours de route, et bien on les prend en compte et on replanifie pour voir où la destination serait la plus pertinente la prochaine fois. Ainsi de suite, ce qui nous permet de nous adapter sur le chemin à l’évolution du besoin, et surtout d’arriver au bon endroit au bon moment.

Ainsi, le plan en lui même n’a pas d’utilité si ce n’est de nous donner une direction pendant un certain temps. C’est l’activité de planification qui nous permet de voir où on en est, de voir où l’on veut aller, d’être réactif et de nous adapter à un environnement en perpétuelle évolution.

Je complète la description des valeurs en prenant un peu de recul et en expliquant que les éléments de droite peuvent être considérés comme des outils en support des éléments de gauche qui représentent les objectifs que l’on souhaite atteindre.

Puis, je pose la question suivante :

« A votre avis, si vous deviez choisir seulement UNE des valeurs du Manifeste Agile, quelle serait pour vous la plus importante ? »

Il y a souvent de tout dans les réponses ce qui rend les échanges intéressants sur les raisons du choix de chacun.

Puis, j’oriente le débat en pointant du doigt chaque valeur une à une de bas en haut :

• « De quoi ai-je besoin pour pouvoir m’adapter au changement ? »
• « De quoi ai-je besoin pour collaborer avec les clients ? »
• « De quoi ai-je besoin pour obtenir des logiciels opérationnels ? »

Si je ne me fais pas couper l’herbe sous le pied par les participants (ce qui arrive souvent à cette étape), je termine en disant :

• « Eh bien d’individus et de leurs interactions. N’oubliez pas que ce sont les personnes qui produisent de la valeur et que sans eux rien ne pourrait fonctionner. »

Parfois, j’invite même les participants à résumer le Manifeste Agile en un mot ce qui donne lieu à de nouveaux échanges et permet de voir la position de chacun vis à vis du sujet.

J’annonce ensuite le mot utilisé par Alistair Cockburn lors du ScrumDay 2014 à Paris :

P E O P L E

Le listing des auteurs

Je présente dans cette partie certains des auteurs, généralement ceux qui pourraient le plus parler à l’audience ou qui pourraient être liés à des sujets abordés plus tard tels que :

• Jeff Sutherland et Ken Schwaber: les 2 papas de Scrum
• Ward Cunningham: l’inventeur du concept du Wiki
• Martin Fowler: connu pour les design patterns, l’UML et le refactoring
• Kent Beck: l’inventeur d’eXtreme Programming

Voilà comment j’ai appris à présenter le Manifeste Agile jusqu’ici. Ce n’est en aucun cas LA façon de faire mais MA façon de faire aujourd’hui. Maintenant, je suis toujours preneur de bonnes idées pour faire évoluer mon approche sachant que je « continuerais à découvrir comment mieux faire, par la pratique, et en aidant les autres à le faire ». 🙂

Et vous, comment faites-vous ? 🙂

Note: J’ai limité l’article à la description des 4 valeurs fondamentales sans rentrer dans les détails des 12 principes sous-jacents.