Les valeurs agiles... quel sens en dehors du secteur IT?

Photo by Annie Spratt on Unsplash

L'agilité - dont vous avez certainement maintes fois entendu parler ces dernières années - est née en 2001 dans le secteur IT. Cette année là, un groupe d'une quinzaine d'informaticiens jetait un pavé dans la mare du développement logiciel avec l'écriture et la publication du manifeste agile. Grosse remise en question: rejet d'une bureaucratie formaliste, révolte des faiseurs envers les penseurs, nouvelles bases de travail, nouveaux rapports interpersonnels, etc.

Tous les ingrédients d'une révolution - heureusement pacifique - y étaient, et cette révolution a d'ailleurs bien eu lieu. Bientôt vingt ans plus tard, presque tout le monde a adopté les bases de l'agilité, tout le monde les a adaptées à sa sauce, et rares sont ceux et celles qui n'admettent pas aujourd'hui que ce fut essentiellement pour un mieux: pour l'esprit d'équipe, le bien être, le sens de l'innovation, la pertinence, la productivité, etc.

L'agilité est d'ailleurs aujourd'hui appelée à investir d'autres secteurs en recherche de ces mêmes vertus. Je propose ici une revisite commentée des quatre valeurs agiles, à destination des futurs agilistes, par exemple non informaticiens:

1. Préférer les interactions entre individus aux processus et outils
2. Préférer un logiciel opérationnel à une documentation exhaustive
3. Préférer la collaboration avec les clients à la négociation contractuelle
4. Préférer l'adaptation aux changements au fait de suivre un plan pré-établi.

L'agilité expose aussi douze principes, plus concrets, que je couvrirai plus tard parce que moins directement transférables hors du secteur IT. Je concluerai avec une remise en contexte de la naissance de l'agilité, qui peut aider à réfléchir à la pertinence d'un transfert hors du secteur IT.

Les quatre valeurs de l'agilité

Le manifeste agile s'articule autour de quatre piliers fondamentaux, qui installent une hiérarchie de valeur parmi des éléments pris deux à deux. Tout en reconnaissant la valeur des éléments de droite, les auteurs indiquent avoir été amenés, par la pratique du développement logiciel à privilégier les éléments de gauche. Je vous propose ici une mise en contexte de chaque pilier, et pour chacun quelques questions ouvertes pour leur transfert hors du secteur où ils sont nés.

Privilégier les individus et leurs interactions aux processus et outils

La création d'un logiciel non trivial est aussi complexe que créatif. Un enjeu particulièrement important est la définition et compréhension des besoins (focus sur le problème à résoudre). Le développement quant à lui nécessite de la créativité (pour explorer les solutions possibles). Alors que les années 60 à 90 posaient les bases théoriques du développement logiciel, les outils et processus ainsi découverts se sont révélés avec le temps... un peu trop théoriques. En particulier, ils éloignaient ceux et celles qui comprenaient les problèmes (les utilisateurs et/ou clients), des développeurs et développeuses qui mettaient en œuvre les solutions. Eloignement temporel: l'analyse d'abord, le développement ensuite. Eloignement physiquement également: surtout chacun dans son bureau, derrière son ordinateur. Eloignement hiérachique enfin: il fût un temps pas si lointain où l'analyste était mieux considéré que le programmeur. Les temps ont bien changé!

Le manifeste agile est venu repositionner le curseur différemment: face à des problèmes complexes nécessitant de la créativité, rien de tel que des... être humains qui interagissent. Et d'insister sur le fait d'éviter si possible les frontières temporelles, physiques et hiérarchiques.

Une équipe agile est ainsi typiquement composée de 4 à 8 personnes aux rôles biens définis, organisée horizontalement, généralement localisée au même endroit, globalement autonome dans ses décisions, et où règnent idéalement la confiance et le respect mutuel.

Et dans votre secteur, projet, ou organisation?

• Voyez-vous des silos à déconstruire? Des interactions qui fréquemment manquent?

• Pensez-vous qu'il faille revoir les lignes temporelles typiques d'un projet?

• Voyez-vous un utilisateur/client à rapprocher de ceux et celles qui lui apportent des solutions concrètes?

• Voyez-vous des lignes hiérarchiques qui viennent en travers de la capacité d'une équipe à batir dans la confiance?

Privilégier des logiciels opérationnels à une documentation exhaustive

Durant de nombreuses années, le développement logiciel s'est inspiré d'autres disciplines d'ingénierie où l'on analyse d'abord finement un problème et sa solution, avant d'imaginer la mettre à oeuvre. Comme le résultat de l'analyse doit être transmise pour compréhension à ceux et celles qui développement ensuite, la phase d'analyse génère son lot de documentation écrite. Malheureusement, très peu d'êtres humains réfléchissent correctement dans l'abstraction pure, quand la matière est intangible (comme pour un logiciel). Il n’était donc pas rare de voir l'analyse erronée ou incomplète, la documentation peu ou pas lue par l'équipe de développement. Ceci sans même citer la difficile implication des utilisateurs et clients face à des montagnes de papiers à revoir. L'approche fonctionnait rarement bien...

Le manifeste agile a repositionné le curseur ici également. L'être humain excelle quand il confronte une idée théorique à une réalisation pratique. Dès lors, rien de tel pour créer un logiciel, que de le faire de manière incrémentale (rendons à César: cela a avait été découvert bien avant l'agilité, par exemple par F. Brooks) et de mettre le résultat bien concret dans les mains d'un utilisateur réel, qui en fera bon usage et pourra mieux que personne indiquer les ajustements nécessaires.

C'est ainsi que le développement logiciel moderne insiste sur le développement par itérations successives, chaque itération se terminant idéalement par une mise à disposition d'un résultat tangible et qualitatif. L'importance accordée par les méthodes agiles aux tests (automatisés) poursuit le même objectif: construire incrémentalement un logiciel de qualité sans régresser en chemin.

Et dans votre secteur, projet, ou organisation?

• Est-il possible construire de manière plus incrémentale? De mettre fréquemment dans les mains des utilisateurs ou clients quelque chose de tangible pour validation?

• Comment pouvez-vous confronter vos constructions mentales à la réalité de terrain?

• Est-il possible de construire qualitativement sans faire et défaire, et sans régresser en chemin?

Privilégier la collaboration avec les clients à la négociation contractuelle

Comme les montants engagés dans le développement d'un logiciel non trivial sont importants, il s'agit généralement de tenir un cahier des charges précis, dans des délais bien tenus, et un budget cadré à l'avance. En pratique, le cahier des charges n'est jamais assez précis, les délais jamais tenus, et le budget toujours trop court. Il a fallu trouver une autre manière de procéder...

Ici encore, le manifeste agile a revisité les pratiques du secteur, même s'il faut avouer qu'il s'agit sans doute du pilier le plus rarement mis en place. L'idée (théorique) semble pourtant simple: plutôt qu'engager des heures de négociation sur nombre de points de détails, pourquoi ne pas nourrir la confiance mutuelle. Le client, par son implication, s'engage à piloter le projet vers ce qui génère de la valeur pour lui, son entreprise, ou ses propres clients ; le prestataire s'engage, par son professionnalisme et les pratiques agiles, à fournir fréquemment des versions successives et de qualité du logiciel souhaité, qui permette d'aller chercher cette valeur.

Et dans votre secteur, projet, ou organisation?

• Passe-t-on des heures ou des jours à négocier? Si oui, est-ce des heures à haute valeur ajoutée?

• Quels risques justifient le temps passé à mener cette négociation et à la coucher par écrit?

• Investit-on dans la confiance mutuelle? Revisite-t-on cette relation de confiance fréquemment?

Privilégier l’adaptation au changement au suivi d’un plan

Dans tout projet d'envergure, il est fréquent de suivre un cahier des charges détaillé, des master plans, gantt charts et autres constructions théoriques qui décrivent un chemin de développement idéalisé. Par le passé, s'écarter du plan dans le développement logiciel relevait de la faute grave. Dans le chef du client, changer d'avis ou d'idée remettait en question ce qui avait été initialement convenu, chamboulant de la sorte les délais et budgets âprement négociés. Dans le chef du prestataire, s'écarter du plan revenait précisément à ne pas tenir le cahier des charges, ou les délais, ou le budget... ce qui mettait à mal la relation contractuellement établie.

Vous l'aurez compris, suivre un plan tout tracé n'est pas idéal pour la création d'un logiciel: trop d'incertitudes et d'aller-retour sont nécessaires pour d'une part bien comprendre le problème à résoudre et d'autre part mettre en œuvre la solution. L'agilité a fait bouger les lignes: puisque tout est incertain, admettons qu'avoir un plan c'est bien, mais s'adapter à la réalité c'est mieux. Sur base d'une confiance mutuelle, et du respect de quelques règles qui dictent quand les changements peuvent intervenir, l'agilité prône des plans moins précis et plus souvent revisités.

Et dans votre secteur, projet, ou organisation?

• Établit-on souvent des plans de projets qui se révèlent être sur la comète?

• Pourrait-on faire des plans moins précis, et s'adapter à la réalité de terrain plus souvent?

• Que mettre en place pour accueillir le changement comme une opportunité plutôt qu'une contrainte?

• Est-il possible d'installer une confiance mutuelle quant aux comportements adéquats face à l'incertitude?

Conclusion

Cet article sur l'agilité offre une relecture commentée des quatre piliers agiles. Ces derniers posent une hiérarchie de valeur. L'idée n'est PAS de rejeter en bloc les processus, outils, documentation, négociation, et plans. Mais bien d'y préférer quand c'est possible, les interactions entre individus, les résultats concrets, la confiance et collaboration, et les ajustements.

Le manifeste agile a bientôt 20 ans. Alors que nombre de secteurs en empruntent aujourd'hui les valeurs et pratiques, il me semble également important d'en revisiter les hypothèses fondatrices sous un angle critique, pour un transfert aussi raisonnable qu'éclairé. Les questions ouvertes proposées ci-dessus vous ont j'espère offert un premier jalon simple dans cette réflexion: qu'est-ce qui est applicable dans votre secteur et qu'est-ce qui ne l'est pas?

Lors d'un événement dans le secteur pharmaceutique, où Klaro est utilisé, j'ai eu l'occasion de présenter une lecture historique du développement logiciel et la place de l'agilité dans l'innovation. J'aimerais remettre ici par écrit le contexte qui me semble le plus important à connaître pour tout transfert de l'agilité à un autre secteur:

L'agilité est née dans un secteur où maîtriser l'incertitude est généralement important, voire central, pour la bonne conduite d'un projet.

Les méthodes agiles sont particulièrement efficaces quand les risques d'une approche par essais/erreurs sont faibles, voire peuvent être transformés en opportunités.

Probablement plus que toute autre méthode, l'agilité investit dans la confiance au sein des équipes, et l'intelligence des humains.

J'aurai l'occasion d'écrire un peu plus tard sur les risques intrinsèques à la hiérarchie de valeurs posée par les valeurs agiles. Inscrivez-vous à notre newsletter ci-dessous pour être tenu.e au courant.