J’ai pu remarquer que le Agile Manifesto était difficile d’accès lorsqu’une amie, excellente ingénieure senior en France, m’a demandé de lui expliquer le principe. Je l’ai alors pointée vers le site et elle est revenue avec… les mêmes questions.

Le site Agile Manifesto n’est pas parlant:

• Le site est démodé,
• Les Français sont réticents à propos du choc culturel pour appliquer des méthodes américaines,
• Il laisse plein de questions en suspens: Comment utiliser Agile dans des projets au forfait? Comment utiliser Agile pour un projet industriel? Comment rédiger un appel aux marchés publics en Agile?

La sentence est terrible: C’est seulement maintenant que l’Agile pénètre en France, treize ans après les pays anglo-saxons. Sur le terrain, en 2014, les SSII qui sensibilisent leurs clients pullulent en 2014. Mais Google Trends indique que d’autres pays sont beaucoup plus intéressés:

Google Trends pour “Agile”: Les premiers pays sont l’Inde, l’Argentine, le Brésil.

Il est donc temps d’étoffer la traduction en Français du Manifeste Agile.

Que dit le Manifeste Agile?

Vous serez étonnés : Il ne dit pas grand chose. Il pose les bases. Il rappelle ce qui est important. Il rappelle le bon sens, dans un pragmatisme très anglo-saxon. Voici les quatre principes fondateurs:

• Des individus et leurs interactions, plus que les processus et les outils;
• Des logiciels opérationnels, plus qu’une documentation exhaustive;
• La collaboration avec les clients, plus que la négociation contractuelle;
• L’adaptation au changement, plus que le suivi d’un plan.

Ces quatre principes s’étendent en 12 points de haut niveau.

Notez que l’Agile lui-même n’est pas une gestion de projet, c’est Scrum qui en est une. Cependant on retrouve des thèmes systématiques dans les méthodes Agile. Voyons-en quelques-uns.

Complexité et taille des lots

La complexité est toujours maximale dans l’informatique. Là où la biologie consiste à étudier l’existant, l’informatique est une science construite de toutes pièces. Or le seul frein est la limite de l’intelligence des programmeurs eux-mêmes. Donc les programmes informatiques vont toujours aux limites de l’entendement.

Plusieurs attitudes sont apparues pour dompter cette complexité. Certains écrivent des spécifications jusque dans les moindres détails, et l’on se retrouve à dupliquer la complexité du programme sous forme de spécifications. L’Agile a pris le parti opposé: Avouer qu’on ne peut pas tout maîtriser. Pour eux, un logiciel qui marche vaut mieux qu’une documentation exhaustive.

Et pour tuer la complexité, le principe de réduction de la taille des lots revient souvent en Agile:

• Eviter de contractualiser les spécifications pour éviter de saturer des tuyaux administratifs. Les exigences sont passées directement de l’utilisateur final au développeur, notamment par communication orale, et le contrat se concentre sur d’autres critères. Plusieurs sites, dont Wikipedia [1], l’expliquent.
• Le “continuous delivery”  Chaque changement est livré dans l’après-midi en production. Plus d’informations sur Wikipedia [2]. Il n’existe plus de numéro de version ou de saison de test: Tout est streamliné. Ce qui nous amène au point suivant…
• Le Kanban. On interdit au développeur d’avoir plus de 2 développements en cours. S’il a deux développements en test, il se met en standby et ne commence pas un troisième développement. L’objectif n’est pas de maximiser sa production, l’objectif est de minimiser le temps total de traitement de chaque dossier. On réduit l’impression de longueur entre l’inception de l’idée et sa disponibilité en prod. Voir l’article “Le compte des immobilisations de code” [3] de Joel on Software.
• Les “sprints” (itérations) de quatre, deux ou une semaine, qui ne sont réussis que si le travail a pu être mis en prod.

La complexité diminue exponentionnellement suivant la taille des lots. Chaque module qui attend de passer en production est un risque: Est-il vraiment terminé? Passera-t-il en production? Sera-t-il toujours à jour quand il passera en production? Faut-il déjà corriger ses bugs? Quelle est notre spéculation du développement suivant le plus nécessaire ? Dès qu’il passe en production, le risque disparaît: Il agit comme une baseline, une certitude. On peut mesurer l’expérience utilisateur sans spéculer, et ainsi mieux décider quelle est la bonne prochaine étape pour la roadmap.

• [1] voir Agile Contracts sur Wikipedia
• [2] voir Continuous Delivery sur Wikipedia
• [3] Le compte des immobilisations de code de Joel on Software

La vélocité

Il faut trouver la juste place pour la documentation. Mal faite, elle peut agir comme une interruption et diluer la tâche du programmeur dans un bain de cahier des charges. Absente, elle laisse de l’information se perdre.

Le même syndrome arrive lorsque le développeur veut ajouter une librairie ou veut choisir son outil de travail. Est-ce qu’il demande l’autorisation ? Combien de temps ça lui prend ?

Il y a un effet boule de neige à augmenter la vélocité d’un travailleur. L’informatique est un travail intellectuel. Pour être performant, le développeur charge toutes les branches de ses algorithmes en tête, conceptualise une solution et l’implémente. C’est excitant pour lui. A chaque interruption, sa réflexion se volatilise, ensemble avec son excitation. Il suffit de quelques heures à pointer des estimations dans Excel, ou une machine de travail un peu lente, pour que toute l’excitation soit dissolue.

Les occasions de dilluer le travail effectif avec des procédures et de mauvais outils sont nombreuses et justifiables. Mais il ne faut pas seulement regarder le coût immédiat. C’est tout l’élan de l’équipe qui prend un coup et l’on réduit ses ambitions.

La délégation

La confiance. On ne décide pas en un jour de faire de l’Agile, car la confiance est un cercle vertueux. Qu’est-ce qui certifie qu’avec le même nombre de ressources et une méthode moins micro-management, vous obtiendrez le bon résultat? Avec une méthode “waterfall”, vous barricadiez le projet de jalons, de garanties, pour vous approcher de la certitude maximale. Avec l’Agile, vous devez quitter le micro-management. Pour avoir confiance dans vos équipes, il faut donc développer une culture de l’excellence où vous avez du respect pour l’expertise de chacun. Chaque employé doit avoir l’envie d’être autonome et fiable.

A Atlassian, l’une des valeurs était “Be the change you seek”. Cette petite phrase nous rappelle, au moment où un détail nous titille, que nous avons le pouvoir de changer notre environnement en étant porteur d’initiatives. La culture entière encourageait le développeur à dégager un petit temps libre pour s’attaquer à ce genre de maintenance. Au final, vous pouvez mettre autant de management que vous souhaitez, mais le code qui va en production vient de la main du développeur: Autant le responsabiliser.

Les questions fréquentes

• “Peut-on utiliser Agile pour un lancement de fusée ?” Non, l’Agile consiste à faire de l’amélioration continue, il est donc faiblement adapté pour l’industriel. Le résultat n’est pas déterministe. C’est particulièrement adapté à l’informatique, secteur économique où les attentes des clients évoluent constamment.
• “L’Agile ne s’applique pas en France parce qu’on ne peut pas licencier un développeur qui n’est pas motivé.” Exact! Mais j’ai vu bien des environnements déterministes où la motivation des employés était le facteur d’échec numéro 1. Quelle que soit votre situation, pour passer au niveau de maturité suivant, vous devrez donner de l’amour-propre aux employés et investir sur eux. Si vous avez peur de former vos employés parce qu’ils partent tous, vous avez un sérieux problème de rétention.
• “Je fais des projets au forfait. L’Agile ne s’applique pas à ce cadre.” Voulez-vous dire que votre marge correspond au nombre de jours vendus qui n’étaient pas nécessaires ? Vous n’êtes pas forcément incités sur le bon critère. Le forfait a divers coûts: Le temps pour le client d’écrire les spécifications, pour la SSII de comprendre l’impact et de chiffrer, le temps pour le développeur de décortiquer les règles de gestion et le temps pour les avocats de vérifier les responsabilités dans les pénalités de retard… et le coût le plus énorme: la livraison d’un logiciel conforme aux spécifications mais inadapté au besoin réel. C’est exact, si vous faites des projets au forfait, il y a de fortes chances pour que le résultat soit cher et inadapté. Ce que vous pouvez vendre au client dans ce cas, c’est du conseil sur les méthodes Agile.
• “Comment rédiger un appel aux marchés publics?” C’est simple: Spécifier le contexte, les technologies, le niveau d’expertise attendu du fournisseur, et ne contractualiser que le nombre d’unités d’oeuvre à livrer.
• “L’Agile consiste à stresser quotidiennement le développeur” Non. Dans tout système, le développeur a des tâches quotidiennes à réaliser. L’Agile consiste à lui donner une autonomie, une fierté, à appliquer du bon sens pour répondre au mieux au besoin du client, et à lui donner environnement où il upgrade ses connaissances régulièrement.
• “Demain, nous démarrons avec une méthode Agile.” Il y a plusieurs niveaux de maturité. Lorsque le PDG accepte de ne pas avoir de roadmap pour sur les six prochains mois, qu’il fait confiance à la production de son équipe parce qu’il a garanti un certain nombre de jours travaillés, s’il a mis en place une objectivisation du middle-management basée sur l’efficience de leur production, alors vous pouvez prétendre “faire de l’Agile”.
• “Je crée une start-up. Comment commencer en Agile ?” On parlera plutôt de Lean Start-up. Ce sont les mêmes principes, appliqués à l’acquisition de clients. Notamment le mouvement Lean Start-up insiste pour vendre la solution avant de l’avoir créée, afin d’augmenter la boucle de feedback entre le besoin et la réponse.

En conclusion

Les rétrospectives jouent un rôle central. L’adaptation constante aux besoins du marché est une raison d’être de l’Agile. Plus que mettre en place des méthodes, il faut insister pour les renouveler constamment. C’est donc difficile de dire quelles sont les règles à appliquer dans votre entreprise: Elles seront définies et adaptées au fur-et-à-mesure qu’elles seront pertinentes ou obsolètes.