Agile : avertissements

Ce serait une erreur pour une organisation de penser qu’elle peut introduire l’Agilité dans des développements de projets de système d’information, sans commencer par remettre en question ses structures.

Avertissement sur le fond

Tout d’abord il faut assimiler fonctionnellement que l’agilité  - dans le cas de développements applicatifs et en tant que recherche d’efficience - implique avant tout une  « spécification détaillée / conception-développement / validation technico fonctionnelle » se réalisant de manière intégrée lors d’une interaction unique impliquant les deux parties (qui n’en font plus qu’une le temps du projet - produit). Cette contrainte non négociable constitue pourtant le talon d’Achille de la plupart des organisations.

En clair et en pratique, si les deux parties ne sont pas naturellement et géographiquement proches, il n’existe que deux voies pour obtenir l’osmose du « métier » avec l’informatique de développement dans un mode réellement Agile :

• soit le métier déporte ses représentants « porteurs de connaissances » sur le lieu de la réalisation des projets ;
• soit c’est l’équipe informatique – à minima du développement en question – qui est déplacée géographiquement au cœur du métier.

Avertissement sur la forme

Quelle que soit sa taille de l’organisation, lorsqu’un lieu regroupe physiquement les deux entités informatique et métier(s), l’adoption du mode Agile n’est généralement pas un problème pour peu que les partenaires s’engagent dans la voie de la performance facilitée par les moyens d’une communication permanente.  En revanche, si métier(s) et informatique sont géographiquement distants, il est évident que les technologies actuelles  tentant de réduire cette fracture ne correspondent malheureusement pas encore aux exigences du pilotage des projets « Agiles ».  D’autant plus que la plupart des outils actuels n’ont d’agile que leur dénomination. Gardez à l’esprit la pertinence du manifeste proposé par les pionniers et fondateurs  d’agile « Les individus et les interactions  plutôt que les processus et les outils ».  À défaut de pouvoir obtenir le regroupement global d’entités gigantesques il faut alors, tel que sommairement décrit précédemment, décentraliser - temporairement ou non - la fonction de développement informatique au cœur du métier, ou à l’inverse intégrer la ressource disposant de la connaissance détaillée du besoin au plus proche des équipes de réalisation.

Autant le dire tout de suite, ce genre de restructuration sans être réellement novatrice n’est ni si simple ni aisée à mettre en œuvre. Pourtant, plus l’organisation s’avère importante, et moins elle pourra se permettre de s’en passer (pour se contenter de simples outils de téléconférence et de l’usage d’utilitaires de visualisation limitée d’une gestion de Kanban simpliste).

Le jour ou la technologie nous offrira des murs-écrans permettant d’appréhender clairement la totalité du « reporting mural »  d’un projet conséquent  tout en « vivant » la présence de multiples participants situés dans d’autres immeuble, pays ou continents, alors l’usage d’outils respectera enfin la première valeur du manifeste agile et rendra caduque une bonne partie des raisonnements sous-jacents ayant conduit  à cet article.

Certaines questions reviennent régulièrement en conférence, elles portent très souvent sur la typologie de projet la plus propice à une méthode Agile. En fait, il n’y a pas de projet type pour Agile. Il y a juste - généralement limité par les aspects  d’éloignement préalablement décrits - des organisations plus ou moins aptes à admettre et accepter les contraintes de l’Agile, afin de pouvoir ensuite en récolter les bénéfices. D’expérience il est possible d’appliquer Agile sur un projet de dix ou quinze jours de charges, comme sur un projet de trente années ou plus. Néanmoins, au-dessous d’un certain seuil de quelques dizaines de jours, seule une organisation disposant déjà de l’expertise et de l’environnement de travail Agile peut obtenir des bénéfices immédiats avec cette approche.

Parmi les autres points de déperdition d’efficience ou générateurs d’erreurs couteuses, on retrouve régulièrement les idées fréquemment colportées que le métier « ne saurait pas ce dont il a besoin » et que de toute façon « il n’aurait pas le temps de le préciser ». Ces vieux démons ont la vie dure. Pour les combattre sans vouloir réellement les tuer, les dirigeants ont recours à des maîtrises d’ouvrage déléguées ou des assistances à maîtrise d’ouvrage (proxy PO en Scrum). Du point de vue Agile, cela ne change rien au problème de fond, même si cela semble le dissimuler un peu. La doctrine Agile est aussi simple que puissante : la MOA doit être DU métier, pas DE métier.

La notion de  « documentation » demeure aussi une préoccupation primaire posée par l’adoption de l’Agilité. Dans les grandes entreprises, la source du problème se situe dans la structure même de leur organisation. Celles-ci sont habituellement issues d’un passé finalement très proche (quelques décennies au maximum), lorsque ce n’est pas dans la création d’un présent consacrant malheureusement un abîme géographique entre la localisation des métiers et celle de l’informatique.  Cette situation représente généralement l’héritage direct de la vision passéiste des développements organisés en projets suivant le mode « cascade ». C’est-à-dire séparant dans une première phase la production d’un document  servant de support à un développement envisagé dans une phase suivante (souvent dans un autre lieu avec d’autres personnes). Les exigences agiles de validation immédiate et d’acceptation des demandes de modification en cours de développement, caractéristiques  des projets actuels ont rendu obsolète et dangereuse cette vision basée sur une documentation exhaustive et figée. Il faut donc accepter le principe d’une documentation unique, dont la partie « haute » (légère mais permettant compréhension puis  estimation sera formalisée lors d’étapes de cadrage, puis de conception) servira de base à la constitution des exigences du produit (backlog selon Scrum). Ensuite ce qui devra être précisé dans le détail sera alors commenté lors du développement (d’où la nécessité de la présence régulière des deux parties), directement dans le code (lieu ou sa recherche ultérieure facilitée correspondra à un besoin de correction ou d’évolution).  Rien de bien révolutionnaire dans le principe, puisque cette technique est connue depuis un quart de siècle, encore faut-il la mettre en œuvre concrètement.

Conclusion

La mise en œuvre des exigences intrinsèques à l’agilité s’avère donc au départ un ensemble de communication, de réorganisation,  et d’acceptation de plusieurs types de changements.  C’est aussi, au-delà de l’humain, une exigence de facilités matérielles (plateau projet, communication, etc.).

Pour conclure comme M. de La Palisse, c’est de l’incapacité ou le manque de volonté de l’organisation à structurer agilement  l’allocation de ses ressources - surtout humaines - que découle l’impossibilité pour elles d’obtenir la performance et l’économie obtenues lors d’un projet en mode réellement Agile.