Temps de lecture = 5 minutes

Après plus de 30 ans d’expérience dans le développement logiciel Agile et DevOps, dont 8 ans en tant que Coach Agile, Coach Kanban et Scrum Master, j’ai eu l’occasion de constater l’impact des valeurs agiles sur la réussite des projets.
Cet article regroupe une série de 4 posts dédiés à l’exploration approfondie de ces valeurs.
On commence avec l’adaptation au changement, une compétence essentielle pour naviguer dans un monde en constante évolution.

🧭 L’adaptation au changement plutôt que le suivi d’un plan.

📖 Anecdote
Je me souviens d’un projet de simulateur financier pour un client. Le cahier des charges initial prévoyait un outil qui regroupait les actifs de ses clients en 3 catégories (actions, obligations, monétaire), leur proposait une réallocation en fonction de leur profil d’investisseur… sans impacter le patrimoine à la sortie.
En tant que développeur, j’avais l’impression que le parcours était incomplet mais nous n’avions pas de contact avec le client en ces temps reculés. Une fois livré, les utilisateurs ont partagé le même sentiment. Nous étions tous d’accord sur le potentiel d’aller plus loin, mais les décisions avaient déjà été prises par d’autres personnes.
Si nous avions adopté une approche agile, les retours utilisateurs auraient rapidement fait remonter le besoin d’un produit plus complet. L’agilité aurait servi de sonnette d’alarme, signalant un produit inachevé aux yeux des utilisateurs.

En agilité, on accorde plus d’importance à l’adaptation au changement plutôt qu’au suivi rigide d’un plan préétabli.
Cela signifie que même si un plan initial est utile, notre priorité doit être de nous adapter aux nouvelles informations, aux retours des utilisateurs et aux évolutions du marché.

💡Concrètement, comment ça se traduit ?

1️⃣ En étant à l’écoute des besoins réels des utilisateurs, même s’ils diffèrent du cahier des charges initial.
2️⃣ En s’assurant que les décideurs participent aussi aux revues pour que l’information circule correctement.
3️⃣ En acceptant de modifier le plan en cours de route si cela permet de créer un meilleur produit.
4️⃣ En privilégiant l’expérimentation et l’apprentissage continu plutôt que de s’enfermer dans une approche figée.

Continuons sur une autre valeur clé…

🧭 La collaboration avec les clients plutôt que la négociation contractuelle

Une synergie entre équipes et parties prenantes est essentielle.
Mais quand cette collaboration est mal comprise, ça peut vite déraper.

📖 Anecdote
Nous avions remporté un appel d’offres avec une belle maquette et, fait rare, un contrat agile 🎉.
Tout semblait idéal… jusqu’à ce que la réalité nous rattrape :
🚨 4 mois de négociation pour un projet prévu en 3 mois.
🚨 Un forfait valeur… sans valeur définie.
🚨 Un Product Owner client désigné… mais sans connaissance de l’agilité. Nous avons dû le suppléer avec un proxy PO. Mais sans un PO client expert métier et décisionnaire, la situation s’est vite compliquée.
🚨 Des revues à 20 personnes… jusqu’à ce que le vrai décideur apparaisse au dernier sprint pour rejeter le produit 💥.
👉 Résultat ? Un projet qui traîne, un budget explosé, et une frustration partagée. L’agilité sans collaboration, ce n’est plus de l’agilité.

💡 Comment éviter ces pièges ?
1️⃣ Des contrats légers et collaboratifs : Un contrat simple, complété d’un Plan d’Assurance Qualité Agile. Si ça devient trop rigide, mieux vaut un contrat classique.
2️⃣ Impliquer les décideurs dès le départ : Les identifier et s’assurer qu’ils participent aux revues pour éviter les mauvaises surprises.
3️⃣ Un vrai Product Owner client : Formé à l’agilité, expert métier et capable de trancher sans devoir consulter un comité à chaque décision.
4️⃣ Construire une relation de confiance : Un contrat agile ne remplace pas une vraie collaboration.

🔍 Focus sur « Money for Nothing, Change for Free »
Bien que le forfait valeur soit une bonne option (à condition de définir cette valeur, bien sûr 😉), le modèle contractuel « Money for Nothing, Change for Free » peut aussi être très intéressant.
Formulé par Jeff Sutherland, il repose sur deux principes clés :
💰 Change for Free : Ajouter de nouvelles fonctionnalités en retirant des moins prioritaires.
💰 Money for Nothing : Stopper le projet dès que la valeur est atteinte, avec un paiement compensatoire de 20 %.
Un modèle qui privilégie la vraie valeur et l’engagement plutôt que des clauses rigides.

Continuons notre exploration des valeurs agiles avec une autre valeur clé…

🧭Les individus et leurs interactions plutôt que les processus et les outils

L’agilité transforme la collaboration : plus de communication, plus de feedbacks, plus de transparence. Mais cela ne veut pas dire abandonner les outils et les processus !

💡 Prenons l’exemple du schéma de Henrik Kniberg
Il illustre la différence entre suivre un ordre rigide et co-construire une solution en s’adaptant aux besoins réels, tout en s’appuyant sur l’intelligence collective. Il montre aussi l’importance de la collaboration entre décideurs et équipes pour réussir.

📖 Anecdote
À chaque transformation agile, un effet marquant est la multiplication des échanges.
Des équipes qui se contentaient d’exécuter des tâches ont commencé à partager, challenger et s’aligner. Non pas pour « faire de l’agile », mais pour mieux travailler ensemble.
Certains se sont plaints de perdre de l’« emprise », mais les résultats étaient là : des équipes plus autonomes, plus efficaces et des produits de meilleure qualité.
Je me souviens particulièrement d’une équipe où certains collaborateurs ont commencé à exprimer leurs difficultés et leurs doutes. Loin d’être un problème, cela a renforcé la dynamique collective : l’équipe a mis en place du pair-programming et du coaching de code, favorisant l’entraide et la montée en compétences. Comme le dit l’adage : « C’est dans l’adversité que se révèlent les vrais amis ». Ici, c’est dans les moments de difficulté que l’équipe a su se renforcer et grandir ensemble.

💡 Clés pour équilibrer interactions humaines, outils et processus
1️⃣ Encourager l’expression : Un cadre sécurisé où chacun peut s’exprimer sans crainte est essentiel. Sans cela, les meilleures idées restent enfouies, les conflits larvés et les départs imprévisibles. Par exemple, utiliser des rétrospectives régulières pour donner à chacun la parole sans crainte de jugement.
2️⃣ Co-construire les processus : Un bon processus ne doit pas brider, mais harmoniser. Quand les équipes participent à leur définition, elles s’y engagent naturellement. La coconstruction, encore et toujours !
3️⃣ Bien utiliser les outils : Jira et consorts ne sont pas « anti-agiles ». Mal utilisés, ils deviennent des usines à gaz. Bien maîtrisés, ils servent la transparence et la collaboration. Arrêtons de basher ces outils comme certains bashent l’agilité. Un bon outil est celui qui soutient le travail de l’équipe, pas celui qui le freine.

Terminons notre voyage au pays des valeurs agiles avec…

🧭 Un logiciel fonctionnel est plus important qu’une documentation exhaustive.

Livrer rapidement et régulièrement un logiciel fonctionnel est essentiel pour établir la confiance. Mais cela ne signifie pas abandonner la documentation, qui doit être utile et évolutive.

📖 Anecdote
Dans une équipe, tout allait vite… en apparence. Le client exprimait ses besoins directement à l’expert métier, qui transmettait oralement aux développeurs. Les testeurs, eux, devaient deviner comment valider le produit. Zéro documentation.
❌ Aucune trace des décisions, donc des erreurs répétées.
❌ Un onboarding inexistant : les nouveaux étaient livrés à eux-mêmes.
❌ Les anciens, submergés, se plaignaient de ne pas pouvoir avancer sur le produit.
❌ Résultat ? Un turnover élevé, les nouveaux préféraient fuir plutôt que galérer.

💡 Comment équilibrer livraisons rapides et documentation utile ?
1️⃣ Prioriser le produit fonctionnel : Un logiciel qui fonctionne et répond aux besoins vaut plus qu’un document détaillé décrivant un produit qui n’existe pas encore.
2️⃣ Opter pour une documentation vivante : Plutôt qu’un énorme manuel jamais mis à jour, privilégier des « auto-docs » qui évoluent avec le produit.
🔹 Le backlog comme référentiel vivant 📝 : Un backlog bien structuré documente les besoins, décisions et évolutions du produit.
🔹 Gherkin & BDD 📜 : Écrire des scénarios lisibles par tous, qui servent à la fois de spécifications et de tests automatisés.
🔹 Modèles C4 (Contexte, Conteneurs, Composants, Code) 🏗️ : Visualiser l’architecture logicielle pour mieux la comprendre et la partager.
3️⃣ ADR (Architecture Decision Records) : Tracer les choix architecturaux pour éviter les débats sans fin et documenter l’évolution du produit. En contexte multi-équipes, ces décisions doivent être partagées à l’échelle pour assurer la cohérence et éviter les redécouvertes inutiles.
4️⃣ Run & exploitation : Playbooks pour la gestion des incidents, procédures de déploiement et rollback (idéalement push-button, mais la doc aide à debugger en cas de problème), monitoring.
5️⃣ Docs d’onboarding : Une bonne documentation aide les nouveaux arrivants à monter en compétence sans alourdir l’équipe.
🎯 Tip d’intégration efficace :
Lorsqu’un nouvel arrivant rejoint l’équipe et qu’une partie de la doc est manquante, faites-lui rédiger ce qu’il a compris après une session avec un ancien. Il enrichit ainsi la documentation au plus près du besoin, validant sa compréhension et améliorant le support pour les prochains.

Voilà notre voyage s’achève… Qu’en retenir ? Que l’agilité n’est pas une révolution, mais une mise à jour nécessaire des pratiques existantes. Elle nous invite à recentrer notre attention sur ce qui compte vraiment : le produit et les personnes. Ce qui existait avant n’est pas obsolète, mais il est essentiel de le voir sous un autre angle. L’équilibre réside dans l’application du bon sens, loin des dogmes, qu’ils soient anciens ou nouveaux. Par exemple, un cycle en V n’est pas en soi une mauvaise chose. C’est l’allongement excessif de ces cycles qui devient problématique. L’agilité, c’est avant tout s’adapter à l’évolution, et cela commence par une vision pragmatique et équilibrée.

Si tu veux échanger sur la manière d’appliquer ces principes dans ton organisation ou découvrir comment l’agilité peut transformer tes pratiques, n’hésite pas à me contacter.
Et si tu as des retours ou des questions, laisse un commentaire, je serai ravi d’échanger avec toi !