Les hypothèses agiles qui freinent encore les organisations

Quinze ans et toujours les mêmes erreurs

En 2011, le coach agile Mike Cottmeyer a publié une liste de douze hypothèses que les méthodes agiles formulent sur votre organisation. Le message était clair: adopter ces pratiques dans un contexte inadéquat mène à l’échec. Quinze ans plus tard, les organisations continuent de commettre les mêmes erreurs. On installe Scrum ou SAFe, on omet de vérifier si les conditions préalables existent et on déclare ensuite que l’agilité ne fonctionne pas.

Certaines de ces hypothèses se sont révélées remarquablement durables. D’autres méritent un regard neuf. Voici une évaluation de celles qui tiennent toujours, de celles qui ont évolué et de ce que les praticiens doivent surveiller aujourd’hui.

Les hypothèses qui n’ont pas changé

La stabilité des équipes reste non négociable

L’hypothèse la plus importante de la liste originale était que les équipes restent ensemble dans le temps. Rien au cours des quinze dernières années n’a affaibli ce constat. Les recherches issues du projet Aristotle de Google et des décennies d’études sur la performance des équipes confirment que la sécurité psychologique, les modèles mentaux partagés et une vélocité prévisible exigent de la continuité. Les organisations qui traitent les personnes comme des ressources interchangeables et les redistribuent entre projets chaque trimestre continueront d’obtenir de mauvais résultats avec les méthodes agiles.

Des équipes stables ont aussi besoin de personnes polyvalentes. L’agilité suppose que les membres de l’équipe sont des généralistes spécialisés: des professionnels en T qui possèdent une expertise approfondie dans un domaine tout en pouvant contribuer dans d’autres disciplines. Quand chaque personne de l’équipe est un spécialiste étroit, la seule façon de les occuper est de répartir leur temps sur plusieurs projets. Cela détruit la stabilité dont l’agilité a besoin.

L’engagement client fait toujours la différence

L’hypothèse selon laquelle un client ou un product owner pleinement engagé participe aux décisions en temps réel reste la condition la plus fréquemment violée en pratique. Le schéma se répète dans tous les secteurs: on nomme un product owner qui a un autre poste, on lui accorde deux heures par semaine pour l’équipe et on reproche ensuite aux développeurs de construire le mauvais produit. La documentation légère et la livraison itérative ne fonctionnent que lorsque quelqu’un ayant l’autorité est disponible pour orienter.

Les dépendances tuent la prévisibilité

Le couplage faible entre équipes et des dépendances externes minimales restent critiques. Des frameworks de mise à l’échelle comme SAFe tentent de gérer les dépendances inter-équipes via des incréments de programme et des tableaux de dépendances, mais le problème de fond persiste. Chaque dépendance hors du contrôle de l’équipe introduit du retard et érode la responsabilisation. Les équipes qui livrent le plus régulièrement sont celles qui possèdent l’intégralité de leur chaîne de valeur.

Les hypothèses qui ont évolué

La co-localisation n’est plus la norme

La liste originale supposait que les membres de l’équipe seraient dans la même salle. Le basculement mondial vers le travail à distance et hybride a rendu cette hypothèse largement obsolète comme exigence stricte. Les équipes distribuées peuvent réussir avec l’agilité à condition d’investir dans les bons outils et les bonnes pratiques. Ce qui n’a pas changé, c’est le besoin sous-jacent d’une communication fréquente et riche. Les équipes qui remplacent les conversations de couloir par rien échoueront quelle que soit la méthodologie.

Le produit plutôt que le projet est désormais la norme

Cottmeyer avait noté que l’agilité suppose que les équipes livrent des produits plutôt que des projets. En 2011, c’était une position minoritaire. Aujourd’hui, la pensée orientée produit est devenue le modèle dominant dans les organisations logicielles. L’adoption généralisée des rôles de product management et de cadres comme « Escaping the Build Trap » ont fait passer cette hypothèse du statut de présupposé à celui d’aspiration pour la plupart des entreprises. Le défi s’est déplacé: il ne s’agit plus de convaincre les organisations que la pensée produit compte, mais de les aider à restructurer leurs modèles de financement et de gouvernance.

Le niveau de talent requis a évolué

L’hypothèse originale selon laquelle l’agilité nécessite « les 10% de talents les plus performants » mérite d’être nuancée. Les pratiques agiles modernes, de meilleurs outils et des techniques de facilitation d’équipe plus matures ont rendu l’agilité accessible à davantage de professionnels. Ce qui reste vrai, c’est que les équipes auto-organisées ont besoin de personnes capables de prendre des décisions sans attendre des instructions. La question porte moins sur le talent brut que sur l’état d’esprit et la volonté d’opérer avec autonomie.

Les hypothèses qui ont toujours été incomplètes

La gouvernance ne peut pas être ignorée

Les méthodes agiles évitent délibérément de prescrire des structures de gouvernance. Cottmeyer avait signalé cela comme une hypothèse de gouvernance processuelle minimale. En pratique, les industries réglementées comme la banque et la pharmacie, les organisations du secteur public et les grandes entreprises ne peuvent pas simplement faire abstraction de la gouvernance. Une banque adoptant Scrum a toujours besoin de pistes d’audit, d’approbations de changements et de conformité réglementaire. La communauté agile a lentement reconnu cette lacune. Des approches comme le disciplined agile delivery et le Kanban d’entreprise offrent désormais des cadres pour intégrer la gouvernance sans abandonner l’agilité.

L’architecture exige une réflexion en amont

L’hypothèse selon laquelle une architecture établie existe déjà a toujours été une lacune des méthodes agiles. La réponse n’est pas de revenir à une conception massive en amont. Elle consiste à reconnaître que les décisions architecturales portent des conséquences à long terme que le refactoring sprint après sprint ne peut pas toujours corriger. Des pratiques modernes comme les architecture decision records et l’architecture évolutive offrent un terrain intermédiaire entre la planification lourde et l’absence de planification.

Ce que cela signifie pour votre organisation

La conclusion pratique n’a pas changé depuis 2011. Avant d’adopter un framework agile, auditez votre organisation au regard de ces hypothèses. Là où les conditions existent, le framework fonctionnera probablement bien. Là où elles n’existent pas, on fait face à un choix: transformer l’organisation ou adapter les pratiques. Prétendre que l’écart n’existe pas est la seule option garantie d’échouer.