Méthode agile : le guide du fondateur qui paie

Ce que « on travaille en agile » vous achète vraiment, ce que cela vous demande en retour, et comment repérer quand ce n’est que du théâtre.

À la troisième réunion avec l’entreprise qui allait construire le produit, le fondateur a entendu la phrase qu’il entendrait cinquante fois encore : « nous travaillons avec une méthode agile ». Il a acquiescé. Tout le monde acquiesce. Ça sonne comme un gage de sérieux, comme dire que la cuisine est propre. Le problème, c’est qu’il n’avait aucune idée de ce qu’il approuvait. L’agile changeait-il le prix ? Le délai ? Ce qu’il pourrait exiger quand quelque chose tournerait mal ? Personne n’a expliqué, parce que presque tout ce qui s’écrit sur le sujet s’adresse à celles et ceux qui siègent dans l’équipe de développement, pas à la personne qui signe les chèques.

La méthode agile est une façon de construire du logiciel par cycles courts, en livrant des morceaux qui fonctionnent toutes les quelques semaines au lieu de disparaître pendant six mois et de réapparaître avec un produit entier. Plutôt que de figer tout le périmètre au départ et de suivre un plan rigide jusqu’au bout, l’équipe priorise une liste de tâches, construit d’abord les plus importantes, montre le résultat, écoute le retour et corrige la trajectoire. C’est l’inverse du modèle « cascade », où chaque étape ne commence qu’une fois la précédente terminée. Voilà la définition de dictionnaire. Elle est exacte et à peu près inutile pour vous. Ce qui compte, ce n’est pas ce qu’est l’agile. C’est ce que l’agile fait à votre argent, à votre risque et à votre temps.

Ce que la méthode agile vous achète vraiment

Retirez le mot « agile » de la phrase et regardez ce qui reste. Trois choses concrètes changent de mains quand une équipe travaille ainsi, et les trois sont des avantages pour celui qui paie.

La première, c’est la visibilité. Dans un modèle cascade, vous remettez un cahier des charges, vous serrez la main et vous attendez. La première fois que vous voyez du vrai logiciel, c’est bien plus loin, quand vous avez déjà dépensé l’essentiel du budget et que changer d’avis coûte cher. En agile, vous voyez quelque chose qui fonctionne toutes les deux ou trois semaines. Pas une diapositive, pas une belle maquette : le vrai produit, en marche, sur lequel vous pouvez cliquer. Cela transforme votre partenaire technique en boîte de verre au lieu d’une boîte noire, ce qui est exactement comme ça devrait être.

La deuxième, c’est le droit de changer d’avis sans sanction. Vous êtes fondateur. Vous découvrirez en semaine quatre que la fonctionnalité qui semblait essentielle en semaine zéro n’a pas d’importance, et qu’autre chose en a beaucoup. Dans un contrat à périmètre figé, chacun de ces changements devient une négociation, un avenant, une bagarre. En agile, repositionner les priorités du prochain lot de travail est le fonctionnement normal du système, pas une exception. Vous n’achetez pas un produit prédéfini. Vous achetez la capacité de décider du produit pendant qu’il naît.

La troisième, ce sont de petits paris au lieu d’un pari géant. Chaque cycle est une somme limitée misée sur une part limitée de produit. Si la direction est mauvaise, vous le découvrez après avoir dépensé l’équivalent de deux semaines, pas de six mois. L’agile ne supprime pas le risque de construire la mauvaise chose. Il découpe ce risque en morceaux assez petits pour que vous surviviez à vous tromper.

Si votre partenaire parle de méthode agile et qu’aucune de ces trois choses n’apparaît en pratique, vous ne recevez pas de l’agile. Vous recevez le mot.

Les quatre valeurs, traduites pour celui qui signe le chèque

Tout l’agile vient d’un texte de dix-sept lignes écrit en 2001, le Manifeste Agile. Il compte quatre valeurs. Vous verrez des gens réciter les quatre comme une écriture sainte. Il vaut la peine de comprendre ce que chacune signifie quand c’est votre argent qui est en jeu.

Les individus et leurs interactions plus que les processus et les outils. Pour vous, cela veut dire que la qualité de vos conversations avec ceux qui construisent compte plus que n’importe quel logiciel de gestion coloré. Une équipe qui répond à vos questions en langage clair vaut mieux qu’un tableau Jira impeccable que personne n’ouvre.

Du logiciel qui fonctionne plus qu’une documentation exhaustive. La preuve que le travail avance, c’est du logiciel qui tourne, pas un rapport d’avancement. Si chaque semaine vous recevez une présentation de progression et jamais un lien sur lequel cliquer, méfiez-vous.

La collaboration avec le client plus que la négociation de contrat. Voilà la valeur qui vous protège le plus et vous demande le plus. Elle dit que le bon partenaire règle les problèmes à vos côtés au lieu de vous renvoyer aux clauses du contrat. En échange, elle attend que vous soyez présent, pas absent puis de retour à la fin.

L’adaptation au changement plus que le suivi d’un plan. Un plan est une supposition faite le jour où vous en saviez moins sur le produit que maintenant. L’agile traite le plan comme un brouillon, pas comme une promesse. C’est libérateur, et c’est aussi la source de la plus grande confusion que j’aborderai dans un instant : agile n’est pas synonyme de « sans délai et sans budget ».

Remarquez que les trois piliers qui soutiennent la méthode, transparence, inspection et adaptation, ne sont que ces valeurs dites autrement. Vous montrez le travail, vous le regardez avec honnêteté, et vous corrigez. C’est simple. C’est difficile à bien faire justement parce que c’est simple.

Les méthodes que vous croiserez en pratique

« Méthode agile » est un parapluie. En dessous vivent quelques méthodes précises, et vous en croiserez deux.

Scrum est de loin la plus répandue. Elle organise le travail en sprints, des cycles de deux ou trois semaines au début et à la fin définis, en puisant des tâches dans une liste priorisée appelée backlog. À la fin de chaque sprint, il y a une réunion de revue où l’équipe montre ce qui est prêt. Cette réunion est la vôtre. C’est le moment où vous, le fondateur, voyez le produit et décidez de ce qui vient ensuite.

Kanban est plus fluide. Au lieu de cycles fermés, le travail circule sur un tableau continu de colonnes (« à faire », « en cours », « fait »), et l’équipe tire la tâche suivante quand elle termine la précédente. Cela convient généralement mieux à des produits déjà en ligne, avec un flux constant d’ajustements et de correctifs, qu’à une construction partie de zéro.

Il y en a une poignée d’autres, comme l’Extreme Programming, mais vous n’avez pas à mémoriser la liste. Vous avez besoin d’une seule chose : quelle que soit la méthode, elle doit produire du logiciel qui fonctionne à intervalles courts et réguliers, et elle doit vous donner un lieu récurrent pour regarder ce logiciel et décider. Si la méthode choisie ne livre pas cela, son nom n’a pas d’importance.

L’agile n’est pas le contraire d’un délai

Ici vit le malentendu qui coûte le plus cher. Un fondateur non technique entend « agile » et comprend « sans délai, sans prix fixe, on verra au fur et à mesure ». Il prend peur, à raison, de signer un chèque en blanc. Mais ce n’est pas l’offre.

Ce que l’agile refuse, c’est de faire semblant qu’on peut prédire, dès le premier jour, exactement quelles fonctionnalités existeront et dans quel ordre, six mois plus tard. Cette prédiction a toujours été une fiction ; la cascade cachait seulement mieux la fiction. Ce que l’agile vous offre à la place, c’est autre chose : de la prévisibilité de rythme et de dépense. Vous savez ce que coûte un cycle. Vous savez à quelle fréquence vous verrez des résultats. Vous contrôlez ce qui entre dans chaque cycle. Ce qui reste flexible, c’est le périmètre au bout, pas l’argent ni la cadence.

En pratique, cela signifie que vous pouvez et devez avoir un budget et une date pour le premier lancement à vraie valeur. Ce que vous cédez, c’est le droit d’exiger une liste de fonctionnalités gravée dans le marbre. C’est un bon échange pour celui qui paie, à condition qu’il soit compris. La plupart des disputes entre un fondateur et un partenaire naissent de ce que ni l’un ni l’autre n’a jamais convenu, à voix haute, de ce qui était fixe et de ce qui était flexible. Il vaut la peine de lire aussi comment le scope creep s’installe précisément dans cette faille.

Comment repérer quand ce n’est que du théâtre

Le faux agile est facile à vendre et difficile à détecter de l’extérieur, parce qu’il emploie les mêmes mots que le vrai. Vous n’avez pas besoin de comprendre le code pour flairer la fraude. Vous avez besoin d’observer quatre choses, et les quatre sont visibles pour quelqu’un qui n’est pas technique.

D’abord : à la fin de chaque cycle, y a-t-il du logiciel sur lequel vous pouvez cliquer ? Si chaque « sprint » se termine par un rapport et jamais par un écran qui fonctionne, ce n’est pas de l’agile. C’est de la cascade au vocabulaire emprunté.

Ensuite : voyez-vous la liste des priorités, et pouvez-vous y toucher ? Si le backlog est un endroit secret que seule l’équipe manipule et sur l’ordre duquel vous ne pesez jamais, vous avez perdu le bénéfice principal. La liste des priorités, c’est le volant. S’il n’est jamais entre vos mains, vous êtes passager de votre propre produit.

Puis : les réunions produisent-elles des décisions ou juste un état d’avancement ? Une cérémonie agile qui existe pour signaler que « tout est dans les temps » et jamais pour décider de ce qui change est du théâtre. La revue de fin de cycle doit se terminer par vous et l’équipe choisissant ce qui vient ensuite.

Enfin : quand vous changez d’avis, l’équipe le traite-t-elle comme un travail normal ou comme une crise contractuelle ? La réaction à un changement de priorité est le test le plus honnête qui soit. Un partenaire qui fait du vrai agile replanifie le cycle suivant sans drame. Un partenaire qui fait semblant sort le contrat.

Si trois de ces quatre réponses sont mauvaises, l’étiquette « méthode agile » sur la proposition est de la décoration. Nous l’avons vu des deux côtés de la table, et le schéma est toujours le même : les mots arrivent avant les pratiques, et parfois ils arrivent seuls.

Ce que l’agile vous demande en retour

Rien de tout cela n’est gratuit, et la facture se règle en temps. Le modèle cascade vous demande peu après la signature : vous briefez, vous disparaissez, vous vous plaignez à la fin. L’agile inverse cela. Il vous donne du contrôle et de la visibilité, et il vous les facture en présence.

La présence veut dire des choses précises. Venir à la revue de chaque cycle. Répondre aux questions de l’équipe en jours, pas en semaines, parce qu’une question à l’arrêt gèle la décision suivante. Garder la liste des priorités vraiment vôtre, au lieu de la déléguer puis d’être surpris par ce qui a été construit. Être la personne qui décide, quand la décision relève du produit et du business, là où vous êtes irremplaçable et où l’équipe ne peut pas vous couvrir.

Un fondateur qui veut les bénéfices de l’agile sans payer cette facture de présence se retrouve avec le pire des deux mondes : une méthode qui présuppose un propriétaire impliqué, menée comme si le propriétaire n’existait pas. Le résultat est un produit qui s’éloigne de ce dont le business a besoin, un lot de travail à la fois. Si vous n’avez aucune disponibilité pour vous impliquer, soyez honnête là-dessus au moment de choisir le format de travail, car alors un périmètre plus figé, malgré ses inconvénients, servira peut-être mieux votre réalité.

La méthode agile, au fond, est un pari sur le fait que la personne qui comprend le business, vous, sera là pour guider la construction pendant qu’elle se fait. Quand ce pari est vrai, c’est la façon la plus sûre qui soit pour un fondateur non technique de construire du logiciel sans remettre les clés et prier. Bien menée, elle réduit la distance entre ce que vous imaginiez et ce qui a été construit, une correction à la fois. C’est du travail, du début à la fin. Mais c’est votre produit, et le volant reste entre vos mains.

Questions fréquentes sur la méthode agile

Qu’est-ce que la méthode agile, en une phrase ?
C’est une façon de construire du logiciel par cycles courts, en livrant des parties qui fonctionnent toutes les quelques semaines et en corrigeant la trajectoire selon ce que l’on apprend, au lieu de figer tout le périmètre au départ et de suivre un plan rigide jusqu’au bout.

Quelles sont les quatre valeurs du Manifeste Agile ?
Les individus et leurs interactions plus que les processus et les outils ; du logiciel qui fonctionne plus qu’une documentation exhaustive ; la collaboration avec le client plus que la négociation de contrat ; et l’adaptation au changement plus que le suivi d’un plan. Cela ne veut pas dire abandonner le second élément de chaque paire, mais valoriser davantage le premier.

Quels sont les trois piliers de l’agile ?
Transparence, inspection et adaptation. En clair : montrez le vrai travail, regardez-le avec honnêteté et corrigez la trajectoire. Les trois s’appliquent autant à vous, du côté qui paie, qu’à l’équipe.

Quelles sont les principales méthodes agiles ?
Scrum (travail organisé en sprints à partir d’une liste priorisée) et Kanban (flux continu sur un tableau de colonnes) sont les deux que vous croiserez. Il y en a d’autres, comme l’Extreme Programming, mais c’est le principe commun qui compte : du logiciel qui fonctionne à intervalles courts et un lieu récurrent où vous décidez de ce qui vient ensuite.

La méthode agile signifie-t-elle aucun délai et aucun budget ?
Non. L’agile vous donne de la prévisibilité de rythme et de dépense ; vous connaissez le coût et la fréquence de chaque cycle. Ce qui reste flexible, c’est la liste exacte des fonctionnalités au bout, pas l’argent ni la cadence. Vous pouvez avoir un budget et une date de lancement et être quand même agile.

Agile ou cascade : quel est le meilleur choix quand on fait appel à une équipe externe ?
Pour la plupart des fondateurs non techniques qui externalisent la construction, l’agile est plus sûr, car il échange un gros pari aveugle contre de nombreux petits paris visibles. L’exception, c’est quand vous n’avez aucune disponibilité pour rester impliqué : l’agile présuppose un propriétaire présent, et sans cela, un périmètre plus figé peut mieux vous servir.