L'agilité reste un mirage

Dans le monde numérique actuel, l'agilité est devenue la qualité primordiale des projets, surtout quand ceux-ci sont destinés à produire les applications web et mobiles destinés à la clientèle. Naturellement, tous les acteurs du logiciel se sont emparés des méthodes « Scrum » et apparentées. Mais sont-ils vraiment agiles pour autant ?
Si je me pose cette question aujourd'hui, c'est que j'ai eu récemment l'occasion de me replonger (un peu) dans les problématiques des projets informatiques et de leur organisation. Naïvement, je pensais que, depuis la naissance (en 2001) du « Manifeste Agile » et de l'emphase que mettent les équipes de développement à s'en réclamer, les principes étaient maîtrisés et largement appliqués. Or, je découvre avec stupeur que, dans la plupart des cas, les mises en application sont caricaturales…
Ainsi, où est la participation active des clients à la validation des livrables (qui doivent être des logiciels opérationnels et non seulement des spécifications plus ou moins précises), que sont devenues l'acceptation permanente des changements et les négociations régulières sur les différentes fonctions attendues du produit désiré (et leurs priorités), quid des équipes pluri-disciplinaires auto-organisées et de la collaboration de proximité (dont les contacts quotidiens entre le métier et les développeurs)…?
Rarement les retrouve-t-on dans les grandes entreprises, où les bonnes vieilles méthodes – dont l'inusable cycle en V – continuent à régner malgré un (parfois) habile maquillage marketing. Dans la « vraie vie », la maîtrise d'ouvrage produit toujours son cahier des charges pour le compte du client. Une fois transmis au responsable du projet, ce document devient artificiellement un « backlog produit » servant de base à quelques itérations internes (et voilà pour l'agile !). Une fois qu'il est épuisé, le logiciel fini est finalement transmis aux testeurs… et les ennuis commencent…
La responsabilité de ces dérives est partagée. D'un côté, ce sont les demandeurs qui ne sont pas tout à fait raisonnables : ils veulent simultanément des projets flexibles – au cours desquels ils ont la possibilité, jusqu'au dernier moment, de changer les spécifications du produit à livrer – et un engagement ferme sur les délais et les coûts de réalisation du logiciel idéal décrit dans un cahier des charges qui n'est de surcroît jamais considéré comme un « backlog » dynamique. Une gageure, surtout lorsque c'est une société tierce qui est engagée pour exécuter ce miracle…
Pour leur part, les DSI et les sociétés de services ne sont pas innocentes non plus. En dépit de leur légendaire incapacité à maîtriser les coûts et délais des projets, elles préfèrent prolonger une situation qu'elles connaissent et dont elles savent manier tous les rouages que de se lancer dans de nouveaux modèles, où elles devront faire elles-mêmes preuve de flexibilité. Tant que le vernis d'agilité suffit à satisfaire les clients, pourquoi s'aventurer dans l'inconnu ? Et tant pis pour les promesses de solutions mieux adaptées aux besoins réels et à la qualité irréprochable…
Alors, que faudrait-il pour que l'agilité devienne une réalité ? En un mot : la confiance. Le commanditaire doit accepter que le produit qui sera livré ne peut être décrit a priori et que, par conséquent, son partenaire de développement ne peut s'engager sur son contenu. En revanche, ce dernier doit aussi comprendre la crainte de son client et savoir lui proposer une certaine garantie de résultat (nécessitant un peu de créativité) tout en le sensibilisant aux avantages qu'il tirera de cette nouvelle forme de collaboration…