Agile, état de l'art 2016 et clés du futur

Certains pensent que je ne crois plus à "l’Agile", c’est faux. Je pense même que les organisations n’en ont jamais eu autant besoin.

Agile, les clés actuelle de la réussite

En 2003, dans l’ouvrage Systèmes d’information et processus Agile, j’écrivais : « L’émergence d’une économie mondialisée et numérisée positionne la dimension temporelle de la performance comme le vecteur déterminant d’une recherche exacerbée de différenciation stratégique. » Cette phrase, et bien d’autres réflexions publiées dans les livres et communications précédentes et suivantes, restent toujours d’actualité. L’urgence de la comprendre fonctionnellement et opérationnellement s’est simplement accrue.

« Think globally »

Il est étonnant de constater que plus de vingt-cinq ans auront été nécessaires au mouvement itératif qui se nomma ensuite « Agile », parallèlement à la pression de la différenciation concurrentielle pour commencer à bousculer sérieusement la conduite de projet classique. Lors de cette recherche d’adaptation, la culture française centralisatrice et la forme d’éducation qui en découle ne nous aide pas vraiment. Confrontée à des processus en évolution rapide, la quête de perfection propre au rationalisme cartésien aboutit désormais à la paralysie de l’action.

Dans le film culte de Denys de la Patellière, un taxi pour Tobrouk, Maurice Biraud et Charles Aznavour, en observant Lino Ventura, constataient : « Deux intellectuels assis vont moins loin qu’une brute qui marche. » Appliquée au contexte de cet ouvrage, la paraphrase est aisée. « Deux rationalistes qui planifient produisent moins qu’un pragmatique qui développe. ». Le Nord-Américain, adepte de l’empirisme pragmatique, conclura par just do it ! De plus, l’observation des tentatives de mises en œuvre de cette formule dans la plupart des organisations porte à conclure que, décidément, le système d’information est une chose trop importante pour être exclusivement confié à des informaticiens, et que, de toute évidence l’expression « think globally, act locally » n’est pas d’origine latine.

« Act locally »

Au-delà de ces réflexions généralistes, dans les entreprises en quête « d’agilité », les vraies questions à se poser par les dirigeants devraient être :

« Pour quels motifs précis doit-on devenir Agile dans notre contexte ? »
« Quels moyens seront concrètement alloués aux nécessaires adaptations de processus, de fonctions »
« Quelle communication va accompagner le changement qui va être imposé, s’il n’est pas issu des demandes de la base ? »

À ce sujet, il n’est pas inutile de rappeler les débuts de l’agilité. Les méthodes actuelles sont issues des envies naturelles des équipes d’informaticiens qui souhaitaient améliorer leurs environnements organisationnel, méthodologique et technologique de travail. C’est à partir de ces réalités pratiques issues de la base, et non à partir d’une théorie globale ou structurante, que l’Agilité progressait jusqu’alors vers les sphères les plus hautes de l’organisation. Je ne suis pas certain que la démarche inverse permette d’obtenir les mêmes résultats. Dans tous les cas, il faudra beaucoup de finesse dans la communication pour diffuser le message et faire accepter un réel changement rarement perçu comme indispensable.

Avertissement sur le fond du problème

Ce serait une erreur pour une organisation de penser qu’elle pourrait introduire de l’Agilité dans ses projets de systèmes d’information et leur exploitation, sans commencer par remettre en question ses structures. En clair, il n’existe que trois voies pour obtenir l’osmose du « métier » avec l’informatique de développement dans un mode réellement Agile. Tout d’abord, il faut assimiler fonctionnellement que cette recherched’efficience implique avant tout une « spécification détaillée - conception-développement – validation » se réalisant de manière intégrée lors d’une interaction unique. Dans ce cas,

soit les deux parties sont naturellement et géographiquement proches ;
soit le métier déporte ses représentants sur le lieu de la réalisation des projets,
soit c’est l’équipe informatique - du développement en question – qui est déplacée géographiquement au cœur du « métier ».

Avertissement sur la forme de la solution

Si l’on me pose la question : « On vous confie un projet de développement d’application. En regard de votre expérience, quelle méthode choisissez-vous ? ».

Ma réponse est évidente : « En admettant utiliser Scrum pour le pilotage du projet et la validation de la qualité fonctionnelle applicative, il est alors nécessaire de déterminer un framework de développement sur la base d’une partie des techniques d’eXtreme Programming pour la qualité technique. Mais cet ensemble ne sera pas suffisant pour couvrir l’organisation et la production du « sprint zéro » (les étapes de préparation préalables à tout projet Scrum). Pour ce faire, j’utiliserai les techniques de structuration des besoins proposés par Puma dans le cadre de son moteur de communication. Pour compléter cet ensemble, dans une structuration logique du fameux « Sprint zéro », je mettrais en œuvre les trois premières phases détaillées par la méthode RAD (Initiation, Cadrage, Design). Ainsi, je disposerai d’un canevas cohérent incluant le choix des acteurs et la variabilité de leurs engagements, la justification financière de mon action, un cadre prévisionnel de contrôle de la « boîte de temps » allouée. »

Avec ces outils, je devrai aussi prendre en considération les divers impacts organisationnels ou d’architecture ainsi que la modélisation Agile minimum, mais indispensable à tout développement de SI. Cette vision d’ensemble est d’ailleurs le type d’intégration proposée par PUMA. Encore faut-il le savoir et en maîtriser les connaissances sous-jacentes.

Certains pensent que je ne crois plus à « l’Agile », c’est faux. Je pense même que les organisations n’en ont jamais eu autant besoin. Ce dont je doute, c’est de leur capacité à changer leurs structures lorsqu’elles n’y sont pas contraintes. Quant à Scrum, puisque cette « méthode » est un sous-ensemble des premières méthodes Agiles, même si ses adeptes le réfutent, il suffit d’en contrôler les errements organisationnels et de lui adjoindre quelques techniques adaptatives pour en faire un socle méthodologique acceptable. On ne va même pas l'assassiner, on va juste l'aider à devenir ce qu'elle aurait pu et du être. C’est d’ailleurs la raison principale de la publication de mon dernier livre « Scrum et au-delà ». Lequel présente dans la partie « Act locally » des techniques et des formes d’utilisation indispensables à la maîtrise des vrais développements adaptatifs.

Pour conclure cet article avec un peu de plus de légèreté, je vous propose la lecture de « Protectora Galactica ». Cela se présente comme un simple roman de vacances, où parmi bien d’autres choses se trouvent de nombreux clins d’œil à des formes d’Agilité réellement surprenantes et parfois futuristes.